Secrets de tolérance aux fautes de notre front office

Comment est organisée une banque moderne? Il y a un back office où diverses opérations sont effectuées, des comptes et des rapports sont tenus. Il existe un middle office où les décisions sont prises et les risques sont évalués, où les risques de crédit sont évalués et les fraudeurs sont neutralisés. Et il y a un front office où ils servent les clients et sont responsables de leur interaction avec la banque à travers différents canaux.



Sberbank possède des centaines de systèmes de disponibilité et de fiabilité variables. Il a son propre développement et des solutions en boîte avec différents degrés de personnalisation, différents SLA. Tous les systèmes sont intégrés les uns aux autres de nombreuses façons. Dans cet article, nous vous expliquerons comment toute cette colline de fourmis frontale est construite de manière à fournir un service client continu.

Commençons par la théorie. Les principes clés par lesquels un système à sécurité intégrée est construit peuvent être empruntés à un sous-marin:

1. Le sous-marin est divisé en compartiments indépendants. Si un compartiment est inondé, les autres survivent encore.
   
2. Tous les composants critiques sont réservés. Moteurs, réservoirs d'oxygène. Et les Beatles ont également réservé des périscopes avec des hublots.
   
3. Le sous-marin est protégé des conditions critiques à la surface - si nécessaire, il peut aller plus loin et y travailler comme si de rien n'était.
   

Nous illustrons le premier principe avec un exemple de notre pratique. Nous avions un système de cache distribué. Et une fois sous charge, l'un des nœuds de données de cache est tombé en panne. Ce n'est pas grave: pour maintenir une réplication correcte, le contrôleur a redistribué les données aux nœuds restants. Mais à la suite de la redistribution, le trafic réseau a bondi et les paquets ont commencé à être perdus, y compris la surcharge du cache. À un moment donné, le contrôleur a décidé qu'un autre nœud de données était en panne, a redistribué les données à nouveau, le trafic a augmenté ... En conséquence, en moins d'une minute, le système est tombé complètement en panne. Heureusement, c'était un circuit de charge et personne n'a été blessé. Mais nous avons passé beaucoup de temps à chercher la cause.

On peut affirmer que cela ne se produit pas avec les bases de données en cluster et les serveurs haut de gamme - la redondance est intégrée au niveau matériel. Pour citer Werner Vogels, CTO Amazon: «Tout échoue tout le temps.» Nous sommes tombés et clusters de bases de données, et serveur haut de gamme. Tombé à cause d'erreurs de configuration, à cause de problèmes dans le logiciel de gestion. Avec la solution de chaque problème, notre confiance dans ces solutions a diminué. En conséquence, nous sommes arrivés à la conclusion: seuls les systèmes qui sont divisés en parties indépendantes les unes des autres - principalement indépendantes dans la gestion - ne refusent pas.

Architecture multi-blocs

La solution à nos problèmes était une architecture multi-blocs. Dans ce document, tous les composants matériels, y compris les bases de données, sont divisés en blocs à couplage lâche, presque indépendants. Chaque bloc sert une partie des clients, comme lors du partage dans des bases de données. Les nœuds de chaque bloc sont réservés à tous les niveaux, y compris la géo-redondance. Tout problème dans un bloc n'affecte pas les autres. Avec une augmentation du nombre de clients, nous pouvons facilement ajouter de nouveaux blocs et continuer à travailler normalement.


Architecture générale des blocs. Tous les blocs sont réservés selon le schéma 2N. Chaque centre de données dispose d'un puissant équilibreur de charge matériel. Les centres de données sont connectés par 2-3 canaux de communication indépendants.

Les serveurs sont répartis en blocs de cinq types:

• Routeur - une unité de contrôle qui distribue les clients aux autres unités
  
• Bloc client - le bloc principal desservant jusqu'à 10 millions de clients
  
• Bloc pilote - ici, nous testons de nouvelles versions d'applications sur des clients fidèles (environ 300 000 personnes, principalement des employés de Sberbank)
  
