Les nuages sont comme une boîte magique : vous demandez ce dont vous avez besoin et les ressources apparaissent 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 de recevoir toujours les ressources nécessaires, vous ne tenez compte de personne et vous déterminez indépendamment à quoi ressemblera le réseau. Comment fonctionne cette magie qui permet au cloud d'allouer les ressources de manière élastique et d'isoler complètement les locataires les uns des autres ?
Le cloud AWS est un système méga-super complexe qui évolue de manière évolutive depuis 2006. Une partie de cette évolution a eu lieu Vassili Pantioukhine - Architecte Amazon Web Services. En tant qu'architecte, il a un aperçu non seulement du résultat final, mais également des défis qu'AWS surmonte. Plus la compréhension du fonctionnement du système est grande, plus la confiance est grande. Par conséquent, Vasily partagera les secrets des services cloud AWS. Vous trouverez ci-dessous la conception de serveurs AWS physiques, l'évolutivité élastique de la base de données, une base de données Amazon personnalisée et des méthodes permettant d'augmenter les performances des machines virtuelles tout en réduisant simultanément leur prix. La connaissance des approches architecturales d'Amazon vous aidera à utiliser les services AWS plus efficacement et pourra vous donner de nouvelles idées pour créer vos propres solutions.
À propos de l'orateur : Vasily Pantyukhin () a commencé comme administrateur Unix dans des sociétés .ru, a travaillé sur du matériel Sun Microsystem pendant 6 ans et a prêché un monde centré sur les données chez EMC pendant 11 ans. Il a naturellement évolué vers des cloud privés, puis est passé en 2017 vers des cloud publics. Il fournit désormais des conseils techniques pour vous aider à vivre et à vous développer dans le cloud AWS.
Avertissement : tout ce qui suit est l'opinion personnelle de Vasily et peut ne pas coïncider avec la position d'Amazon Web Services. Le rapport sur lequel est basé l'article est disponible sur notre chaîne YouTube.
Pourquoi je parle de l'appareil Amazon ?
Ma première voiture avait une transmission manuelle. C’était génial car j’avais le sentiment de pouvoir conduire la voiture et d’en avoir un contrôle total. J'ai aussi aimé avoir compris au moins approximativement le principe de son fonctionnement. Naturellement, j'ai imaginé la structure de la boîte comme étant assez primitive - un peu comme une boîte de vitesses sur un vélo.
Tout était super, sauf une chose : coincé dans les embouteillages. On a l'impression que vous êtes assis et que vous ne faites rien, mais vous changez constamment de vitesse, appuyez sur l'embrayage, l'accélérateur, le frein - cela vous fatigue vraiment. Le problème des embouteillages a été partiellement résolu lorsque la famille s’est procurée une voiture automatique. En conduisant, j'ai eu le temps de réfléchir à quelque chose et d'écouter un livre audio.
Un autre mystère est apparu dans ma vie, car j'ai complètement arrêté 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 : appui sur l'accélérateur, frein, style de conduite, qualité de la route. Je ne comprends plus comment ça marche.
Quand j’ai commencé à travailler sur le cloud Amazon, c’était aussi un mystère pour moi. Seul ce mystère est d'un ordre de grandeur plus grand, car il y a un conducteur dans la voiture, et dans AWS il y en a des millions. Tous les utilisateurs dirigent, appuient sur l'accélérateur et freinent simultanément. C'est incroyable qu'ils aillent où ils veulent, c'est un miracle pour moi ! Le système s'adapte, évolue et s'ajuste automatiquement de manière élastique à chaque utilisateur pour qu'il lui semble qu'il est seul dans cet Univers.
La magie s’est un peu dissipée lorsque je suis ensuite devenu architecte chez Amazon. J'ai vu à quels problèmes nous sommes confrontés, comment nous les résolvons et comment nous développons les services. Avec une meilleure compréhension du fonctionnement du système, une plus grande confiance dans le service apparaît. Je souhaite donc partager une image de ce qui se cache sous le capot du cloud AWS.
De quoi allons-nous parler
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. Des nuages éphémères avec une incarnation physique : des centres de données physiques où se trouvent des serveurs physiques qui bourdonnent, chauffent et clignotent avec des lumières.
Fonctions sans serveur (Lambda) est probablement le service le plus évolutif du cloud.
Mise à l'échelle de la base de données. Je vais vous expliquer comment 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.
Note. Cet article abordera l'optimisation du serveur et la mise à l'échelle de la base de données. Nous examinerons la mise à l'échelle du réseau dans le prochain article. Où sont les fonctions sans serveur ? Une transcription distincte a été publiée à leur sujet "" Il parle de plusieurs méthodes de mise à l'échelle différentes et discute en détail de la solution Firecracker - une symbiose des meilleures qualités d'une machine virtuelle et de conteneurs.
Les serveurs
Le nuage est éphémère. Mais cette éphémère a encore une incarnation physique : les serveurs. Au départ, leur architecture était classique. Chipset x86 standard, cartes réseau, Linux, hyperviseur Xen sur lequel s'exécutaient les machines virtuelles.
En 2012, cette architecture a plutôt bien fait face à ses tâches. Xen est un excellent hyperviseur, mais il présente un inconvénient majeur. Il en a assez surcharge élevée pour l'émulation de périphérique. À mesure que de nouvelles cartes réseau ou disques SSD plus rapides deviennent disponibles, cette surcharge devient trop élevée. Comment faire face à ce problème ? Nous avons décidé de travailler sur deux fronts à la fois : optimiser à la fois le matériel et l'hyperviseur. La tâche est très sérieuse.
Optimisation du matériel et de l'hyperviseur
Tout faire en même temps et bien le faire ne fonctionnera pas. Ce qu’était le « bien » n’était pas non plus clair au départ.
Nous avons décidé d'adopter une approche évolutive : nous modifions un élément important de l'architecture et le mettons en production.
Nous marchons sur chaque râteau, écoutons les plaintes et les suggestions. Ensuite, nous changeons un autre composant. Ainsi, par petits incréments, nous modifions radicalement l’ensemble de l’architecture en fonction des commentaires des utilisateurs et du support.
La transformation a commencé en 2013 avec la chose la plus complexe : le réseau. DANS S3 Dans certains cas, une carte Network Accelerator spéciale a été ajoutée à la carte réseau standard. Il était connecté littéralement avec un court câble de bouclage sur le panneau avant. Ce n'est pas joli, mais ce n'est pas visible dans le cloud. Mais l'interaction directe avec le matériel a fondamentalement amélioré la gigue et le débit du réseau.
Ensuite, nous avons décidé d'améliorer l'accès au stockage de données en bloc EBS - Elastic Block Storage. C'est une combinaison de réseau et de stockage. La difficulté est que même si des cartes Network Accelerator existaient sur le marché, il n'était pas possible d'acheter simplement du matériel Storage Accelerator. Nous nous sommes donc tournés vers une startup Laboratoires Annapurna, qui a développé pour nous des puces ASIC spéciales. Ils ont permis de monter des volumes EBS distants en tant que périphériques NVMe.
Dans les cas C4 nous avons résolu deux problèmes. La première est que nous avons mis en place une base pour l’avenir de la technologie NVMe, prometteuse mais nouvelle à l’époque. Deuxièmement, nous avons considérablement déchargé le processeur central en transférant le traitement des requêtes vers EBS vers une nouvelle carte. Cela s’est bien passé, alors Annapurna Labs fait désormais 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 la surcharge de l'émulation des appareils et de travailler directement avec les nouveaux ASIC. Instances S5 ont été les premières machines virtuelles dotées d'un nouvel hyperviseur fonctionnant sous le capot. Nous l'avons nommé nitro.
Evolution des instances sur la timeline.
Tous les nouveaux types de machines virtuelles apparus depuis novembre 2017 fonctionnent sur cet hyperviseur. Les instances Bare Metal n'ont pas d'hyperviseur, mais ils sont aussi appelés Nitro, car ils 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 machines Nitro modernes
Ils comportent trois composants principaux : l'hyperviseur Nitro (discuté ci-dessus), la puce de sécurité et les cartes Nitro.
Puce de sécurité intégré directement à la carte mère. Il contrôle de nombreuses fonctions importantes, telles que 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 communs. Certains de leurs firmwares sont également courants.
Quatre types de cartes Nitro.
L'une des cartes est conçue pour fonctionner avec réseauVPC. C'est ce qui est visible dans les machines virtuelles sous forme de carte réseau ENA - Adaptateur réseau élastique. Il encapsule également le trafic lors de sa transmission via un réseau physique (nous en parlerons dans la deuxième partie de l'article), contrôle le pare-feu des groupes de sécurité et est responsable du routage et d'autres éléments du réseau.
Certaines cartes fonctionnent avec le stockage par blocs EBS et les disques intégrés au serveur. Ils apparaissent sur la machine virtuelle invitée sous la forme Adaptateurs NVMe. Ils sont également responsables du cryptage des données et de la surveillance des disques.
Le système de cartes Nitro, hyperviseur et puce de sécurité est intégré à un réseau SDN ou Réseau défini par logiciel. Responsable de la gestion de ce réseau (Control Plane) carte contrôleur.
Bien entendu, nous continuons à développer de nouveaux ASIC. Par exemple, fin 2018, ils ont lancé la puce Inferentia, qui vous permet de travailler plus efficacement avec les tâches d'apprentissage automatique.
Puce du processeur d’apprentissage automatique Inferentia.
Base de données évolutive
Une base de données traditionnelle a une structure en couches. Pour simplifier grandement, on distingue les niveaux suivants.
- SQL — les répartiteurs de clients et de demandes y travaillent.
- Des provisions transactions - tout est clair ici, ACID et tout ça.
- mise en cache, qui est fourni par les pools de mémoire tampon.
- Enregistrement — permet de travailler avec des journaux de rétablissement. Dans MySQL, ils sont appelés Bin Logs, dans PosgreSQL - Write Ahead Logs (WAL).
- stockage – enregistrement direct sur disque.
Structure de base de données en couches.
Il existe différentes manières de faire évoluer les bases de données : partitionnement, architecture Shared Nothing, disques 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 mise en cache indépendant. L'architecture cesse d'être un monolithe et nous gagnons 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 sur un système de stockage sous forme de blocs. Chez Amazon Aurora, nous avons créé un stockage intelligent qui parle un langage journaux redo. À l’intérieur, le stockage transforme les journaux en blocs de données, surveille leur intégrité et effectue automatiquement des sauvegardes.
Cette approche vous permet de mettre en œuvre des choses aussi intéressantes que clonage. Il fonctionne fondamentalement plus rapidement et de manière plus économique car il ne nécessite pas de créer une copie complète de toutes les données.
La couche de stockage est implémentée en tant que système distribué. Il est constitué d'un très grand nombre de serveurs physiques. Chaque journal redo est traité et enregistré simultanément six nœuds. Cela garantit la protection des données et l’équilibrage de la 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, via laquelle nous écrivons les données, et les répliques restantes. Les données à jour sont garanties d'être 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 en train d'être résolu transfert de tous les redo logs aux répliques sur le réseau interne. Si le journal est dans le cache, il est marqué comme incorrect et écrasé. S'il n'est pas dans le cache, il est simplement supprimé.
Nous avons réglé le stockage.
Comment faire évoluer les niveaux de SGBD
Ici, la mise à l’échelle horizontale est beaucoup plus difficile. Alors sortons des sentiers battus mise à l'échelle verticale classique.
Supposons que nous ayons une application qui communique avec le SGBD via un nœud maître.
Lors d'une mise à l'échelle verticale, nous allouons un nouveau nœud qui disposera de plus de processeurs et de mémoire.
Ensuite, nous passons l’application de l’ancien nœud maître au nouveau. Des problèmes surviennent.
- Cela nécessitera un temps d’arrêt important des applications.
- Le nouveau nœud maître aura un cache froid. Les performances de la base de données ne seront maximales qu'une fois le cache réchauffé.
Comment améliorer la situation ? Configurez un proxy entre l'application et le nœud maître.
Qu'est-ce que cela va nous apporter ? Désormais, toutes les applications n'ont plus besoin d'être redirigées manuellement vers le nouveau nœud. Le changement peut être effectué sous un proxy et est fondamentalement plus rapide.
Il semble que le problème ait été résolu. Mais non, nous souffrons toujours de la nécessité de réchauffer le cache. De plus, un nouveau problème est apparu : le proxy est désormais un point de défaillance potentiel.
Solution finale avec Amazon Aurora sans serveur
Comment avons-nous résolu ces problèmes ?
A laissé un proxy. Il ne s'agit pas d'une instance distincte, mais de toute une flotte distribuée de proxys 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.
Ajout d'un pool de nœuds chauds de différentes tailles. Ainsi, s’il est nécessaire d’attribuer un nouveau nœud de taille plus grande ou plus petite, il est immédiatement disponible. Pas besoin d'attendre qu'il se charge.
L'ensemble du processus de détartrage 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 chaleureuses et surveillance.
Un nœud avec la puissance requise est disponible. Les pools de tampons y sont copiés et le système commence à attendre un moment sûr pour basculer.
Habituellement, le moment de changer arrive assez rapidement. Ensuite, la communication entre le proxy et l'ancien nœud maître est suspendue et toutes les sessions sont basculées vers le nouveau nœud.
Le travail avec la base de données reprend.
Le graphique montre que la suspension est effectivement très courte. Le graphique bleu montre la charge et les étapes rouges montrent les moments de mise à l'échelle. Les baisses à court terme dans le graphique bleu correspondent précisément à ce court délai.
À propos, Amazon Aurora vous permet d'économiser complètement de l'argent et de désactiver la base de données lorsqu'elle n'est pas utilisée, par exemple le week-end. Après avoir arrêté la charge, la base de données réduit progressivement sa puissance et s'éteint pendant un certain temps. Lorsque la charge reviendra, elle remontera à nouveau en douceur.
Dans la prochaine partie de l'histoire de l'appareil Amazon, nous parlerons de la mise à l'échelle du réseau. S'abonner et restez à l'écoute pour ne pas manquer l'article.
Sur Vasily Pantyukhin fera un rapport "" Quels modèles de conception pour les systèmes distribués sont utilisés par les développeurs Amazon, quelles sont les raisons des pannes de service, qu'est-ce que l'architecture basée sur les cellules, le travail constant, le Shuffle Sharding - ce sera intéressant. Moins d'un mois avant la conférence - . Augmentation définitive des prix le 24 octobre.
Source: habr.com