📤 🚍 🤹🏾 Houston nous avons un problème. Échec de la conception du système 👨🏿‍🏭 👩‍🔬 🚧

En 1970, des ingénieurs américains ont lancé le vaisseau spatial Apollo 13 sur la lune. À bord se trouvent trois batteries de piles à combustible, il n'y a rien à craindre, tout est dupliqué de manière fiable et répétée. Mais personne n'aurait pu imaginer que l'explosion d'une bouteille d'oxygène désactiverait deux des trois batteries. La tragédie! Les astronautes sont rentrés chez eux, un long métrage a été tourné sur l'événement avec Tom Hanks, et la phrase de l'astronaute Jack Swigert: «Houston, nous avons un problème!», Est entrée dans l'histoire.

L'histoire d'Apollo 13 est une autre preuve du fait bien connu que vous ne pouvez pas vous préparer à tous les problèmes possibles. C'est une propriété naturelle du monde: le fer se casse périodiquement, le code plante et les gens font des erreurs. Il est impossible d'éliminer complètement cela.

Pour les grands systèmes distribués, ce comportement est normal, il est la conséquence d'économies d'échelle et de statistiques. C'est pourquoi Design for Failure (AWS) est le principe de conception de base des services cloud AWS. Les systèmes sont initialement construits de manière à restaurer le fonctionnement à temps plein le plus rapidement possible et à minimiser les dommages causés par des défaillances connues et inconnues. À HighLoad ++, Vasily Pantyukhin, en utilisant des problèmes réels avec les services de combat à titre d'exemple, a montré des modèles de conception pour les systèmes distribués que les développeurs AWS utilisent.

Vasily Pantyukhin (Poule) Est l'architecte d'Amazon Web Services en Europe, au Moyen-Orient et en Afrique. Il a commencé en tant qu’administrateur Unix, a travaillé chez Sun Microsystem pendant 6 ans, a enseigné des cours techniques et pendant 11 ans, il a enseigné la concentration des données dans le monde chez EMC. Au sein d'une équipe internationale, il a conçu et mis en œuvre des projets du Cap à Oslo. Désormais, il aide les grandes et petites entreprises à travailler dans des clouds publics.

En 1949, un accident d'avion a été enquêté dans une base des forces aériennes de Californie. Edward Murphy était l'un des ingénieurs qui a fait cela. Il a décrit le travail des techniciens locaux comme suit: "S'il y a deux façons de faire quelque chose et que l'une d'elles mène au désastre, alors quelqu'un choisira cette méthode."

Plus tard, grâce à Arthur Bloch, la déclaration est entrée dans l'histoire comme l'une des lois de Murphy. En russe - la loi de la méchanceté. Son essence est qu'il ne sera pas possible d'éviter les pannes et les erreurs humaines, et devra vivre avec elle en quelque sorte. C'est pourquoi, lors de la conception, nous introduisons immédiatement les défaillances et les défaillances de composants individuels dans nos systèmes.

Conception de défaillance

Dans la conception pour l'échec, nous essayons d'améliorer trois caractéristiques:

accessibilité (ces mêmes «neuf»);
fiabilité - propriété du système de fournir le niveau de service nécessaire;
tolérance aux pannes - une propriété du système pour éviter l'apparition de problèmes et récupérer rapidement après eux.

La fiabilité a la propriété d '« inconnues connues ». Nous nous protégeons des problèmes connus, mais nous ne savons pas quand ils se produiront.

« Un inconnues connues » est ajouté à la tolérance aux pannes - ce sont des problèmes surprises que nous ne savons rien. Beaucoup de ces problèmes dans le cloud sont liés à des économies d'échelle: le système prend de la taille lorsque de nouveaux effets étonnants et inattendus apparaissent.

L'échec n'est généralement pas un phénomène binaire. Sa propriété principale est le «rayon de souffle» ou le niveau de dégradation du service, rayon de destruction. Notre tâche est de réduire le "rayon de souffle" des systèmes.

