Petit, oui. Déballage du pétard microvirtuel

Enregistrez les microvirtuels de pétard. Nous utilisons deux méthodes populaires pour isoler les charges de travail multi-utilisateurs: les machines virtuelles et les conteneurs. Nous comprenons le meilleur des deux approches, simplifions autant que possible, testons sur une charge réelle élevée. En conséquence, nous obtenons une isolation impénétrable des ordinateurs virtuels qui peuvent être lancés en centaines de millisecondes. Cette solution fonctionne sous le capot d'AWS Lambda et Fargate, exécutant des millions de fonctions sans serveur et de conteneurs dans le cloud chaque seconde. Il s'appelle Firecracker.



Cet outil de microvirtualisation est disponible dans OpenSource . Si vos tâches nécessitent une isolation multi-locataire (enfin, par exemple, vous décidez de créer votre propre cloud), Firecracker est ce dont vous avez besoin.

Vasily Pantyukhin , architecte d'Amazon Web Services, parle de l'architecture Firecracker, de la façon dont elle est utilisée par AWS Lambda, la compare avec des solutions alternatives et donne des exemples d'intégration.

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.

Caractéristiques naturelles des nuages ​​publics

L'une des propriétés fondamentales des clouds publics est la multi-location.

Quelqu'un traduit ce terme par "multi-tenancy" ou "multi-user environment". Mais de mon point de vue, cela ne reflète pas l'essence. La multi-location signifie que différents utilisateurs et leurs charges vivent sur la même infrastructure physique, la partagent entre eux, mais ne se connaissent pas. À partir des charges de travail multi-utilisateurs, la multi-location diffère en principe par des exigences plus strictes pour l'isolement des ressources et l'accès à celles-ci.

La surcharge est une autre propriété inhérente aux clouds publics.

Croyez-moi, dans le cas d'AWS, c'est une énorme charge! La capture d'écran est un exemple de données réelles. Je ne dirai pas pendant combien de temps et dans quelle région ces millions de "perroquets" ont été mesurés, mais ce n'est pas une sorte d'urgence, mais le mode de fonctionnement habituel pour nous.



Il s'avère une certaine contradiction. D'une part, nous devons garder les utilisateurs aussi isolés que possible. D'autre part, nous devons garantir un niveau très élevé de productivité et d'utilisation des ressources. L'amélioration de l'un conduit souvent aux limites de l'autre. Comment trouver un compromis, et encore mieux, pour obtenir le maximum sur tous les fronts?

Machines virtuelles ou conteneurs?

Il existe deux approches de base qui pourraient potentiellement aider. Ce sont des machines virtuelles et des conteneurs. Chacun a ses avantages et ses inconvénients.



Le principal inconvénient des machines virtuelles est qu'elles prennent beaucoup de temps à charger . Il faut généralement des dizaines de secondes, voire des minutes, pour démarrer la machine. Mais les virtualoks ont une vertu: ils isolent les charges de béton les uns des autres. Et des deux points de vue:

• sécurité lorsqu'une machine virtuelle n'est pas en mesure d'accéder aux données d'une autre machine;
• ressources , lorsque j'ai commandé 8 Go de mémoire, j'espère que cette RAM sera la mienne et personne ne pourra réclamer la ressource pour laquelle j'ai payé.

Le contraire est le cas des conteneurs: ils sont légers et se chargent donc très rapidement. Ils peuvent être facilement mis à l'échelle horizontalement. Mais il y a une fonctionnalité avec laquelle nous, en tant que fournisseur de cloud public, ne pouvons pas vivre. Ils utilisent un noyau partagé - le noyau du système d'exploitation est partagé entre tous les conteneurs .



Peut-on dire que les conteneurs ne sont pas sûrs? Non, même s'il existe de graves vulnérabilités.

Je pense qu'aujourd'hui un conteneur correctement «soudé» offre un niveau de sécurité suffisant.

Le problème est différent - un noyau partagé ne garantit pas fondamentalement qu'à l'avenir, des vulnérabilités n'apparaissent pas qui rompent l'isolement des locataires. Le cloud public ne peut pas se le permettre, même en théorie.

Il y a encore une autre contradiction et une solution doit être recherchée. Le moyen le plus simple est de tirer le meilleur parti de maman - une machine virtuelle et de papa - d'un conteneur, de traverser et d'obtenir quelque chose de convergent . En fait, nous l'avons fait. Il s'est avéré que Firecracker.

