Vous avez passé des mois à repenser votre monolithe en microservices, et finalement tout le monde s'est réuni pour appuyer sur le bouton. Vous accédez à la première page Web... et rien ne se passe. Vous le rechargez - et encore une fois rien de bon, le site est tellement lent qu'il ne répond pas pendant plusieurs minutes. Ce qui s'est passé?
Dans son exposé, Jimmy Bogard procédera à une « autopsie » d’un véritable désastre de microservice. Il montrera les problèmes de modélisation, de développement et de production qu'il a découverts, et comment son équipe a lentement transformé le nouveau monolithe distribué en l'image finale de la raison. Bien qu'il soit impossible d'éviter complètement les erreurs de conception, vous pouvez au moins identifier les problèmes dès le début du processus de conception pour garantir que le produit final devienne un système distribué fiable.
Bonjour à tous, je m'appelle Jimmy et aujourd'hui, vous allez découvrir comment éviter les méga-catastrophes lors de la création de microservices. C'est l'histoire d'une entreprise pour laquelle j'ai travaillé pendant environ un an et demi pour empêcher son navire d'entrer en collision avec un iceberg. Pour raconter correctement cette histoire, nous devrons remonter le temps et parler de l'endroit où cette entreprise a commencé et de la façon dont son infrastructure informatique s'est développée au fil du temps. Pour protéger les noms des innocents dans cette catastrophe, j'ai changé le nom de cette société pour Bell Computers. La diapositive suivante montre à quoi ressemblait l'infrastructure informatique de ces entreprises au milieu des années 90. Il s'agit d'une architecture typique d'un grand serveur mainframe HP Tandem universel et tolérant aux pannes pour l'exploitation d'un magasin de matériel informatique.
Ils avaient besoin de créer un système pour gérer toutes les commandes, ventes, retours, catalogues de produits et base de clients, ils ont donc choisi la solution mainframe la plus courante à l'époque. Ce système géant contenait toutes les informations sur l'entreprise, tout ce qui était possible, et chaque transaction était effectuée via ce mainframe. Ils gardaient tous leurs œufs dans le même panier et pensaient que c’était normal. La seule chose qui n'est pas incluse ici, ce sont les catalogues de vente par correspondance et les commandes par téléphone.
Au fil du temps, le système est devenu de plus en plus grand et une énorme quantité de déchets s'y est accumulée. De plus, COBOL n'est pas le langage le plus expressif au monde, le système a donc fini par être un gros morceau de ferraille monolithique. En 2000, ils ont constaté que de nombreuses entreprises disposaient de sites Web sur lesquels elles exerçaient absolument toutes leurs activités et ont décidé de créer leur premier site Web commercial point-com.
La conception initiale était plutôt jolie et consistait en un site de niveau supérieur bell.com et un certain nombre de sous-domaines pour des applications individuelles : catalog.bell.com, comptes.bell.com, commandes.bell.com, recherche de produits search.bell. com. Chaque sous-domaine utilisait le framework ASP.Net 1.0 et ses propres bases de données, et ils communiquaient tous avec le backend du système. Cependant, toutes les commandes continuaient d'être traitées et exécutées au sein d'un seul énorme ordinateur central, dans lequel tous les déchets restaient, mais le front-end était constitué de sites Web distincts avec des applications individuelles et des bases de données distinctes.
La conception du système semblait donc ordonnée et logique, mais le système réel était tel que présenté dans la diapositive suivante.
Tous les éléments s'appelaient les uns aux autres, accédaient aux API, aux DLL tierces intégrées, etc. Il arrivait souvent que les systèmes de contrôle de version récupéraient le code de quelqu'un d'autre, le plaçaient dans le projet, puis tout se cassait. MS SQL Server 2005 utilisait le concept de serveurs de liens, et bien que je n'aie pas montré les flèches sur la diapositive, chacune des bases de données communiquait également entre elles, car il n'y a rien de mal à créer des tables basées sur des données obtenues à partir de plusieurs bases de données.
Comme il y avait désormais une certaine séparation entre les différentes zones logiques du système, cela est devenu des taches de saleté distribuées, le plus gros déchet restant toujours dans le backend du mainframe.
Le plus drôle, c'est que cet ordinateur central a été construit par des concurrents de Bell Computers et était toujours entretenu par leurs consultants techniques. Convaincue des performances peu satisfaisantes de ses applications, l’entreprise décide de s’en débarrasser et de repenser le système.
L'application existante était en production depuis 15 ans, ce qui constitue un record pour les applications basées sur ASP.Net. Le service a accepté des commandes du monde entier et les revenus annuels de cette application unique ont atteint un milliard de dollars. Une partie importante des bénéfices a été générée par le site Web bell.com. Lors des Black Fridays, le nombre de commandes passées via le site a atteint plusieurs millions. Cependant, l'architecture existante ne permettait aucun développement, puisque les interconnexions rigides des éléments du système ne permettaient pratiquement aucune modification du service.
Le problème le plus grave était l’impossibilité de passer une commande depuis un pays, de la payer dans un autre et de l’envoyer dans un troisième, malgré le fait qu’un tel système commercial soit très courant dans les entreprises mondiales. Le site Web existant ne permettait rien de tel, ils ont donc dû accepter et passer ces commandes par téléphone. Cela a amené l’entreprise à réfléchir de plus en plus à un changement d’architecture, notamment en passant aux microservices.
Ils ont fait preuve d’intelligence en s’intéressant à d’autres entreprises pour voir comment elles avaient résolu un problème similaire. L'une de ces solutions était l'architecture de service Netflix, composée de microservices connectés via une API et une base de données externe.
La direction de Bell Computers a décidé de construire une telle architecture, en adhérant à certains principes de base. Premièrement, ils ont éliminé la duplication des données en utilisant une approche de base de données partagée. Aucune donnée n’était envoyée ; au contraire, tous ceux qui en avaient besoin devaient s’adresser à une source centralisée. Viennent ensuite l'isolement et l'autonomie : chaque service est indépendant des autres. Ils ont décidé d'utiliser l'API Web pour absolument tout : si vous souhaitiez obtenir des données ou apporter des modifications à un autre système, tout se faisait via l'API Web. La dernière grande nouveauté était un nouveau mainframe appelé "Bell on Bell", par opposition au mainframe "Bell" basé sur le matériel des concurrents.
Ainsi, en 18 mois, ils ont construit le système autour de ces principes fondamentaux et l’ont amené à la pré-production. De retour au travail après le week-end, les développeurs se sont réunis et ont allumé tous les serveurs auxquels le nouveau système était connecté. 18 mois de travail, des centaines de développeurs, le matériel Bell le plus moderne - et aucun résultat positif ! Cela a déçu beaucoup de gens car ils ont utilisé ce système à plusieurs reprises sur leurs ordinateurs portables et tout allait bien.
Ils ont eu la sagesse de consacrer tout leur argent à la résolution de ce problème. Ils ont installé les racks de serveurs les plus modernes avec des commutateurs, utilisé de la fibre optique gigabit, le matériel serveur le plus puissant avec une quantité folle de RAM, tout connecté, configuré - et encore une fois, rien ! Ensuite, ils ont commencé à soupçonner que la raison pourrait être des délais d'attente, ils sont donc allés dans tous les paramètres Web, tous les paramètres de l'API et ont mis à jour toute la configuration du délai d'attente aux valeurs maximales, de sorte que tout ce qu'ils pouvaient faire était de s'asseoir et d'attendre que quelque chose se passe. au site. Ils ont attendu et attendu et attendu 9 minutes et demie jusqu'à ce que le site Web soit enfin chargé.
Après cela, ils se sont rendu compte que la situation actuelle nécessitait une analyse approfondie et ils nous ont invités. La première chose que nous avons découvert, c'est qu'au cours des 18 mois de développement, pas un seul véritable « micro » n'a été créé - tout n'a fait que s'agrandir. Après cela, nous avons commencé à rédiger une autopsie, également appelée « rétrospective » ou « triste rétrospective », également connue sous le nom de « tempête de reproches », semblable à une « tempête de cerveaux », pour comprendre la cause du désastre.
Nous avions plusieurs indices, dont une saturation complète du trafic au moment de l’appel de l’API. Lorsque vous utilisez une architecture de service monolithique, vous pouvez immédiatement comprendre ce qui n'a pas fonctionné, car vous disposez d'une trace de pile unique qui rapporte tout ce qui a pu provoquer l'échec. Dans le cas où plusieurs services accèdent simultanément à la même API, il n'y a aucun moyen de suivre la trace sauf d'utiliser des outils supplémentaires de surveillance du réseau comme WireShark, grâce auxquels vous pouvez examiner une seule requête et découvrir ce qui s'est passé lors de sa mise en œuvre. Nous avons donc pris une page Web et avons passé près de 2 semaines à assembler les pièces du puzzle, à y lancer une variété d'appels et à analyser les conséquences de chacune d'elles.
Regarde cette image. Cela montre qu'une requête externe incite le service à effectuer de nombreux appels internes qui reviennent. Il s'avère que chaque appel interne effectue des sauts supplémentaires afin de pouvoir répondre indépendamment à cette demande, car il ne peut se tourner vers aucun autre endroit pour obtenir les informations nécessaires. Cette image ressemble à une cascade d'appels dénuée de sens, car la requête externe appelle des services supplémentaires, qui appellent d'autres services supplémentaires, et ainsi de suite, presque à l'infini.
La couleur verte dans ce diagramme montre un demi-cercle dans lequel les services s'appellent - le service A appelle le service B, le service B appelle le service C, et il appelle à nouveau le service A. En conséquence, nous obtenons une « impasse distribuée ». Une seule requête créait un millier d'appels d'API réseau, et comme le système n'avait pas de tolérance aux pannes ni de protection contre les boucles intégrées, la requête échouerait si même l'un de ces appels d'API échouait.
Nous avons fait quelques calculs. Chaque appel API avait un SLA ne dépassant pas 150 ms et une disponibilité de 99,9 %. Une requête provoquait 200 appels différents, et dans le meilleur des cas, la page pouvait s'afficher en 200 x 150 ms = 30 secondes. Naturellement, ce n’était pas bon. En multipliant la disponibilité de 99,9 % par 200, nous obtenons une disponibilité de 0 %. Il s’avère que cette architecture était vouée à l’échec dès le début.
Nous avons demandé aux développeurs comment ils n'avaient pas réussi à reconnaître ce problème après 18 mois de travail ? Il s'est avéré qu'ils ne comptaient que le SLA pour le code qu'ils exécutaient, mais si leur service appelait un autre service, ils ne comptaient pas cette fois dans leur SLA. Tout ce qui était lancé au sein d'un processus respectait la valeur de 150 ms, mais l'accès à d'autres processus de service augmentait plusieurs fois le délai total. La première leçon apprise était : « Contrôlez-vous votre SLA, ou est-ce que le SLA vous contrôle ? » Dans notre cas, c'était ce dernier.
La prochaine chose que nous avons découverte, c'est qu'ils connaissaient le concept d'idées fausses sur l'informatique distribuée, formulées par Peter Deitch et James Gosling, mais qu'ils en ignoraient la première partie. Il affirme que les affirmations « le réseau est fiable », « latence nulle » et « débit infini » sont des idées fausses. D'autres idées fausses incluent les affirmations « le réseau est sécurisé », « la topologie ne change jamais », « il n'y a toujours qu'un seul administrateur », « le coût du transfert de données est nul » et « le réseau est homogène ».
Ils ont commis une erreur car ils ont testé leur service sur des machines locales et ne se sont jamais connectés à des services externes. Lors du développement local et de l’utilisation d’un cache local, ils n’ont jamais rencontré de sauts de réseau. Au cours des 18 mois de développement, ils ne se sont jamais demandé ce qui pourrait arriver si les services externes étaient affectés.
Si vous regardez les limites des services dans l’image précédente, vous pouvez voir qu’elles sont toutes incorrectes. Il existe de nombreuses sources qui donnent des conseils sur la manière de définir les limites des services, et la plupart le font mal, comme Microsoft sur la diapositive suivante.
Cette image provient du blog MS sur le sujet « Comment créer des microservices ». Cela montre une application Web simple, un bloc de logique métier et une base de données. La demande vient directement, il y a probablement un serveur pour le web, un serveur pour l'entreprise et un pour la base de données. Si vous augmentez le trafic, la situation changera un peu.
Voici un équilibreur de charge pour répartir le trafic entre deux serveurs web, un cache situé entre le service web et la logique métier, et un autre cache entre la logique métier et la base de données. C’est exactement l’architecture utilisée par Bell pour son application d’équilibrage de charge et de déploiement bleu/vert au milieu des années 2000. Jusqu'à un certain temps, tout fonctionnait bien, puisque ce schéma était destiné à une structure monolithique.
L'image suivante montre comment MS recommande de passer d'un monolithe aux microservices - en divisant simplement chacun des services principaux en microservices distincts. C'est lors de la mise en œuvre de ce stratagème que Bell a commis une erreur.
Ils ont divisé tous leurs services en différents niveaux, chacun composé de nombreux services individuels. Par exemple, le service Web comprenait des microservices pour le rendu du contenu et l'authentification, le service de logique métier était constitué de microservices pour le traitement des commandes et des informations sur les comptes, la base de données était divisée en un ensemble de microservices avec des données spécialisées. Le Web, la logique métier et la base de données étaient des services sans état.
Cependant, cette image était complètement fausse car elle ne cartographiait aucune unité commerciale en dehors du cluster informatique de l’entreprise. Ce système ne prenait en compte aucun lien avec le monde extérieur, il n'était donc pas clair comment, par exemple, obtenir des analyses commerciales tierces. Je constate qu'ils ont également inventé plusieurs services simplement pour développer la carrière d'employés individuels qui cherchaient à gérer le plus de personnes possible afin d'en tirer plus d'argent.
Ils pensaient que passer aux microservices était aussi simple que de prendre leur infrastructure de couche physique interne à N niveaux et d’y coller Docker. Jetons un coup d'œil à ce à quoi ressemble l'architecture traditionnelle à N niveaux.
Il se compose de 4 niveaux : le niveau de l'interface utilisateur de l'interface utilisateur, le niveau de la logique métier, le niveau d'accès aux données et la base de données. Plus progressiste est le DDD (Domain-Driven Design), ou architecture orientée logiciel, où les deux niveaux intermédiaires sont des objets de domaine et un référentiel.
J'ai essayé d'examiner différents domaines de changement, différents domaines de responsabilité dans cette architecture. Dans une application typique à N niveaux, différentes zones de changement sont classées et imprègnent la structure verticalement de haut en bas. Il s'agit des paramètres de catalogue, de configuration effectués sur des ordinateurs individuels et des vérifications de paiement, qui ont été gérées par mon équipe.
La particularité de ce schéma est que les limites de ces domaines de changement affectent non seulement le niveau de logique métier, mais s'étendent également à la base de données.
Voyons ce que signifie être un service. Il existe 6 propriétés caractéristiques d'une définition de service - il s'agit d'un logiciel qui :
- créé et utilisé par une organisation spécifique ;
- est responsable du contenu, du traitement et/ou de la fourniture d'un certain type d'informations au sein du système ;
- peut être construit, déployé et exécuté de manière indépendante pour répondre à des besoins opérationnels spécifiques ;
- communique avec les consommateurs et d'autres services, en fournissant des informations basées sur des accords ou des garanties contractuelles ;
- se protège contre les accès non autorisés et ses informations contre la perte ;
- gère les échecs de manière à ce qu’ils n’entraînent pas de dommages aux informations.
Toutes ces propriétés peuvent être exprimées en un seul mot « autonomie ». Les services fonctionnent indépendamment les uns des autres, satisfont à certaines restrictions et définissent des contrats sur la base desquels les personnes peuvent recevoir les informations dont elles ont besoin. Je n'ai pas évoqué de technologies spécifiques dont l'utilisation va de soi.
Examinons maintenant la définition des microservices :
- un microservice est de petite taille et conçu pour résoudre un problème spécifique ;
- Le microservice est autonome ;
- Lors de la création d’une architecture de microservices, la métaphore de l’urbanisme est utilisée. C'est la définition du livre de Sam Newman, Building Microservices.
La définition du contexte limité est tirée du livre Domain-Driven Design d'Eric Evans. Il s'agit d'un modèle de base dans DDD, un centre de conception d'architecture qui travaille avec des modèles architecturaux volumétriques, les divisant en différents contextes délimités et définissant explicitement les interactions entre eux.
En termes simples, un contexte limité indique la portée dans laquelle un module particulier peut être utilisé. Dans ce contexte se trouve un modèle logiquement unifié qui peut être vu, par exemple, dans votre domaine d'activité. Si vous demandez « qui est un client » au personnel impliqué dans les commandes, vous obtiendrez une définition, si vous demandez aux personnes impliquées dans les ventes, vous en obtiendrez une autre, et les interprètes vous donneront une troisième définition.
Ainsi, Bounded Context dit que si nous ne pouvons pas donner une définition claire de ce qu'est un consommateur de nos services, définissons les limites dans lesquelles nous pouvons parler de la signification de ce terme, puis définissons les points de transition entre ces différentes définitions. Autrement dit, si nous parlons d'un client du point de vue de la passation de commandes, cela signifie ceci et cela, et si du point de vue des ventes, cela signifie ceci et cela.
La définition suivante d'un microservice est l'encapsulation de tout type d'opérations internes, empêchant la « fuite » des composants du processus de travail dans l'environnement. Vient ensuite la « définition de contrats explicites pour les interactions externes, ou communications externes », qui est représentée par l’idée de contrats revenant des SLA. La dernière définition est la métaphore d'une cellule, ou cellule, qui désigne l'encapsulation complète d'un ensemble d'opérations au sein d'un microservice et la présence de récepteurs pour la communication avec le monde extérieur.
Nous avons donc dit aux gars de Bell Computers : « Nous ne pouvons pas réparer le chaos que vous avez créé parce que vous n'avez tout simplement pas l'argent pour le faire, mais nous allons réparer un seul service pour que tout fonctionne. sens." À ce stade, je vais commencer par vous expliquer comment nous avons corrigé notre seul service afin qu'il réponde aux demandes plus rapidement que 9 minutes et demie.
22:30 min
A suivre très prochainement...
Un peu de publicité
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com