Si nous reconnaissons que les problèmes ne peuvent être évités, nous devons alors nous y préparer de manière proactive. Cela signifie que nous concevons les services de telle manière qu'en cas de problèmes (ils le seront certainement), nous contrôlons les problèmes, et non l'inverse.

Lorsque nous répondons à un problème, il nous contrôle.

Plan de données et plan de contrôle

Vous avez sûrement des appareils électroniques à la maison qui sont contrôlés par une télécommande, comme un téléviseur. L'écran du téléviseur fait partie du plan de données - qui exécute directement la fonction. La télécommande est l'interface utilisateur - Plan de contrôle. Il est utilisé pour gérer et configurer le service. Dans le cloud, nous essayons de séparer le plan de données et le plan de contrôle pour les tests et le développement.

Les utilisateurs, le plus souvent, ne voient pas la complexité du plan de contrôle. Mais les erreurs de conception et de mise en œuvre sont les causes les plus courantes de défaillances massives. C'est pourquoi mes conseils se concentrent sur le plan de contrôle - parfois explicitement, parfois non.

L'histoire d'un problème

En juillet 2012, une violente tempête est passée en Virginie du Nord. Le centre de données a une protection, des générateurs diesel, etc., mais il se trouve que dans l'un des centres de données de l'une des zones de disponibilité (zone de disponibilité, AZ) de la région de Virginie du Nord, l'alimentation a été coupée. L'électricité a été rapidement rétablie, mais la restauration des services a duré des heures.

Je vais vous expliquer les raisons de l'exemple de l'un des services de base - CLB (Classic Load Balancer). Cela fonctionne simplement: lorsque vous démarrez un nouvel équilibreur dans chaque zone de disponibilité, des instances distinctes sont créées, dont l'IP résoudra le DNS.

Lorsque l'une des instances échoue, un message à ce sujet est envoyé à une base de données spéciale.

En réponse, les procédures commencent: supprimer les enregistrements du DNS, démarrer une nouvelle instance et ajouter une nouvelle IP au DNS.

Remarque: C'est ainsi que le système fonctionnait dans le passé, maintenant tout est fondamentalement différent.

Tout est simple - il n'y a rien à casser. Mais lors d'un échec de masse, lorsque des milliers d'instances s'effondrent en même temps, un énorme Backlog apparaît dans la base de données à partir des messages à traiter.

Mais ça a empiré. Le plan de contrôle est un système distribué. En raison d'un bogue, nous avons reçu des doublons et des milliers d'enregistrements dans la base de données ont augmenté jusqu'à des centaines de milliers. Il est devenu très difficile de travailler avec cela.

Lorsqu'une défaillance se produit sur l'une des instances, tout le trafic passe presque instantanément aux machines survivantes et la charge double (dans l'exemple, pour plus de simplicité, il n'y a que deux zones d'accès).

Il n'y a pas assez de ressources, une instance en direct commence automatiquement à évoluer. Le processus prend un temps relativement long. Tout se passe en pointe et en même temps avec un grand nombre d'instances - les ressources libres de la zone de disponibilité s'épuisent. Le «combat» pour les ressources commence.

Dans le nord de la Virginie, l'automatisation n'a pas réussi à faire face à l'échec massif et les ingénieurs ont manuellement (à l'aide de scripts) rétabli le fonctionnement des services. Ces troubles sont rares. Au cours du débriefing, des questions se sont posées sur les causes de l'échec, ils ont décidé que la situation ne devait plus se répéter et que l'ensemble du service devait être changé.

Les huit modèles que je vais couvrir sont des réponses à certaines des questions.

Remarque. Il s'agit de notre expérience dans la conception de services, et non d'une sagesse universelle pour une utilisation généralisée. Les modèles sont utilisés dans des situations spécifiques.

— . AWS . — , . . — . !

Pour minimiser l'impact des échecs, beaucoup d'approches. L'un d'eux est de répondre à la question: "Comment puis-je m'assurer que les utilisateurs qui ne connaissent pas un problème n'en savent rien pendant une panne et pendant la récupération?"