Firecracker est déjà en production. Dans la même charge élevée de services critiques, par exemple, AWS Lambda (fonctions sans serveur) et AWS Fargate (conteneurs sans serveur).

Problèmes de l'ancien AWS Lambda

AWS Lambda est un service de fonctionnalités sans serveur. Nous prenons la fonction en Java, Go, Python ou un autre langage, nous la jetons dans Lambda, et elle est exécutée comme par magie. Il n'est pas nécessaire d'allouer et de gérer les ressources. Comment cela a-t-il été mis en œuvre auparavant?



Pour chaque compte AWS, une ou plusieurs machines virtuelles EC2 distinctes ont été allouées pour isoler les fonctions appartenant à différents locataires. Une telle machine virtuelle consomme des ressources, même lorsqu'elle ne fait rien. Supposons que nous exécutons une fonction toutes les 10 minutes et qu'elle s'exécute en 200 ms comme une Lambda ordinaire. Il s'avère qu'en une heure la machine EC2 n'est utilisée que quelques secondes. De plus, même à l'exécution, il ne consomme pas toutes les ressources disponibles - élimination sous la plinthe. C'est furieusement non rentable.

Comment avez-vous résolu le problème du recyclage?

Développé à partir de zéro leur propre solution Firecracker. Cela ressort clairement du titre du rapport :)

Pour commencer à développer un nouveau produit, vous avez besoin d'une tâche technique. Il contient beaucoup de texte, mais si vous sélectionnez uniquement la signification, vous obtenez ce qui suit.

• Propulsé par KVM en tant qu'hyperviseur. Quiconque travaille avec AWS sait que nous avons deux hyperviseurs préférés. Les machines virtuelles héritées s'exécutent sur Xen. Depuis fin 2017, KVM vit sous le capot de toutes les voitures.
• Cela démarre le plus rapidement possible. Sur le matériel de référence, l'exigence était une charge complète du microvirtuel en 125 ms.
• Frais généraux de virtualisation minimum . Dans l'architecture de référence, une seule machine micro-virtuelle Firecracker ne consomme en outre que 5 Mo de mémoire.
• La possibilité du départ le plus dense . Paramètres de conception - pleine charge de 5 microvirtuels par cœur par seconde. Cette exigence est fondamentale pour des services tels qu'AWS Lambda. Les fonctions doivent décoller, s'entraîner et mourir rapidement, libérant des ressources pour la suivante.
• La possibilité de réabonnement . C'est une opportunité - il n'est pas nécessaire de l'utiliser. En fait, il s'agit de l'allocation de ressources virtuelles dans une plus large mesure qu'elles ne sont physiquement disponibles. Cela signifie que le serveur dispose de 16 Go de RAM et que vous exécutez simultanément 4 machines virtuelles sur celui-ci, chacun étant sûr qu'il dispose de 8 Go de mémoire.

AWS Lambda avec pétard sous le capot

Qu'est-ce qui a changé dans la nouvelle version d'AWS Lambda? Du point de vue de l'utilisateur final, rien n'a changé. La migration vers une architecture mise à jour en production était totalement transparente et invisible pour les consommateurs. Les fonctionnalités Lambda sont de courte durée - c'était facile à faire.

À quoi ressemble l'architecture moderne?

Au niveau le plus bas, il ne s'agit plus maintenant d'une machine virtuelle, mais d'un bare-metal physique.

Ces serveurs permettent d'utiliser pleinement toutes les fonctions du processeur, par exemple Intel VT. Cela offre des avantages supplémentaires lors de l'utilisation de la virtualisation à des niveaux supérieurs.



Au sommet de la pièce de fer se trouve le système d' exploitation hôte avec le module KVM dans le noyau. Les microvirtuels de pétard avec leurs propres OS invités sont lancés ci-dessus. Eh bien, ils ont déjà implémenté des composants du service AWS Lambda lui-même.

Auparavant, pour chaque client utilisant les fonctionnalités Lambda, nous allouions des machines virtuelles EC2 distinctes à faible utilisation. La nouvelle approche vous permet d'exécuter un microvirtuel léger uniquement lorsque vous en avez vraiment besoin. Isoler les ressources Firecracker les unes des autres nous permet de le faire sur un matériel commun avec une densité maximale. L'utilisation des ressources s'est fondamentalement améliorée.