• Unité invité - les utilisateurs non authentifiés sont servis par son intermédiaire; ceux, par exemple, qui passent par le site
  
• Bloc de réserve - un bloc de sécurité suffisamment puissant pour remplacer deux blocs clients à la fois
  

À l'intérieur de chaque bloc, le serveur d'applications et le serveur Web sont séparés par des canaux de service, mais les bases de données sont communes. Nous pouvons donc isoler les scénarios de défaillance les plus courants afin qu'ils ne dépassent pas les limites de notre canal.

Comment ça marche?

Tout d'abord, l'utilisateur entre dans l'unité de routeur. Ce bloc vérifie à quel bloc client la personne appartient et l'envoie là (ou au bloc invité). De plus, une personne travaille calmement à l'intérieur de son bloc. Si une défaillance se produit dans l'unité native, la personne retourne au routeur et reçoit automatiquement une direction vers l'unité de sauvegarde pour un travail ultérieur.

Qu'arrive-t-il aux données pendant le fonctionnement? Les informations sur l'interaction du client avec la banque sont répliquées en continu des blocs clients vers la base de données d'archives. Après avoir rencontré l'utilisateur, l'unité de sauvegarde extrait les informations nécessaires à son sujet de la base de données d'archives et, si nécessaire, fournit des données - afin que l'utilisateur ne se fige pas lorsque des problèmes surviennent de notre part.

Les opérations effectuées dans l'unité de sauvegarde y sont stockées. Lorsque le bloc client natif de l'utilisateur est restauré, il revient. Les opérations accumulées dans le bloc de sauvegarde sont transférées de manière asynchrone aux blocs clients nécessaires. Bien que les données soient réduites à la cohérence, le client voit un message indiquant que toutes les opérations ont été acceptées et enregistrées, mais en raison de travaux techniques, les dernières opérations peuvent ne pas être affichées.


Schéma général du système

Dans certains cas, le basculement vers le bloc de sauvegarde est planifié à l'avance, par exemple lors de la mise à jour dans le bloc client. Ensuite, l'unité de sauvegarde ne récupère pas les sessions client, mais à un certain moment, elle démarre simplement toutes les nouvelles opérations à la place. Si vous devez passer d'urgence à l'unité de sauvegarde, l'administrateur peut désactiver toutes les sessions. Dans ce cas, la session utilisateur sera interrompue et il en démarrera une nouvelle sur l'unité de sauvegarde. À propos, l'unité de routeur possède sa propre unité de sauvegarde dédiée. Donc, personne ne se retrouve sans roue de secours.

Mise à jour des systèmes

Les nouvelles versions logicielles sont déployées en premier sur le bloc pilote et sont présentées à un public limité. Puis progressivement sur les blocs clients, et déjà à la fin - sur les blocs de réserve. Donc, s'il y a des problèmes dans le bloc client avec la nouvelle version du logiciel, nous pouvons transférer les clients vers le bloc de sauvegarde de l'ancienne.

Lorsqu'une nouvelle fonctionnalité roule sur un bloc, elle ne s'active pas automatiquement. Les administrateurs le font à l'aide de cases à cocher - bascule de fonction. Vous pouvez basculer les clients vers la nouvelle version par groupes - c'est ainsi que nous vérifions la réaction des mises à jour à la croissance de l'audience.

Autonomie

Notre système en lui-même est fiable, mais dépend toujours du backend utilisé pour les opérations. Comment se protéger des problèmes? Nous utilisons trois outils.