Notre énorme Backlog reçoit non seulement des messages de plantage, mais aussi d'autres, par exemple, sur la mise à l'échelle ou le fait que quelqu'un lance un nouvel équilibreur. Ces messages doivent être isolés les uns des autres, en regroupant fonctionnellement: un groupe distinct de messages de récupération après une défaillance, en lançant séparément un nouvel équilibreur.

Supposons que dix utilisateurs aient remarqué un problème - l'un des nœuds de leurs équilibreurs est tombé. Les services fonctionnent en quelque sorte sur les ressources restantes, mais le problème se fait sentir.

Nous avons dix utilisateurs frustrés. Le onzième apparaît - il ne sait rien du problème, mais veut simplement un nouvel équilibreur. Si sa demande de mettre la file d'attente pour traitement, alors très probablement, il n'attendra pas. Alors que les autres procédures de traitement sont terminées, le délai de demande prendra fin. Au lieu de dix utilisateurs frustrés, nous en aurons onze.

Pour éviter cela, nous priorisons certaines demandes - nous plaçons les files d'attente en haut, par exemple, les demandes de nouvelles ressources. En cas d'échec de masse, un nombre relativement faible de ces demandes n'affectera pas le temps de récupération des ressources des autres clients. Mais dans le processus de récupération, nous limiterons le nombre d'utilisateurs impliqués dans le problème.

Travail à plein temps

La réponse aux rapports de problèmes est le lancement de procédures de récupération, en particulier, le travail avec DNS. Les défaillances de masse sont des charges de pointe énormes sur le plan de contrôle. Le deuxième motif aide le plan de contrôle à être plus stable et prévisible dans une telle situation.

Nous utilisons une approche appelée travail constant - travail permanent .

Par exemple, le DNS peut être rendu un peu plus intelligent: il vérifiera constamment les instances de l'équilibreur, qu'elles soient vivantes ou non. Le résultat sera un bitmap à chaque fois: l'instance répond - 1, morte - 0.

DNS vérifie les instances toutes les quelques secondes, que le système soit restauré après une panne de masse ou fonctionne normalement. Il fait le même travail - pas de pics, tout est prévisible et stable.

Autre exemple simplifié: nous voulons changer la configuration sur une grande flotte. Dans notre terminologie, une flotte est un groupe de machines virtuelles qui, ensemble, font un certain travail.

Nous plaçons les modifications de configuration dans le compartiment S3 et, toutes les 10 secondes (par exemple), nous transmettons toute cette configuration à notre parc de machines virtuelles. Deux points importants.

Nous le faisons régulièrement et ne violons jamais la règle. Si vous choisissez un segment de 10 secondes, ne poussez que de cette façon, quelle que soit la situation.
Nous donnons toujours la configuration entière , qu'elle ait changé ou non. Le plan de données (machines virtuelles) décide lui-même quoi en faire. Nous ne poussons pas le delta. Il peut devenir très important avec des perturbations ou des changements massifs. Potentiellement, cela peut contribuer à l'instabilité et à l'imprévisibilité.

Lorsque nous effectuons une sorte de travail permanent, nous payons plus pour cela. Par exemple, 100 machines virtuelles demandent une configuration chaque seconde. Il en coûte environ 1200 $ par an. Ce montant est essentiellement inférieur au salaire d'un programmeur, à qui l'on peut confier le développement d'un plan de contrôle avec une approche classique - une réaction à un échec et la répartition des seuls changements de configuration.

Si vous modifiez la configuration toutes les quelques secondes, comme dans l'exemple, cela est lent. Mais dans de nombreux cas, un changement de configuration ou le lancement de services prend quelques minutes - quelques secondes ne résolvent rien.

Les secondes sont importantes pour les services dans lesquels la configuration doit changer instantanément, par exemple lors de la modification des paramètres VPC. Ici, le "travail permanent" n'est pas applicable. Ce n'est qu'un modèle, pas une règle. Si cela ne fonctionne pas dans votre cas, ne l'utilisez pas.

Mise à l'échelle préliminaire

Dans notre exemple, lorsque l'instance d'équilibrage se bloque, la deuxième instance survivante reçoit la charge doublant presque immédiatement et commence à évoluer. En cas d'échec massif, il consomme une énorme quantité de ressources. Le troisième modèle aide à contrôler ce processus - à l' échelle à l'avance .