Qu'y a-t-il dans la boîte?

J'ai promis une anboxing, alors passons en revue les principaux composants de Firecracker, considérons chacun d'eux séparément, puis assemblons le tout.

Principes de conception

Lorsque nous avons commencé à discuter du développement de Firecracker, nous avons convenu d'adhérer à deux principes.

Débarrassez-vous de tout ce qui n'est pas nécessaire. Pourquoi les machines virtuelles classiques se chargent-elles lentement? En particulier, car le code est surchargé. Ils doivent prendre en charge un grand nombre d'appareils hérités. Mais pourquoi émuler un appareil que personne d'autre n'utilisait il y a 10 ans? Il n'est donc pas nécessaire de se débarrasser de tout ce qui est superflu. Nous résolvons une tâche étroite spécifique et toute fonctionnalité qui ne permet pas de résoudre ce problème est considérée comme inutile.

Débarrassez-vous de tout ce qui est superflu et concentrez-vous sur une tâche.

Simplifiez ce qui reste. Même ce qui reste devrait être aussi simple que possible.

Sur quoi ont-ils écrit?

Firecracker est écrit en rouille tendance parce que:

• il vous permet d'écrire du code plus sécurisé , notamment en termes de mémoire;
• Les performances et les frais généraux sont comparables au C ++ moderne;
• La rouille est utilisée depuis longtemps, depuis 2015, elle a écrit de nombreuses solutions intéressantes pour les charges élevées.

Le fer

Je le répète - Firecracker nécessite une installation sur du vrai matériel. Comme configuration de référence, la machine en métal nu i3.metal a été choisie.


Remarque: le rapport était au début d'avril 2019. À cette époque, seule la plate-forme Intel était prise en charge. En mai, ils ont ajouté la prise en charge alpha d'AMD et en juin ARM. AMD peut être légèrement moins cher qu'Intel, et le support ARM offre des opportunités intéressantes pour travailler avec l'IoT multi-locataire.

Si vous commandez une i3.metal ou une autre machine à métaux nus dans AWS, alors pour les expériences, ce sera une configuration trop puissante et coûteuse. Par conséquent, si vous décidez d'installer Firecracker sur eux, n'oubliez pas de payer ces machines après les expériences. Sinon, un score décent viendra à la fin du mois.

Y a-t-il une option moins chère? Oui, vous pouvez démarrer Firecracker dans un environnement virtuel. Mais plus dans AWS - nous ne prenons pas en charge la virtualisation imbriquée sur EC2. Mais vous pouvez le faire dans GCP, Azure, DigitalOcean ou utiliser Proxmox, Parallels, VMware Fusion. Tout fonctionnera si vous respectez les exigences, en particulier, selon la version du noyau de l'OS invité.

Le noyau

L'élément fondamental de la solution est le module du noyau KVM.

Juste au cas où, je vais décrire comme une digression ce qu'est KVM. Ce n'est pas tout l'hyperviseur, mais seulement une partie de celui-ci. Ses principales tâches consistent à configurer un processeur virtuel (vCPU) et à démarrer une machine virtuelle .



Mais cela ne suffit pas pour un travail à part entière. En plus du processeur, certains autres périphériques sont nécessaires. Leur émulation se produit dans l'espace utilisateur.

VMM

Pour qu'au moins les périphériques de base apparaissent, vous avez besoin d'un autre composant - Virtual Machine Manager (VMM). Avant Firecracker, l'option VMM principale était QEMU.



Nous avons sérieusement envisagé la possibilité d'utiliser QEMU, mais avons décidé de développer notre propre «vélo». Il y avait plusieurs raisons à cela.

Gestion du développement . QEMU est un grand produit mature avec plus d'un million de lignes de code. Pour apporter des modifications, vous devez afficher trop de codes source. Beaucoup de gens participent au développement et à la prise de décision sur le développement.

La sécurité QEMU peut émuler de nombreux appareils. C'est pourquoi il a une surface d'attaque assez importante. Notre tâche est de faire un microvirtuel. D'un point de vue sécuritaire, il faut minimiser la surface d'attaque.