1. Demandes en attente . Le client demande que l'opération soit terminée. Nous l'enregistrons dans notre base de données et essayons de l'exécuter dans le backend. Si le backend ne répond pas, nous montrons au client un message indiquant que l'opération a été acceptée et est en cours de traitement. Lorsque le backend monte, un «docker» distinct lit les opérations incomplètes de la base de données et les «pousse» en lots dans le système backend. Afin de ne pas surcharger la table principale avec des opérations avec un grand nombre de requêtes à faible efficacité, nous utilisons en outre la table dite des jetons - une liste d'identifiants d'opérations incomplètes. Afin de ne pas abandonner le backend qui vient d'augmenter de centaines de milliers d'opérations, nous utilisons le traitement par lots - nous supprimons deux cents opérations et attendons, par exemple, quelques secondes.
   
   
   
   Mais que se passe-t-il si des changements importants se produisent entre la demande de l'utilisateur et la récupération du backend? Par exemple, les taux de change ont-ils changé? Dans ce cas, une double vérification est déclenchée. Ces opérations sont enregistrées à l'entrée, puis vérifiées à l'exécution. Si quelque chose ne converge pas, l'opération sera ajustée ou rejetée.
   
2. Mise en cache des données . Lorsqu'un utilisateur entre, par exemple, Sberbank Online, toutes les informations nécessaires le concernant sont déjà visibles - factures, cartes, prêts, etc. Ces données sont demandées via un bus de service à partir d'une dizaine de systèmes. Si la réponse a été collectée rapidement, en quelques secondes, nous montrons les données au client et les sauvegardons dans le cache système de notre base de données. Sinon, nous recherchons dans la base de données les données précédemment mises en cache et les montrons au client. Bien sûr, pour cela, le cache ne doit pas être plus ancien qu'un certain âge. Lorsque le bus de service collecte néanmoins les données nécessaires à la demande, elles sont mises à jour dans le cache de la base de données et envoyées au client au lieu des anciennes.
   
   Lors de l'utilisation de l'application, cela signifie qu'une personne verra l'état de son compte quelques secondes après son entrée. Bien que les données puissent être quelque peu dépassées. Si cela se produit, après quelques secondes, les données sont généralement remplacées par les données réelles - ce qui signifie que le bus de service a collecté tout ce dont vous avez besoin.
   
   De plus, nous avons une pré-mise en cache utilisant la réplication. Surtout pour différentes données de référence. Nous préchargeons ces données dans le backend, le client fait calmement une demande pour l'opération, et nous l'envoyons. Même si les systèmes chargés de la maintenance des données ne fonctionnent pas, l'utilisateur n'a pas à attendre à nouveau.
   
3. Pauses techniques . Si le système principal est tombé en panne ou est en cours de maintenance, nous le signalons. Et puis les opérations qui le traversent se heurtent immédiatement au refus. Nous évitons donc que le serveur d'applications ne déborde de requêtes en attente d'une réponse par timeout. Dans ce mode, la mise en cache des opérations et des données que nous avons décrites précédemment peut être utilisée. Des ruptures techniques sont définies pour chaque scénario d'intégration, manuellement par l'administrateur ou automatiquement, en fonction du nombre de demandes.
   

Dans tous les cas, nous cherchons à minimiser les attentes de l'utilisateur - s'il y a des problèmes, il reçoit immédiatement un message sur l'impossibilité de l'opération. Nous essayons de minimiser le nombre de ces messages, donc nous augmentons la durée de vie de certaines données en cache - cela nous permet d'étendre l'interaction normale avec les services de la banque.

Dans certains scénarios, la mise en cache ne doit pas être supprimée, par exemple lors de l'émission d'espèces. Il s'agit d'une fraude possible de la part du client. Ces opérations dans les distributeurs automatiques de billets et les succursales ne sont pas mises en cache. Dans la banque Internet, c'est plus facile - nous acceptons la demande, puis la traitons ou la rejetons.

Par conséquent, en respectant les principes décrits dans l'article, vous pouvez obtenir des systèmes avec une disponibilité de 99,99% et plus.

Nos plans

Désormais, les plans visent à minimiser le délai de mise sur le marché de notre système unique, à garantir l'omnicanalité, en tenant compte des caractéristiques techniques et commerciales des canaux. Et également migrer les systèmes hérités tout en conservant leur opérabilité pendant le déménagement.

Nous remercions Roman Shekhovtsov pour son aide active dans la préparation de ce message