Les nuages sont comme une boîte magique - vous demandez ce dont vous avez besoin et les ressources apparaissent simplement de nulle part. Machines virtuelles, bases de données, réseau - tout cela n'appartient qu'à vous. Il existe d'autres locataires du cloud, mais dans votre univers, vous êtes le seul dirigeant. Vous êtes sûr que vous recevrez toujours les ressources nécessaires, vous ne comptez avec personne et vous déterminez de manière indépendante ce que sera le réseau. Comment est cette magie qui fait que le cloud alloue élastiquement les ressources et isole complètement les locataires les uns des autres?
AWS Cloud est un système méga-sophistiqué qui évolue depuis 2006. Une partie de ce développement a été trouvée par
Vasily Pantyukhin , architecte d'Amazon Web Services. En tant qu'architecte, il voit de l'intérieur non seulement le résultat final, mais aussi les défis qu'AWS surmonte. Plus la compréhension du système est grande, plus la confiance est grande. Par conséquent, Vasily partagera les secrets des services cloud AWS. Sous la coupe se trouve l'appareil pour les serveurs physiques AWS, l'évolutivité flexible des bases de données, une base de données Amazon personnalisée et des méthodes pour améliorer les performances des machines virtuelles tout en réduisant leur prix. La connaissance des approches architecturales d'Amazon vous aidera à mieux utiliser les services AWS et peut fournir de nouvelles idées pour créer vos propres solutions.
À propos du président: Vasily Pantyukhin ( Hen ) a commencé en tant qu'administrateur Unix dans les sociétés in.ru, a passé 6 ans à travailler dans de grandes glandes Sun Microsystem, et pendant 11 ans, il a prêché la concentration des données du monde dans EMC. Naturellement, il est devenu un cloud privé et, en 2017, il est devenu un cloud public. Maintenant avec des conseils techniques, il aide à vivre et à se développer dans le cloud AWS.
Avis de non-responsabilité: tout ce qui suit est l'opinion personnelle de Vasily et cela peut ne pas coïncider avec la position d'Amazon Web Services. Une vidéo du reportage sur la base duquel l'article a été créé est disponible sur notre chaîne YouTube.Pourquoi je parle d'un appareil Amazon
Ma première voiture était avec une «poignée» - sur une boîte de vitesses manuelle. C'était génial à cause du sentiment que je pouvais contrôler la machine et la contrôler complètement. J'ai aussi aimé que je comprenne au moins à peu près le principe de son travail. Naturellement, j'ai imaginé le boîtier de manière très primitive - à peu près comme une boîte de vitesses sur un vélo.
Tout était merveilleux, sauf une chose - debout dans les embouteillages. Il semble que vous soyez assis et ne faites rien, mais vous changez constamment de vitesse, appuyez sur l'embrayage, le gaz, le frein - vous en avez vraiment marre. Le problème des embouteillages a été partiellement résolu lorsqu'une machine est apparue sur la machine de la famille. Au volant, il était temps de penser à quelque chose, d'écouter un livre audio.
Un mystère est apparu dans ma vie, car j'ai généralement cessé de comprendre le fonctionnement de ma voiture. Une voiture moderne est un appareil complexe. La voiture s'adapte simultanément à des dizaines de paramètres différents: pression du gaz, frein, style de conduite, qualité de la route. Je ne comprends plus comment cela fonctionne.
Quand j'ai commencé à faire Amazon Cloud, c'était aussi un mystère pour moi. Seul ce secret est d'un ordre de grandeur plus élevé, car il y a un conducteur dans la voiture et des millions dans AWS. Tous les utilisateurs dirigent simultanément, appuient sur le gaz et freinent. C'est incroyable qu'ils aillent où ils veulent - pour moi, c'est un miracle! Le système s'adapte automatiquement, évolue et s'adapte de manière flexible à chaque utilisateur de sorte qu'il lui semble qu'il est seul dans cet univers.
La magie s'est un peu dissipée lorsque je suis plus tard venu travailler comme architecte chez Amazon. J'ai vu à quels problèmes nous sommes confrontés, comment nous les résolvons, comment nous développons les services. Avec une meilleure compréhension du système, il y a plus de confiance dans le service. Je veux donc partager une image de ce qui se cache sous le capot du cloud AWS.
De quoi parlerons-nous
J'ai choisi une approche diversifiée - j'ai sélectionné 4 services intéressants qui méritent d'être évoqués.
Optimisation du serveur . Nuages éphémères avec une incarnation physique: centres de données physiques, où il y a des serveurs physiques qui bourdonnent, se réchauffent et clignotent.
Les fonctions sans serveur (Lambda) sont probablement le service le plus évolutif du cloud.
Mise à l'échelle de la base de données . Je vais parler de la façon dont nous construisons nos propres bases de données évolutives.
Mise à l'échelle du réseau . La dernière partie dans laquelle j'ouvrirai l'appareil de notre réseau. C'est une chose merveilleuse - chaque utilisateur du cloud croit qu'il est seul dans le cloud et ne voit pas du tout les autres locataires.
Remarque Cet article se concentrera sur l'optimisation du serveur et la mise à l'échelle de la base de données. La mise à l'échelle du réseau sera discutée dans le prochain article. Où sont les fonctions sans serveur? Une transcription distincte en sortit: « Mal, oui audacieux. Anboxing of Firecracker microvirtuals . " Il parle de plusieurs façons différentes de faire évoluer, et la solution Firecracker est analysée en détail - une symbiose des meilleures qualités d'une machine virtuelle et de conteneurs.
Serveurs
Le nuage est éphémère. Mais cette éphéméralité a toujours un mode de réalisation physique - les serveurs. Au départ, leur architecture était classique. Chipset x86 standard, cartes réseau, Linux, hyperviseur Xen, qui exécute des machines virtuelles.
En 2012, une telle architecture a bien fait son travail. Xen est un excellent hyperviseur, mais avec un défaut majeur. Il a une
surcharge assez
élevée pour émuler des appareils . Avec l'avènement de nouvelles cartes réseau ou SSD plus rapides, ces frais généraux deviennent trop élevés. Comment gérer ce problème? Nous avons décidé de travailler sur deux fronts à la fois - pour
optimiser à la fois le matériel et l'hyperviseur . La tâche est très sérieuse.
Optimisation du fer et de l'hyperviseur
Tout faire en même temps et bien ne fonctionnera pas. Ce qui est «bien» était initialement incompréhensible.
Nous avons décidé d'appliquer une approche évolutive - nous changeons un élément important de l'architecture et le mettons en production.
Nous marchons sur tous les râteaux, écoutons les plaintes et les suggestions. Ensuite, nous changeons un autre composant. Ainsi, par petits incréments, nous changeons radicalement toute l'architecture en fonction des commentaires et du support des utilisateurs.
La transformation a commencé en 2013 avec la chose la plus difficile - le réseau. Dans
les cas
C3 , une carte Network Accelerator spéciale a été ajoutée à la carte réseau standard. Il était connecté avec un câble de bouclage littéralement court sur le panneau avant. Moche, mais pas visible dans le nuage. Mais l'interaction directe avec le matériel a fondamentalement amélioré la gigue et la bande passante du réseau.
Ensuite, nous avons décidé de nous concentrer sur l'amélioration de l'accès au stockage par blocs EBS - Elastic Block Storage. Il s'agit d'une combinaison de réseau et de stockage. La difficulté est que si les cartes Network Accelerator existaient sur le marché, il n'y avait aucun moyen d'acheter simplement du matériel Storage Accelerator. Par conséquent, nous nous sommes tournés vers la startup
Annapurna Labs , qui a développé pour nous des puces ASIC spéciales. Ils vous ont permis de connecter des volumes EBS distants en tant que périphériques NVMe.
Dans les instances
C4 , nous avons résolu deux problèmes. Tout d'abord, nous avons mis en place les bases de l'avenir avec une technologie NVMe prometteuse, mais nouvelle à l'époque. Le second - a considérablement déchargé le processeur central en transférant le traitement des demandes vers EBS sur une nouvelle carte. Cela s'est bien passé, alors maintenant, Annapurna Labs fait partie d'Amazon.
En novembre 2017, nous avons réalisé qu'il était temps de changer l'hyperviseur lui-même.
Le nouvel hyperviseur a été développé sur la base de modules de noyau KVM modifiés.
Cela a permis de réduire fondamentalement les frais généraux liés à l'émulation des appareils et de travailler directement avec les nouveaux ASIC.
Les instances
C5 ont été les premières machines virtuelles sous le capot desquelles tourne un nouvel hyperviseur. Nous l'avons appelé
Nitro .
L'évolution des instances sur la timeline.Tous les nouveaux types de machines virtuelles apparus depuis novembre 2017 fonctionnent sur cet hyperviseur.
Les instances Iron Bare Metal n'ont pas d'hyperviseur , mais elles sont aussi appelées Nitro, car elles utilisent des cartes Nitro spécialisées.
Au cours des deux années suivantes, le nombre de types d'instances Nitro a dépassé quelques dizaines: A1, C5, M5, T3 et autres.
Types d'instances.Comment fonctionnent les voitures nitro modernes
Ils ont trois composants principaux: un hyperviseur Nitro (discuté ci-dessus), une puce de sécurité et des cartes Nitro.
La puce de sécurité est intégrée directement dans la carte mère. Il contrôle de nombreuses fonctions importantes, par exemple, le contrôle du chargement du système d'exploitation hôte.
Cartes Nitro - il en existe quatre types. Tous sont développés par Annapurna Labs et sont basés sur des ASIC courants. Une partie de leur firmware est également courante.
Quatre types de cartes nitro.L'une des cartes est conçue pour fonctionner avec
un réseau VPC . C'est elle qui est visible dans
les machines virtuelles comme une carte réseau
ENA - Elastic Network Adapter . Il encapsule également le trafic lorsqu'il est transmis via le réseau physique (nous en parlerons dans la deuxième partie de l'article), contrôle le pare-feu des groupes de sécurité, est responsable du routage et d'autres éléments du réseau.
Des cartes distinctes fonctionnent avec le stockage de blocs
EBS et les disques intégrés au serveur. Ils sont présentés aux machines virtuelles invitées en tant
qu'adaptateurs NVMe . Ils sont également responsables du chiffrement des données et de la surveillance du disque.
Le système de cartes Nitro, un hyperviseur et une puce de sécurité sont intégrés dans un
réseau SDN ou
Software Defined Network . La
carte de contrôle est responsable de la gestion de ce réseau (Control Plane).
Bien sûr, nous continuons à développer de nouveaux ASIC. Par exemple, fin 2018, ils ont sorti la puce Inferentia, qui permet un travail plus efficace avec les tâches d'apprentissage automatique.
Puce de processeur d'apprentissage automatique Inferentia.Base de données évolutive
La base de données traditionnelle a une structure en couches. S'ils sont grandement simplifiés, les niveaux suivants sont distingués.
- SQL - les répartiteurs de clients et de requêtes y travaillent.
- Sécuriser les transactions - tout est clair ici, ACID et tout ça.
- Mise en cache fournie par les pools de mémoire tampon.
- Journalisation - permet de travailler avec des fichiers de journalisation. Dans MySQL, ils sont appelés Bin Logs, dans PosgreSQL, ils sont appelés Write Ahead Logs (WAL).
- Stockage - écrire directement sur le disque.
Structure de base de données en couches.Il existe différentes façons de faire évoluer les bases de données: partitionnement, architecture Shared Nothing, lecteurs partagés.
Cependant, toutes ces méthodes conservent la même structure de base de données monolithique. Cela limite considérablement la mise à l'échelle. Pour résoudre ce problème, nous avons développé notre propre base de données -
Amazon Aurora . Il est compatible avec MySQL et PostgreSQL.
Amazon aurora
L'idée architecturale principale est de séparer les niveaux de stockage et de journalisation de la base de données principale.
Pour l'avenir, je dirai que nous avons également rendu le niveau de cache indépendant. L'architecture cesse d'être un monolithe et nous obtenons des degrés de liberté supplémentaires dans la mise à l'échelle des blocs individuels.
Les niveaux de journalisation et de stockage sont distincts de la base de données.Un SGBD traditionnel écrit des données dans le système de stockage sous forme de blocs. Chez Amazon Aurora, nous avons créé un référentiel «intelligent» qui peut parler la langue des
redo-logs . À l'intérieur, le référentiel transforme les journaux en blocs de données, surveille leur intégrité et sauvegarde automatiquement.
Cette approche vous permet de mettre en œuvre des choses intéressantes comme le
clonage . Il fonctionne de manière fondamentalement plus rapide et plus économique du fait qu'il ne nécessite pas la création d'une copie complète de toutes les données.
Le niveau de stockage est implémenté comme un système distribué. Il se compose d'un très grand nombre de serveurs physiques. Chaque redo-log est traité et stocké simultanément par
six nœuds . Cela fournit une protection des données et un équilibrage de charge.
La mise à l'échelle de la lecture peut être réalisée à l'aide de répliques appropriées. Le stockage distribué élimine le besoin de synchronisation entre l'instance de base de données principale à travers laquelle nous écrivons des données et d'autres répliques. Il est garanti que les données actuelles seront disponibles pour toutes les répliques.
Le seul problème est la mise en cache des anciennes données sur les réplicas en lecture. Mais ce problème est résolu en
transférant tous les fichiers de journalisation vers des répliques sur le réseau interne. Si le journal est dans le cache, il est marqué comme non valide et est remplacé. S'il n'est pas dans le cache, il est simplement supprimé.
Nous avons compris le stockage.
Comment faire évoluer les niveaux du SGBD
Ici, la mise à l'échelle horizontale est beaucoup plus difficile à faire. Par conséquent, allons sur les sentiers battus de
la mise à l'échelle verticale classique .
Supposons que nous ayons une application qui communique avec un SGBD via un nœud maître.
Avec une mise à l'échelle verticale, nous sélectionnons un nouveau nœud qui aura plus de processeurs et de mémoire.
Ensuite, basculez l'application de l'ancien nœud maître vers le nouveau. Il y a des problèmes.
- Cela nécessitera un temps d'arrêt notable de l'application.
- Le nouveau nœud maître aura un cache froid. Les performances de la base de données ne seront maximales qu'après réchauffement du cache.
Comment améliorer la situation? Mettez un proxy entre l'application et le nœud maître.
Que nous apportera-t-il? Désormais, toutes les applications n'ont pas besoin d'être redirigées manuellement vers un nouveau nœud. La commutation peut être effectuée sous un proxy et en même temps fondamentalement plus rapide.
Le problème semble résolu. Mais non, nous souffrons toujours de la nécessité de réchauffer le cache. De plus, un nouveau problème est apparu - maintenant le proxy est un point d'échec potentiel.
Solution finale avec Amazon Aurora sans serveur
Comment avons-nous résolu ces problèmes?
Laissé un proxy . Il ne s'agit pas d'une instance distincte, mais d'un ensemble de parcs de proxy distribués via lesquels les applications se connectent à la base de données. En cas de panne, n'importe lequel des nœuds peut être remplacé presque instantanément.
Nous avons ajouté un pool de nœuds chauds de différentes tailles . Par conséquent, si vous devez sélectionner un nouveau nœud d'une taille plus grande ou plus petite, il est immédiatement disponible. Pas besoin d'attendre qu'il se charge.
L'ensemble du processus de mise à l'échelle est contrôlé par un système de surveillance spécial. La surveillance surveille en permanence l'état du nœud maître actuel. S'il détecte, par exemple, que la charge du processeur a atteint une valeur critique, il informe le pool d'instances chaudes de la nécessité d'allouer un nouveau nœud.
Proxy distribués, instances chaudes et surveillance.Un nœud de puissance requise est disponible. Les pools de mémoire tampon y sont copiés et le système commence à attendre un moment sûr pour basculer.
Habituellement, le moment du changement arrive assez rapidement. Ensuite, la communication entre le proxy et l'ancien nœud maître est suspendue, toutes les sessions basculent vers le nouveau nœud.
Le travail avec la base de données reprend.
Le graphique montre que la suspension est vraiment très courte. Sur le graphique bleu, la charge et sur les marches rouges - les moments de mise à l'échelle. Les creux à court terme dans le graphique bleu sont précisément ce court délai.
À propos, Amazon Aurora vous permet d'enregistrer et de désactiver complètement la base de données lorsqu'elle n'est pas utilisée, par exemple le week-end. Après l'arrêt du chargement, la base de données diminue progressivement sa puissance et s'éteint pendant un certain temps. Lorsque la charge revient, elle augmentera à nouveau en douceur.
Dans la prochaine partie de la discussion sur les appareils Amazon, nous parlerons de la mise à l'échelle du réseau. Abonnez-vous à la newsletter et restez à l'écoute pour ne pas manquer l'article.
À HighLoad ++, Vasily Pantyukhin fera une présentation « Houston, nous avons un problème. Conception de systèmes de défaillance, modèles de développement de services internes au cloud Amazon . » Ce que les développeurs de conception d'Amazon utilisent des modèles de conception de systèmes distribués, quelles sont les raisons des échecs de service, quelle est l'architecture basée sur les cellules, Constant Work, Shuffle Sharding - ce sera intéressant. Moins d'un mois avant la conférence - réservez vos billets . 24 octobre, l'augmentation finale des prix.