La nécessité d'implémenter de nouvelles fonctionnalités. QEMU a un bon code. Il s'agit d'un produit mature dans lequel tous les bugs évidents sont déjà détectés. Mais dans sa forme actuelle, la fonctionnalité QEMU ne nous convenait toujours pas - nous devions en ajouter beaucoup. De ce point de vue, le nouveau code dans QEMU et dans le nouveau produit aurait la même qualité. Par conséquent, une victoire spéciale ne fonctionnerait pas.

Appareils

Firecracker implémente VMM, qui est utilisé pour émuler des appareils. Nous émulons les appareils suivants:

• La console Une chose utile et nécessaire, même si elle peut être désactivée.
• Clavier Nous avons créé un clavier délicat - avec un seul bouton «Réinitialiser». Nous ne faisons tout simplement pas confiance au logiciel «Reset» de ces systèmes d'exploitation qui pourraient potentiellement fonctionner dans Firecracker. Par conséquent, ils ont fait du fer.
• Pilotes Virtio pour disque et réseau . Virtio est un appareil très primitif. En substance, il s'agit d'un "tampon en anneau". Le système invité a écrit quelque chose dans le tampon, a cliqué sur l'appel et le système hôte a lu les données de ce tampon dans un fichier.

Dans certains cas, par exemple, pour l'intégration avec des conteneurs, nous avons toujours besoin d'un périphérique réseau qui représenterait les fonctionnalités de base d'une carte réseau standard. Virtio ne rentre pas ici, trop simple. Par conséquent, pour le réseau, nous utilisons un autre appareil - Vsock .

Eh bien, nous devons également pouvoir contrôler la consommation des ressources. Le limiteur de débit en est responsable.

Il y a des appareils. Mais comment gérer et configurer les microvirtuels? L'API de gestion nous aidera ici.

La gestion

Amazon a plusieurs principes fondamentaux incassables. L'un d'eux est que tous les services communiquent entre eux uniquement via l'API. Peu importe qu'il s'agisse de services externes que vous utilisez en tant qu'utilisateur ou de nos services internes. Il n’arrive pas qu’un service accède directement à la base de données d’un autre service - il est interdit et punissable. Le thread de l'API Firecracker est juste utilisé pour accéder aux paramètres et aux fonctionnalités des microvirtuels via l'API REST.



Nous adhérons à la spécification Open API, vous pouvez donc utiliser Swagger.

Métadonnées

Il y a un tel mal - un codage dur. C'est lorsque certaines données sont cousues directement dans le code, par exemple, le login et le mot de passe d'accès à une autre ressource. Bien entendu, cela n'est pas autorisé. Périodiquement, nous devons transférer certaines données à l'intérieur du microvirtuel. Cela se fait via le service de métadonnées .



Nous transmettons les informations requises via le socket au commerce de métadonnées IMDS. Pour obtenir ces informations dans le microvirtuel, vous devez demander http://169.254.169.254/latest/meta-data à l'aide de l'API REST. Les utilisateurs AWS connaissent déjà cette IP magique. De la même manière, les microvirtuels peuvent obtenir des informations détaillées sur leur propre configuration.

Journaux

Il est impératif de pouvoir jeter des bûches de microvirtuels dans le monde extérieur avant sa mort. Cela se fait via un FIFO Unix standard.

Isolation supplémentaire

Le principal avantage de la machine virtuelle isolée. Il semble que cela devrait suffire, mais nous sommes allés plus loin. Au cas où, pour fonctionner en production, il est recommandé de poser une couche supplémentaire d'isolation appelée Jailer .



Ce sont des précautions standard:

• cgroups pour limiter les ressources;

• espace de noms pour isoler les processus;
• seccomp - un analogue du pare-feu pour les appels système;
• et, bien sûr, le chroot préféré de tout le monde .

Intégration avec d'autres services

Existe-t-il des solutions prêtes à l'emploi basées sur Firecracker? Bien sûr que oui.

OSV

Ce système d'exploitation est conçu pour exécuter une seule application. Pour cette raison, elle a très simplement organisé le travail avec la mémoire et un planificateur. Un système d'exploitation puissant et facile à gérer fonctionne désormais au-dessus de Firecracker .

Containerd

Nous avons également fait l'intégration avec containerd. Si vous travaillez déjà avec lui, vous avez besoin d'un minimum d'efforts pour lancer des conteneurs qui sont enveloppés dans Firecracker pour l'isolement.