Dans le cas de deux zones de disponibilité, nous évoluons lorsque nous éliminons moins de 50%.

Si tout est fait à l'avance, en cas d'échec, les instances survivantes de l'équilibreur sont prêtes à accepter un trafic doublé.

Auparavant, nous évoluions uniquement avec une utilisation élevée, par exemple 80%, et maintenant à 45%. Le système est inactif la plupart du temps et devient plus cher. Mais nous sommes prêts à accepter cela et à utiliser activement le modèle, car il s'agit d'une assurance. Vous devez payer une assurance, mais en cas de problème grave, la victoire couvre toutes les dépenses. Si vous décidez d'utiliser le modèle, calculez tous les risques et le prix à l'avance.

Architecture cellulaire

Il existe deux façons de construire et de mettre à l'échelle des services: le monolithe et la structure en nid d'abeilles (à base de cellules).

Le monolithe se développe et se développe comme un seul grand récipient. Nous ajoutons des ressources, le système gonfle, nous nous heurtons à différentes limites, les caractéristiques linéaires deviennent non linéaires et entrent en saturation, et le «rayon de souffle» du système - tout le système.

Si le monolithe est mal testé, il augmente la probabilité de surprises - «inconnues inconnues». Mais un grand monolithe ne peut pas être entièrement testé. Parfois, pour cela, vous devrez créer une zone d'accès distincte, par exemple, pour un service populaire qui est construit comme un monolithe dans la zone d'accès (c'est beaucoup de centres de données). En plus de créer en quelque sorte une énorme charge de test similaire à celle actuelle, cela est impossible d'un point de vue financier.

Par conséquent, dans la plupart des cas, nous utilisons une architecture cellulaire - une configuration dans laquelle un système est construit à partir de cellules de taille fixe. En ajoutant des cellules, nous le mettons à l'échelle.

L'architecture cellulaire est populaire dans le cloud AWS. Il aide à isoler les défauts et à réduire le rayon de souffle.à une ou plusieurs cellules. Nous pouvons tester pleinement les cellules de taille moyenne, ce qui réduit considérablement les risques.

Une approche similaire est utilisée dans la construction navale: la coque d'un navire ou d'un navire est divisée par des cloisons en compartiments. En cas de trou, un ou plusieurs compartiments sont inondés, mais le navire ne coule pas. Oui, cela n'a pas aidé le Titanic, mais nous rencontrons rarement des problèmes d'iceberg.

Je vais illustrer l'application de l'approche maillée en utilisant le service de formes simples comme exemple. Ce n'est pas un service AWS, je l'ai conçu moi-même. Il s'agit d'un ensemble d'API simples pour travailler avec des formes géométriques simples. Vous pouvez créer une instance d'une forme géométrique, demander le type d'une forme par son identifiant ou compter toutes les instances d'un type donné. Par exemple, put(triangle)un objet "triangle" avec un id est créé sur une demande .getShape(id)renvoie le type "triangle", "cercle" ou "losange".

Pour rendre un service trouble, il doit être utilisé par différents utilisateurs en même temps. Faisons-le multi-locataire.

Ensuite, vous devez trouver un moyen de partitionner - pour séparer les chiffres en cellules. Il existe plusieurs options pour choisir la clé de partition. Le plus simple est de forme géométrique : tous les losanges dans la première cellule, les cercles dans la seconde, les triangles dans la troisième.

Cette méthode a des avantages et des inconvénients.

S'il y a sensiblement moins de cercles que les autres figures, alors la cellule correspondante restera sous-utilisée (distribution inégale).
Certaines demandes d'API sont faciles à implémenter. Par exemple, en comptant tous les objets dans la deuxième cellule, nous trouvons le nombre de cercles dans le système.
D'autres requêtes sont plus compliquées. Par exemple, pour trouver une forme géométrique par id, vous devez parcourir toutes les cellules.

La deuxième façon consiste à utiliser l' id des objets par plages : le premier millier d'objets dans la première cellule, le second dans la seconde. La distribution est donc plus uniforme, mais il y a d'autres difficultés. Par exemple, pour compter tous les triangles, vous devez utiliser la méthode scatter/gather: nous distribuons les demandes dans chaque cellule, il compte les triangles à l'intérieur de lui-même, puis il recueille les réponses, résume et produit le résultat.

La troisième voie - la division des locataires(aux utilisateurs). Ici, nous sommes confrontés à un problème classique. Il y a généralement beaucoup de «petits» utilisateurs dans le cloud qui essaient quelque chose et ne chargent pratiquement pas le service. Il y a des utilisateurs de mastodontes. Ils sont peu nombreux, mais ils consomment une énorme quantité de ressources. Ces utilisateurs ne rentreront jamais dans aucune cellule. Vous devez trouver des moyens délicats de les répartir entre de nombreuses cellules.

Il n'y a pas de moyen idéal, chaque service est individuel. La bonne nouvelle est que la sagesse du monde fonctionne ici - couper du bois de chauffage est plus pratique le long des fibres, plutôt que de les couper en travers. Dans de nombreux services, ces «fibres» sont plus ou moins évidentes. Ensuite, vous pouvez expérimenter et trouver la clé de partition optimale.

Les cellules sont interconnectées (quoique faiblement). Par conséquent, il doit y avoir un niveau de connexion. Elle est souvent appelée couche de routage ou de mappage. Il est nécessaire de comprendre à quelles cellules envoyer des demandes spécifiques. Ce niveau doit être aussi simple que possible. Essayez de ne pas y mettre de logique commerciale.

La question se pose de la taille des cellules: petite - mauvaise, grande - aussi mauvaise. Il n'y a pas de conseil universel - décidez en fonction de la situation.

Dans le cloud AWS, nous utilisons des cellules logiques et physiques de différentes tailles. Il y a des services régionaux avec une grande taille de cellule, il y a des services de zone, où les cellules sont plus petites.

Remarque. J'ai parlé des microcellules à Saint Highload ++ Online début avril de cette année. J'y ai discuté en détail un exemple de l'utilisation spécifique de ce modèle dans notre service principal Amazon EBS.

Multi-locataire

Lorsqu'un utilisateur lance un nouvel équilibreur, il reçoit des instances dans chaque zone de disponibilité. Que les ressources soient utilisées ou non, elles sont allouées et appartiennent exclusivement à ce locataire du cloud.

Pour AWS, cette approche est inefficace, car l'utilisation des ressources de service est en moyenne très faible. Cela affecte le coût. Pour les utilisateurs du cloud, ce n'est pas une solution flexible. Il ne peut pas s'adapter à des conditions changeant rapidement, par exemple, pour fournir des ressources avec une charge augmentée de manière inattendue dans les plus brefs délais.

CLB a été le premier équilibreur dans le cloud Amazon. Les services utilisent aujourd'hui une approche multi-locataire, telle que NLB (Network Load Balancer). La base, le "moteur" de ces services réseau est HyperPlane. Il s'agit d'un parc de machines virtuelles (nœuds) interne, invisible pour les utilisateurs finaux.

Avantages de l' approche multi-locataire ou du cinquième modèle.

La tolérance aux pannes est fondamentalement plus élevée . Dans HyperPlane, un grand nombre de nœuds sont déjà en cours d'exécution et attendent la charge. Les nœuds connaissent l'état les uns des autres - lorsque certaines ressources échouent, la charge est instantanément répartie entre les autres. Les utilisateurs ne remarquent même pas les accidents de masse.
Protection contre les pics de charge . Les locataires vivent leur propre vie et leurs charges ne sont généralement pas en corrélation. La charge moyenne totale sur HyperPlane est assez fluide.
L'utilisation de ces services est fondamentalement meilleure . Par conséquent, offrant de meilleures performances, ils sont moins chers.

Ça sonne cool! Mais l'approche multi-locataire présente des inconvénients. Sur la figure, la flotte HyperPlane avec trois locataires (losanges, cercles et triangles), répartis sur tous les nœuds .

Cela pose le problème classique du voisin bruyant: l'action destructrice du locataire, qui génère un trafic ultra-élevé ou mauvais, affectera potentiellement tous les utilisateurs.

Le «rayon de souffle» dans un tel système concerne tous les locataires. La probabilité d'un «voisin bruyant» destructeur dans la véritable zone de disponibilité AWS n'est pas élevée. Mais nous devons toujours être préparés au pire. Nous nous défendons en utilisant une approche maillée - nous sélectionnons des groupes de nœuds comme cellules. Dans ce contexte, nous les appelons des éclats. Cellules, éclats, partitions - ici, c'est la même chose.

Dans cet exemple, un losange, en tant que «voisin bruyant», n'affectera qu'un seul locataire - un triangle. Mais le triangle sera très douloureux. Pour lisser l'effet, appliquez le sixième motif - mélanger le sharding.

Mélange de sharding

Nous distribuons au hasard les locataires aux nœuds. Par exemple, un losange atterrit sur 1, 3 et 6 nœuds, et un triangle sur 2, 6 et 8. Nous avons 8 nœuds et un fragment de taille 3.

Ici, la combinatoire simple fonctionne. Avec une probabilité de 54%, il n'y aura qu'une seule intersection entre les locataires.

Le «voisin bruyant» n'affectera qu'un seul locataire, et non la totalité de la charge, mais seulement 30%.

Considérons une configuration proche du réel - 100 nœuds, taille d'éclat 5. Avec une probabilité de 77%, il n'y aura aucune intersection du tout.

Le partage aléatoire peut réduire considérablement le «rayon de souffle». Cette approche est utilisée dans de nombreux services AWS.

«Une petite flotte entraîne une grande flotte, et non l'inverse»

Lors de la récupération d'une panne de masse, nous mettons à jour la configuration de nombreux composants. Dans ce cas, une question typique est de pousser ou de remplacer une configuration modifiée? Qui est l'initiateur des changements: la source contenant les changements de configuration ou ses consommateurs? Mais ces questions sont fausses. La bonne question est quelle flotte est plus grande?

Prenons une situation simple: un grand parc de machines virtuelles frontales et un certain nombre de backends.

Nous utilisons une approche maillée - des groupes d'instances frontales fonctionneront avec certains backends. Pour ce faire, déterminez le routage - mappage des backends et des frontends travaillant avec eux.

Le routage statique ne convient pas. Les algorithmes de hachage ne fonctionnent pas bien dans les défaillances de masse, lorsque vous devez modifier rapidement la plupart des itinéraires. Il est donc préférable d'utiliserroutage dynamique . À côté des grandes flottes d'instances frontales et principales, nous mettons un petit service qui ne traitera que du routage. Il connaîtra et assignera un mappage de backend et de frontend à tout moment.

Supposons que nous ayons eu un gros crash, de nombreuses instances frontales sont tombées. Ils commencent à récupérer massivement et presque simultanément la configuration de mappage des demandes du service de routage.

Un petit service de routage est bombardé d'un grand nombre de demandes. Il ne supportera pas la charge, dans le meilleur des cas, elle se dégradera et dans le pire des cas il mourra.

Par conséquent, il est correct de ne pas demander de modifications de configuration à un petit service, mais plutôt de construire votre système pour que le «bébé» lui-mêmeinitié des changements de configuration vers une large flotte d'instances .

Nous utilisons le modèle du travail constant. Un petit service de routage enverra la configuration à toutes les instances de flotte frontales toutes les quelques secondes. Il ne pourra jamais surcharger un grand service. Le septième motif aide à améliorer la stabilité et la résilience .

Les sept premiers modèles améliorent le système. Ce dernier modèle fonctionne différemment.

Chute de charge

Voici un graphique classique du retard en fonction de la charge. Sur le côté droit du graphique se trouve le «genou», quand à des charges extrêmement élevées, même une petite augmentation entraîne une augmentation significative de la latence.

En mode normal, nous ne prenons jamais nos services du bon côté de l'horaire. Un moyen simple de contrôler cela consiste à ajouter des ressources à temps. Mais nous nous préparons à tout problème. Par exemple, nous pouvons nous déplacer vers le côté droit du graphique en récupérant d'une défaillance de masse.

Nous avons mis le délai d'attente du client sur le graphique. Tout le monde peut être un client, par exemple, un autre composant de notre service. Pour simplifier, nous dessinons un graphique de retard de 50 centile.

Nous sommes ici face à une situation appelée brownout . Vous connaissez peut-être le terme de panne d' électricité lorsque l'électricité est coupée dans la ville. Brownout, c'est quand quelque chose fonctionne, mais est tellement mauvais et lent que, comptez, cela ne fonctionne pas du tout.

Regardons le brownout de la zone brune. Le service a reçu une demande du client, l'a traitée et a renvoyé le résultat. Cependant, dans la moitié des cas, les clients ont déjà expiré et personne n'attend le résultat. Dans l'autre moitié, le résultat revient plus rapidement que le délai d'attente, mais dans un système lent, cela prend trop de temps.

Nous avons été confrontés à un double problème: nous sommes déjà surchargés et sommes du bon côté du calendrier, mais en même temps nous «réchauffons l'air», faisant beaucoup de travail inutile. Comment éviter cela?

Trouvez le «genou» - le point d'inflexion sur le graphique . Nous mesurons ou estimons théoriquement.

Drop trafic qui nous oblige à aller à droite du point d'inflexion .

Nous devons simplement ignorer une partie des demandes. Nous n'essayons même pas de les traiter, mais renvoyons immédiatement une erreur au client. Même avec une surcharge, nous pouvons nous permettre cette opération - elle est «bon marché». Les demandes ne sont pas satisfaites, la disponibilité globale du service est réduite. Bien que les demandes rejetées soient traitées tôt ou tard après une ou plusieurs tentatives des clients.

Dans le même temps, une autre partie des requêtes est traitée avec une faible latence garantie. En conséquence, nous ne faisons pas de travail inutile, et ce que nous faisons, nous le faisons bien.

Brève compression des modèles de conception de systèmes pour échec

Isolement et régulation . Parfois, il est logique de prioriser certains types de requêtes. Par exemple, avec un volume relativement faible de demandes de création de nouvelles ressources, elles peuvent être placées en tête de file d'attente. Il est important que cela n'empiète pas sur les autres utilisateurs. En cas de panne massive, les utilisateurs qui attendent la récupération de leurs ressources ne ressentiront pas de différence significative.

Travail à plein temps . Réduisez ou éliminez complètement la commutation des modes de service. Un mode, qui fonctionne de manière stable et constante, quelles que soient les situations d'urgence ou de travail, améliore fondamentalement la stabilité et la prévisibilité du plan de contrôle.

Mise à l'échelle préliminaire. Échelle à l'avance avec des valeurs d'élimination plus faibles. Vous devrez payer un peu plus pour cela, mais c'est une assurance qui porte ses fruits lors de graves défaillances du système.

Architecture cellulaire . De nombreuses cellules à couplage lâche sont préférées à un monolithe. L'approche par maillage réduit le «rayon de souffle» et la probabilité d'erreurs surprises.

L'approche multi-locataire améliore considérablement l'utilisation du service, réduit son coût et réduit le "rayon de souffle".

Mélange de sharding . Il s'agit d'une approche qui s'applique aux services multi-locataires. Il vous permet en outre de contrôler le "rayon de souffle".

«Une petite flotte entraîne une grande flotte, et non l'inverse». Nous essayons de créer des services afin que les petits services initient des changements dans les grandes configurations. Nous l'utilisons souvent en conjonction avec un modèle de charge constante.

Abandonner la charge . Dans les situations d'urgence, nous essayons de ne faire que du travail utile et de bien le faire. Pour ce faire, nous jetons une partie de la charge, que nous ne pouvons toujours pas gérer.

— , Saint HighLoad++ Online. -- , Q&A-, , . - . , - .

telegram- @HighLoadChannel — , .

Houston nous avons un problème. Échec de la conception du système