Au lieu de la cale habituelle, containerd se réfère à la cale de pétard. Il gère déjà runc, via un agent installé à l'intérieur du microvirtuel. Vérifié, fonctionne .

Conteneurs Kata

Lorsque nous avons annoncé Firecracker pour la première fois, l'une des questions les plus fréquemment posées par les clients était:

- Le mécanisme d'isolement des conteneurs a déjà été inventé - il s'agit des conteneurs Kata. Pourquoi ne les avez-vous pas utilisés? Pourquoi développer le vôtre?
- Kata fonctionne avec QEMU, mais nous ne voulons pas travailler avec QEMU. Par conséquent, nous avons décidé de cuisiner le nôtre.

Mais cela s'est avéré intéressant. Les développeurs de Kata ont rencontré les développeurs de Firecracker et ont accepté de s'intégrer. Parce que tout le monde voit cela comme un énorme avantage. Kata Containers v1.5 prend déjà en charge QEMU et Firecracker.

Il s'avère que nous ne rivalisons pas, mais que nous nous complétons harmonieusement. Dans Kubernetes avec la v1.12, vous pouvez définir runtimeClassName comme Kata FC ou Kata QEMU, et exécuter vos conteneurs dans l'isolement approprié.



Comment choisir l'isolation qui convient à votre application - Pétard ou QEMU? Mon opinion personnelle est que ce qui importe est de savoir si votre demande concerne des animaux de compagnie ou du bétail .



Kata avec QEMU est une solution pour les animaux de compagnie. QEMU est un grand système multifonctionnel. Potentiellement, il offre plus d'options de support et de traitement pour vos animaux de compagnie préférés.

Le pétard convient lorsque la charge est du bétail. Dans le cas où votre application sans état a été initialement conçue pour une mise à l'échelle horizontale flexible et la défaillance d'un ou plusieurs conteneurs n'est pas critique. Fournissant une isolation fiable, il vous permet de charger rapidement le nombre requis de nouveaux conteneurs pour remplacer ceux qui ont échoué.

Quel est le résultat?

Nous avons commencé avec des contradictions. Il semble que résoudre la contradiction soit une approche «à la fois la nôtre et la vôtre», quelque chose entre les deux qui satisfera tout le monde. Mais l'expérience montre qu'un compromis n'est pas nécessaire.

Nous nous sommes fixé pour objectif de développer une nouvelle solution dans laquelle il n'y aura rien de superflu qui ne soit nécessaire pour résoudre une tâche étroite. Il était également important de simplifier autant que possible tout ce que nous utilisons. Je voudrais croire que nous n'avons pas obtenu de compromis, mais une solution solide qui vous permet de lancer rapidement et en masse des milliers de microvirtuels sans sacrifier leur isolement.

Nous utilisons déjà Firecracker dans la production de plusieurs de nos services. Le principal avantage que nous avons obtenu est l'amélioration de l'utilisation des services. Cela a permis d'économiser considérablement. Une partie de ces économies que nous avons partagées avec les clients. Par exemple, après l'introduction de Firecracker, les prix des conteneurs sans serveur AWS Fargate en janvier 2019 ont chuté de 35 à 50%. L'avantage est visible à l'œil nu, il ne fait donc aucun doute que nous continuerons à développer ce produit et à partager nos meilleures pratiques avec l'Open Source. Le fait que Firecracker ait déjà commencé à s'intégrer à d'autres solutions indique un intérêt croissant de la part de la communauté.

Si vous avez une idée ou un produit fini dans la description de laquelle il y a les mots «isolation multi-locataire» - c'est un indicateur clair de ce qu'il vaut la peine d'expérimenter avec des microvirtuels Firecracker.

Ce rapport illustre parfaitement le principe auquel nous essayons d'adhérer lors des conférences d' Ontiko - recevoir une expérience mondiale d'experts russophones. Et le point n'est pas seulement dans une éventuelle barrière linguistique, mais dans la culture, nous sommes habitués à partager des détails techniques. En novembre, Vasily se produira à nouveau à HighLoad ++ , et il sera rejoint , par exemple, par Artemy Kolesnikov de Facebook, Vittorio Cioe d'Oracle et, bien sûr, Petr Zaitsev de Percona. Nous aurons également des rapports en anglais, abonnez - vous à la newsletter - nous vous dirons quand de nouveaux seront ajoutés aux quarante rapports acceptés.