Construire des systèmes résilients sans serveur – Un bon serveur Minecraft

Transcription

Chapin: Je m'appelle John Chapin, je suis partenaire d'un très petit cabinet de conseil appelé Symphonia. Nous faisons du conseil en architecture sans serveur et en cloud. Nous sommes basés ici à New York. Si tu veux en parler plus, viens me chercher après. Je suis heureux d’en parler plus longuement à ce sujet, mais nous sommes ici aujourd’hui pour parler de la création de systèmes résilients sans serveur. Voici ce que nous allons couvrir. Nous allons passer en revue un peu ce que nous pensons, en tant que Symphonia, sans serveur. Nous allons parler de résilience, à la fois en termes d'applications et en termes de systèmes de fournisseurs sur lesquels nous comptons, nous allons donner une brève démonstration en direct, je vais donc tenter les dieux de la démo aujourd'hui, puis J'espère que nous aurons du temps pour des discussions et des questions-réponses à la fin. Si, pour une raison quelconque, nous n’avons pas le temps, nous serons heureux de répondre à toutes vos questions après la séance.

Qu'est-ce que Serverless?

Qu'est-ce que sans serveur? La réponse courte est d'aller lire le petit rapport que nous avons préparé. Nous avons fait cela avec notre Ariely. Il y a un lien en bas ici. Ce lien est dans la diapositive, vous pouvez télécharger le PDF gratuit. Nous pensons que sans serveur est une combinaison de fonctions en tant que service, donc des choses dont vous avez tous entendu parler, telles que AWS Lambda, Auth0 Webtask, Fonctions Azure, les fonctions Google Cloud, etc., etc., ainsi que les backends en tant que service. Ce sont des choses comme Auth0 pour l'authentification, DynamoDB, Firebase, Parse – cela n'existe plus, mais cela aurait été l'un de ceux-ci – même S3, SQS, SNS Kinesis, etc. Serverless est une combinaison de fonctions en tant que service, ces petits extraits de logique métier que vous téléchargez sur une plate-forme et de back-end en tant que service. Ce sont des fonctionnalités plus complètes que vous utilisez.

Quels sont certains attributs de sans serveur qui sont communs à ces deux choses? Nous couvrons cela en détail dans ce rapport, je vous encourage donc à le vérifier. Il n'y a pas de gestion d'hôtes ou de processus, ces services sont auto-dimensionnés et provisionnés. Leurs coûts sont basés sur une utilisation précise, et la chose vraiment importante que nous allons couvrir aujourd'hui est que lorsque vous ne les utilisez pas, le coût est nul ou très proche de zéro. Ce que nous allons également aborder aujourd'hui, c'est qu'ils ont également cette idée de la haute disponibilité implicite, et je parlerai de ce que cela signifie un peu plus tard.

Quels sont certains des avantages du sans serveur? Vous avez entendu cela de plusieurs endroits au cours des deux dernières années. Ce sont les avantages du cloud, mais nous venons de franchir une étape supplémentaire. Réduction supplémentaire du coût total de possession, beaucoup plus de flexibilité dans la mise à l'échelle et un délai d'exécution beaucoup plus court pour le déploiement de nouveaux éléments, coût d'expérimentation nettement inférieur. Si je veux mettre en place une nouvelle application sans serveur avec des Lambdas et une table DynamoDB, je peux la mettre en place en quelques heures. Si je n'aime pas ça, je peux le détruire en deux minutes et je n'ai pas investi tout cet argent dans cette infrastructure persistante.

Avec tous ces avantages, nous abandonnons également certaines choses. Une chose que nous appelons dans ce rapport, et c’est ce dont nous allons beaucoup parler aujourd’hui, est cette idée de perte de contrôle. Plus nous utilisons ces services gérés par des fournisseurs, plus nous donnons le contrôle à des fournisseurs tels qu'Amazon, Microsoft, Microsoft, Google, en contrepartie de l'exécution de ces services en notre nom. Nous sommes en quelque sorte en train de dire: "Ok, Amazon, je pense que vous allez faire un bien meilleur travail pour gérer une fonction de plate-forme de service que John Chapin."

Avec cette perte de contrôle, nous abandonnons également notre capacité à configurer ces éléments à un niveau vraiment granulaire. Cependant, quel que soit le comportement du service Lambda, nous disposons d’un nombre assez limité d’options de configuration pour son fonctionnement. Nous avons beaucoup moins de possibilités d'optimisation, en particulier d'optimisation qui pourrait être spécifiquement liée à notre analyse de rentabilisation ou à notre scénario d'utilisation. Encore une fois, avec Lambda, nous avons un bouton à tourner. Nous devons ajuster la mémoire et affecter les performances, ainsi que la structure de notre code et autres choses du même genre, mais nous n’avons pas à y aller et à ajuster les paramètres du noyau Linux.

La dernière partie de cette perte de contrôle est cette idée de résolution de problème sans intervention. Qui se souvient ici de la chute de S3 il y a quelques années? Qui a joué un rôle direct dans la résolution de ce problème? Une personne ici … menteuse. Lorsque S3 tombe en panne, ce gars ici peut résoudre le problème. S3 est tombé en panne, nous avons tous construit des systèmes qui reposaient sur cela ou reposaient sur des systèmes qui s'appuyaient sur S3, et quand il était en panne, nous ne pouvions rien faire pour le rétablir, à moins de lancer des pagettes pour nos directeurs de comptes. Nous ne pouvions prendre aucune mesure de manière proactive pour le ramener. Nous devions faire confiance au vendeur pour le remettre en état. Nous perdons un peu le contrôle lorsque nous utilisons ces services gérés par des fournisseurs, ces services sans serveur ou, comme certains l'appellent maintenant, des services de service.

Élasticité

Avec tout cela à l'esprit – nous avons établi ce qui est sans serveur, quels sont certains des avantages et des inconvénients – parlons de la résilience. Cette citation, "Les échecs vont de soi et tout finira par échouer avec le temps". Voici une citation de Werner Vogels, directeur de la technologie d’Amazon, qui publie cet excellent article de blog intitulé "10 leçons de 10 ans d’AWS". Ce lien est également sur les diapositives. Je vous encourage fortement à aller lire ceci. Il parle essentiellement de 10 ans d'utilisation d'AWS à une échelle sans cesse croissante, et de ce qui se passe de la sorte.

Que dit-il à propos de l'échec? Il dit que les systèmes échoueront et qu'à l'échelle, les systèmes échoueront beaucoup. Ce qu’ils font chez AWS, c’est que l’échec est naturel. Nous savons que les choses vont échouer, alors nous allons simplement accepter ce fait. Ils essaient de concevoir leurs systèmes de manière à limiter le rayon de l'explosion des pannes, et nous verrons à quoi ressemblent certains de ces rayons. Ils essaient autant que possible de continuer à fonctionner et tentent de récupérer rapidement grâce à l'automatisation.

Je jette ça ici. Beaucoup de gens l'utilisent comme suit: "Nous faisons quelque chose de vraiment mauvais et ce n'est pas ce que nous voulons être." C'est en fait l'état actuel du nuage. Cela devrait dire: "Ceci est normal". Quelque chose échoue toujours et à grande échelle, certaines choses échouent toujours beaucoup. J'avais l'habitude de plaisanter sur le fait qu'il s'agissait d'une vue webcam de us-east-1 mais personne n'a ri. Je vous remercie.

Nous avons parlé de ce qui est sans serveur, nous avons parlé de la résilience, de ce que Werner Vogels avait à dire à propos de la résilience, alors à quoi ressemblent les échecs sur des terres sans serveur? Les architectures sans serveur ou de service sont toutes basées sur l'utilisation de ces services gérés par le fournisseur. Ce faisant, nous avons deux grandes catégories d'échecs, nous avons les échecs au niveau de l'application. Des choses comme «OK, nous avons livré du code incorrect» ou «Nous avons mal configuré notre infrastructure cloud» ou «Nous avons fait quelque chose pour que notre application échoue d'une manière ou d'une autre». Ces problèmes ont été causés par nous et peuvent également être résolus par nous. Nous pouvons corriger notre code, nous pouvons refaire notre formation Cloud, notre modèle Terraform ou le cas échéant.

Il y a cette classe d'échecs, puis il y a les échecs de service. Ce sont les choses comme S3 en baisse, par exemple. Du point de vue de nos clients, ces problèmes sont toujours notre problème. Si nos clients ne peuvent pas accéder à notre application, à notre site Web ou à d’autres raisons, ils nous en veulent toujours. La résolution, comme nous en avons parlé dans la première section, n’est pas à notre portée. Nous devons compter sur notre fournisseur pour résoudre le problème, c’est-à-dire, encore une fois, des défaillances d’application et de service.

Que pouvons-nous faire? Pouvons-nous réellement faire quelque chose lorsque ces services gérés par un fournisseur échouent? Cette présentation est vraiment sur la réponse à cette question, étant oui. Ce que nous allons essayer de faire est d’atténuer les défaillances de ces fournisseurs à grande échelle grâce à l’architecture. Nous n'avons aucun contrôle sur la résolution des défaillances graves des fournisseurs. Ok, S3 tombe en panne, aucun de nous, à l'exception du gars de la troisième rangée, ne peut réparer S3 en particulier, alors nous devons planifier en cas d'échec. Nous devons concevoir et construire nos applications pour être résilient.

Pour ce faire, nous allons tirer parti des mécanismes d'isolation conçus par les fournisseurs. Werner Vogels disait: "Vous devez limiter le rayon de l'explosion pour les échecs." Ils documentent ces rayons de souffle et disposent de mécanismes d'isolation (Amazon, Microsoft, Google, etc.). Nous allons tirer parti de ces mécanismes d'isolation – dans ce cas, ce seront des régions AWS – et des services des fournisseurs conçus et conçus spécifiquement pour fonctionner dans ces régions afin de nous aider à conserver notre application en hausse, même lorsque l'une de ces régions est en panne.

Ce dernier point, si je n’avais qu’une chose à dire, c’était une présentation spécifique à AWS – c’est en quelque sorte une présentation spécifique à AWS – ce serait: lisez le pilier de fiabilité du framework, bien conçu. Amazon, ainsi que Microsoft et Google, expliquent comment architecturer des applications pour tirer parti de leurs mécanismes d'isolation. Ils vous donnent les réponses ici même, alors je vous encourage fortement à aller vérifier cela. Si vous êtes sur l’un des autres nuages, cherchez la même information ici.

Parlons très rapidement des mécanismes d'isolation AWS. Je reviens sur cela car nous le verrons plus tard dans les diagrammes d'architecture et dans la démo. Ces grands cercles sont des régions AWS. Dans chaque région géographique, vous pouvez les appeler des centres de données logiques. AWS les appelle ces zones de disponibilité. Chaque zone de disponibilité constitue sa propre petite unité isolée d’alimentation, peut-être de réseau, et autres éléments nécessaires au centre de données, autres dont les serveurs ont besoin, et l’idée est que vous concevez votre application. Si vous utilisez quelque chose comme sur EC2, par exemple, vous pouvez avoir plusieurs instances virtuelles EC2 dans us-east-1a, plusieurs autres dans us-east-1b et l’idée est que vous auriez un équilibreur de charge devant vous. de celles. Si une zone de disponibilité tombe en panne, vous êtes toujours opérationnel dans une autre zone de disponibilité.

Il s'agit de la haute disponibilité régionale classique proposée par AWS. Il s’agit de services exécutés dans plusieurs zones de disponibilité. Un moyen rapide, vous pouvez donc le savoir: si le service que vous utilisez adresse des ressources, il les adresse au niveau de la zone de disponibilité. Lorsque vous démarrez un serveur EC2, le message "Dans quelle zone de disponibilité souhaitez-vous l'insérer?" Vous savez que c'est votre indice dès le départ: «D'accord, si je veux être résilient face à une défaillance de zone de disponibilité, j'ai besoin de plusieurs d'entre eux dans différentes zones», par opposition à des services tels que Lambda ou Dynamo auxquels vous vous adressez. au niveau régional. Nous allons parler de la façon dont nous les utilisons, mais je voulais juste en parler rapidement.

Résilience sans serveur sur AWS – nous avons parlé de haute disponibilité régionale, il s’agit de services exécutés sur plusieurs zones de disponibilité dans une région. EC2, c’est notre problème, nous devons concevoir nos applications pour le faire. Avec sans serveur, encore une fois, Lambda, Dynamo, S3, SNS, SQS, AWS s’occupe de cela pour nous. Nous disons: "Je veux juste Lambda dans nous-est-1, dans une région" ou "Je veux Lambda dans eu-west". AWS gère ce qui se passe si une zone de disponibilité dans cette région tombe en panne. Nous n'avons pas à nous inquiéter à ce sujet.

Pour franchir une nouvelle étape, la haute disponibilité globale, il s’agit de services exécutés dans plusieurs régions. Nous pouvons en fait concevoir l’application à ce niveau. Nous pouvons concevoir notre application pour tirer parti de plusieurs régions et bénéficier d'une haute disponibilité globale. Si une région entière de nous-est-1 tombe en panne, nous pouvons rester en activité. Je l'ai déjà mentionné, mais ce modèle de coûts sans serveur est l'un des avantages majeurs. Ce modèle sans serveur présente d'autres avantages lorsque nous essayons de créer ces applications globales. Cette idée de systèmes sans serveur et basés sur des événements, comme Lambda, ou d’API Gateway, dépend de la nature.

Lorsque vous combinez cela avec cette idée d'état externalisé dans quelque chose comme DynamoDB – et je pense que plusieurs des autres présentations sans serveur présentées à QCon cette année parlent de cette idée de systèmes sans serveur pilotés par événement ou de microservices sans serveur. Cela signifie que nous avons peu ou pas de données en vol en cas de panne et que ces données ont persisté dans des magasins extrêmement fiables. Si nous devons passer d’une région à l’autre, c’est vraiment transparent. Nous n'avons rien en vol dont nous ayons besoin de savoir quoi faire. Nous pouvons simplement passer de l'un à l'autre.

Une autre propriété de ces systèmes sans serveur, ce qui est surprenant, c’est que plusieurs systèmes ont tendance à être déployés en permanence parce qu’ils sont si difficiles à gérer autrement. Au moins c'est quelque chose que nous voyons. Lorsque vous avez ce déploiement continu, vous spécifiez toute votre infrastructure en code ou en configuration. Vous n'avez aucune de ces infrastructures persistantes à réhydrater. Si vous avez besoin que cela fonctionne dans de nombreuses régions, et nous verrons cela dans la démo, c'est très simple à faire, et souvent, cela vient naturellement.

Nous avons parlé de résilience, et ce style d’architecture tire non seulement de la résilience, mais nous obtenons à nouveau cette application mondiale distribuée qui est meilleure pour nos utilisateurs et qui ne coûtera peut-être pas beaucoup plus cher qu’une seule exécution. Région. Nous verrons cela dans la démo et dans le diagramme d'architecture, mais cette infrastructure régionale est plus proche de votre utilisateur régional. Si notre application est déployée dans nous-east-1 et dans eu-west-2, nous pouvons réellement diriger les utilisateurs de ces régions vers ces deux instances de l'application.

Parce que sans serveur est payer à la demande, ces coûts totaux sont similaires. Si la moitié de nos utilisateurs nous envoient-est-1 et l'autre moitié vers eu-west-2, notre facture totale sera la même que si tous les utilisateurs nous arrivaient-est-1 dans cette première région. Ce coût total par demande est à peu près le même. Infrastructure-as-code minimise le travail incrémentiel de déploiement dans cette nouvelle région. Par conséquent, si nous décidons "nous souhaitons évoluer en Asie-Pacifique", nous utilisons le même modèle de configuration et l'envoyons à Asie-Pacifique. la capacité de faire des déploiements automatisés multi-régions. J'ai un lien à la fin de cette présentation pour certains travaux réalisés par Symphonia, qui donnent un exemple de la procédure à suivre, mais cela facilite la mise à jour de cette infrastructure multirégionale. Le principe de cette discussion est vraiment que la nature des systèmes sans serveur permet d'architecter la résilience face aux défaillances des fournisseurs. Pas facile, mais possible.

Démo

Parlons de la démo. Nous allons créer une API globale hautement disponible, et je dis que nous allons la construire – je vais vous montrer et rendre le code source disponible pour vous afin que vous puissiez l'emporter chez vous et l'utiliser avec toi même. Nous allons créer une API globale hautement disponible. Le code source est là et les diapositives seront distribuées après. C'est un modèle SAM-Serverless Application Model-, du code Lambda, nous l'appellerons un frontal basique écrit en Elm. À quoi ressemble l'architecture, cependant?

Voici à quoi cette application ressemblera du côté de l’architecture. Imaginez que je me tiens vraiment à gauche avec un navigateur Web, un téléphone ou quelque chose du genre, et que j'utilise l'application frontale, et que cela envoie une demande au réseau. La première chose à faire est de dire: "Je dois prendre ce nom DNS et le traduire en adresse IP. Je veux cliquer sur api.resilient-demo.symphonia.io." Il envoie cette demande, cette demande est gérée par la Route 53; il s'agit du service DNS global d'AWS. La Route 53 regarde d'où je viens sur le réseau et renvoie une adresse IP la plus proche de moi en fonction des ressources disponibles pour cette application. Si je suis assis ici à New York, il va me donner une adresse IP à us-east-1 en Virginie. Si je suis assis à Londres ou en Europe, quelque part, cela me donnera une adresse IP située en Europe, en fait, dans la région de London, eu-west-2.

Sur cette base, à ce niveau supérieur, le trafic sera acheminé vers l'une des deux régions. Les fonctions Lambda déployées dans cette région vont gérer cette demande. Ils vont parler à deux tables DynamoDB. L'autre aspect intéressant est ce que AWS appelle une table globale DynamoDB. Nous avons essentiellement configuré deux tables DynamoDB miroir qui acceptent les droits, puis les propagent à leurs pairs en coulisse. Beaucoup de gens m'arrêtent et disent: "John, vous décrivez simplement quelques astuces sur le DNS et une certaine magie de la configuration AWS." Oui, c'est totalement le but ici. Pour survivre à ces échecs régionaux, nous devons concevoir de cette manière. Le fait est que nous pouvons le faire. J'ai décrit le flux de demandes ici. En revenant à ce diagramme d’architecture, nous verrons que les utilisateurs assis dans l’un de ces deux emplacements sont correctement acheminés. C’est donc mieux pour nos utilisateurs, c’est la bonne expérience utilisateur dont nous avons parlé. . Nous allons également voir, si nous simulons une panne, que le trafic peut également être redirigé. Nous aurons peut-être de la chance parce que nous sommes à l'est-1, mais si nous ne le sommes pas, je vais essentiellement échouer à l'examen de santé que Route 53 utilise pour déterminer les régions disponibles, et cela simulera une défaillance régionale. Ou peut-être que ce gars de la troisième rangée peut aussi nous aider, mais vous pouvez faire tomber S3 exprès cette fois-ci.

Nous avons parlé de simuler un échec. Passons directement à la démo. Je vais juste lancer ce petit front d’orme. Encore une fois, les instructions pour le faire sont dans le dépôt source, donc je vous encourage à le prendre et à l'expérimenter. La seule chose que vous devrez changer est la configuration DNS pour qu'elle corresponde au nom de domaine disponible, car vous ne pouvez pas utiliser le mien, c'est pris.

Je vais aller à Chrome ici, je vais aborder notre petit front-end. Ceci est une application de chat, ce que nous voyons ici n'est rien, alors laissez-moi mettre quelque chose ici, "Bonjour QCon". De toute évidence, à gauche, nous avons notre message, la source et la colonne de lecture. Cette colonne source nous dit que c'est là que le message est entré dans le système. Nous voyons ici que ce message a été accepté et traité par un Lambda de nous-est-1 et que nous utilisons actuellement WebSockets. Ce que cela nous dit aussi, c'est que ce message a été lu dans le système de us-east-1. Cela a du sens, assez simple, mais je veux juste expliquer ce que vous voyez ici.

La prochaine chose que nous voulons faire est d'aller de l'avant et de changer l'emplacement de notre réseau afin que le back-end, au moins, pense que nous venons d'Europe. Je vais simplement me rendre au Danemark via VPN. J'ai rafraîchi l'application. Notre message est là, notre message a été persisté, mais nous parlons maintenant d'une instance de cette application exécutée dans eu-west-2. Cette information est lue dans eu-west-2. Tout cela a du sens. Nous pouvons mettre un autre message dans le système, "Bonjour, QCon du Danemark." Nous pouvons voir que ce message a été accepté par notre application dans eu-west-2, puis lu à partir de là également. C'est assez facile, assez simple.

Revenons aux États-Unis. Je vais simplement rafraîchir mon propos et vous pouvez voir maintenant que nous lisons tous ces messages dans notre est-1. Je suis de retour aux États-Unis, cette application se comporte exactement comme nous l'espérions, en lisant les données de us-east-1, et je vais vous montrer où ces données se trouvent sur le back-end un peu plus tard dans la démo.

Maintenant, ce que nous allons faire, c'est simuler nous-est-1 en train de descendre. Sur le réseau, je suis ici à New York, je devrais être acheminé vers nous-est-1. Si nous nous rabattons vers l'est-1, si quelqu'un doit désactiver son service de téléavertisseur ou quelque chose du genre, le moment est venu. Voici comment nous allons procéder: nous allons passer à la route 53, à mes bilans de santé et vous voyez que j'ai deux bilans de santé ici – le premier est nous-est -1, le second est eu-west-2. J'ai trouvé que, pour les besoins de cette démonstration, le moyen le plus rapide de faire échouer une vérification de l'état de santé est de ne pas changer le code qui le sous-tend, mais bien de procéder à ce qu'on appelle l'inversion.

En gros, nous disons à la Route 53 de traiter les mauvais comme bons, et les bons comme les chats, comme des chiens, et de monter et descendre, et tout le reste. J'ai maintenant inversé ce bilan de santé, et nous allons attendre que cela passe de sain à malsain. Pendant que nous faisons cela, je vais simplement souligner la configuration de DynamoDB. DynamoDB est le magasin AWS hautement disponible et très performant. Nous avons une table de messages, et je suis donc assis ici dans nous-est-1. Je regarde les messages là-bas. Ceci est configuré pour recevoir des messages dans us-east-1 pour le trafic acheminé ici. Ces messages sont copiés sur la même table dans eu-west-2 à Londres. Je peux sauter et voir que j'ai la même table à Londres avec les mêmes messages.

Ce sont des tables globales DynamoDB, je vous encourage à y jeter un coup d'œil. Nous parlerons de certaines limitations plus tard, mais il s'agit d'un moyen très intéressant de disposer de ces applications globales qui partagent des données à travers différentes instances de l'application déployée. Je vais y retourner et vérifier la Route 53, voir si cette chose se révèle encore malsaine. La route 53 nous dit que ce bilan de santé est malsain. Si nous actualisions cette page, nous nous attendons à ce que nous lisions les données d'eu-west-2, de Londres, même si, sur le réseau, nous sommes toujours ici à New York.

Je vais essayer de rafraîchir ça. En fait, j'ai déjà touché ceci, il s'agit d'un problème de Chrome DNS, je vais donc faire une fenêtre de navigation privée ici, et vous pouvez voir que cela se lit maintenant dans eu-west-2. Cela ne semble pas beaucoup, mais nous avons échoué dans une région et notre demande a été maintenue. Je peux toujours interagir avec cette application, "Où sommes-nous-est-1-aller?" Nos utilisateurs peuvent toujours utiliser cette application. Les personnes assises à New York pourraient être acheminées vers l’Europe, mais cela reste à faire. Nous avons réussi l'architecture autour d'un échec régional AWS. Cela ne semble pas beaucoup à l'écran ici, mais c'est énorme.

Si vous aviez conçu cette architecture de la même manière lorsque S3 est tombé en panne il y a de nombreuses années, votre application aurait été maintenue et vos utilisateurs ne l'auraient jamais remarqué. Ils ont peut-être eu un peu plus de latence, mais c'est tout. AWS et les fournisseurs de cloud nous donnent la possibilité de le faire. Nous devons simplement en tirer parti et le faire. Je vais réinitialiser notre bilan de santé afin de nous ramener aux États-Unis, bien que nous ne puissions peut-être pas attendre. C’est notre démonstration d’une application disponible mondialement sur AWS.

Bords rugueux

Parlons de ce que sont certaines des aspérités de ceci. Bon nombre de ces contours sont spécifiques à AWS. Par conséquent, les tables globales, WebSockets, les domaines personnalisés et la formation de cloud ne fonctionnent pas très bien. Cela signifie que mon approche infrastructure-code, que je souhaite vraiment utiliser pour le déployer très facilement dans de nombreuses régions différentes, présente des aspérités et des éléments brisés. Je dois effectuer des actions manuelles pour que cela soit complètement configuré. Ces choses seront corrigées avec le temps.

Le troisième, si vous utilisez des tables globales, elles ne peuvent contenir aucune donnée lorsque vous les liez, c’est donc une grande réserve. Cet ensemble de piles en bas – Les ensembles de piles ne sont qu'un moyen pour AWS de se déployer facilement dans plusieurs régions à la fois. Nous pouvons réellement atténuer cela avec notre pipeline de déploiement. Quelques autres aspérités – et il s’agit là simplement de défis architecturaux. Malheureusement, je ne vois pas de diapositive à cet effet – mais votre application peut prendre en compte des considérations particulières pour accepter ou non les données écrites dans plusieurs régions. C'est un défi architectural à relever pour vous. Vos utilisateurs peuvent avoir besoin d'avoir des affinités avec une région ou une autre. Vous ne pourrez peut-être pas les déplacer ou accepter leurs données à plusieurs endroits pour des raisons de conformité ou pour d'autres raisons. Quelques aspérités et des problèmes d’architecture, mais nous avons montré que c’était tout à fait possible.

J'ai quelques liens ici pour le déploiement multi-régions. Il existe d'autres moyens d'architecter différentes applications, il existe donc une excellente documentation sur une nouvelle fonctionnalité d'Amazon CDN appelée Origin Failover. Cela signifie fondamentalement que je peux créer un CDN. Je peux avoir le magasin de support pour ce CDN, peut-être S3, ou base de données, ou quelque chose du genre. Si cette banque de sauvegarde devient indisponible, le cloud du CDN basculera vers un autre.

D'autres CDN, Fastly et CloudFlare, et des personnes de ce type possèdent ces fonctionnalités depuis un certain temps, mais elles sont désormais également disponibles sur AWS. Il existe Global Accelerator, qui vous permet de faire tout cela, mais à un niveau de réseau beaucoup plus fondamental. Je souhaite également attirer votre attention sur certaines ressources AWS. J'ai mentionné plus tôt ce cadre bien architecturé que vous devriez tous lire si vous exécutez des applications et construisez des applications sur Amazon.

Dans l'exposé de re: Invent 2016 intitulé "The Amazon Global Network Overview", James Hamilton explique en détail comment ils développent leur infrastructure globale, structurent les régions et les zones de disponibilité. Il parle de la mauvaise conception des interrupteurs de commutation de génératrices. C'est très profond et très intéressant, et il est incroyablement enthousiaste quand il en parle. Si vous utilisez Dynamo, je vous recommande vivement le discours de Rick Houlihan de l'an dernier sur re: Invent, "Modèles de conception avancés pour DynamoDB", et aborde également certains détails techniques autour des tables globales.

Ensuite, il existe une foule d’états de la technique relatifs à la construction de ces applications mondiales. Nous en avons rassemblé une partie dans cette démo aujourd'hui. Ensuite, Symphonia, nous avons également des ressources que je vous encourage à consulter. N'hésitez pas à nous envoyer un email ou à nous contacter sur Twitter si vous avez des questions ou si vous souhaitez simplement en parler davantage. J'aimerais que vous restiez en contact à nouveau. Je suis ouvert aux questions par email, Twitter.

questions et réponses

Participant 1: Cela semble être une belle histoire de chemin heureux. Pouvez-vous parler des problèmes, des pièges, des cas extrêmes auxquels nous ne pensons pas? Il s’agit là d’une belle voie évidente et heureuse pour faire des choses, et vous pourriez aussi avoir un routage au sein de votre région pour les défaillances locales-régionales, et cela va jusqu’au bout. Quels sont certains des problèmes? Quelles sont les choses que nous ne voyons pas ici?

Chapin: La question, pour reformuler et condenser un peu est, "Boy, John [Chapin], vous avez montré une belle voie heureuse ici, ce n’est sûrement pas toujours comme ça. Qu'est-ce qui peut aller mal? Pouvez-vous faire cela dans une région? "Ce que je voudrais revenir à la deuxième partie de la question," Est-ce que vous pouvez le faire dans une région ", est que si vous faites cela, vous n'utilisez probablement pas de composants sans serveur de toute façon et je vais donc simplement ne pas couvrir cela parce que nous nous concentrons sur les systèmes sans serveur pilotés par les événements dans ce cas.

J'ai souligné certaines des aspérités mineures quelque part ici. Ce sont les défis architecturaux. Si votre application n'est pas comme ça – quand je dis "pas comme ça", je veux dire, si votre application ne peut pas fonctionner comme ça – alors vous devez évidemment faire des choix différents. Nous comptons beaucoup sur les services disponibles au niveau mondial, ou sur ce qui devrait être des services disponibles au niveau mondial, tels que la Route 53. Il y a certainement eu des cas où la Route 53 a eu des problèmes. C'est un gros bord rugueux.

Cela étant dit, je préférerais qu'Amazon, ou Microsoft, ou Google, ou quiconque exploite un système DNS mondial, à moi. Vous pouvez également extraire la Route 53 de l'équation ici et utiliser également un fournisseur DNS tiers. Vous êtes toujours exposé à certaines défaillances de ces fournisseurs et à certaines de ces défaillances de service, mais à un niveau beaucoup plus élevé.

Participant 2: Ce type de routage est idéal lorsque votre service n'est absolument pas disponible, mais vous y avez laissé entendre que s'il y avait une panne de service, ou si vous aviez une chaîne dans les niveaux, et dans l'un des niveaux, il y avait une panne de service. Que devez-vous propager pour montrer cette défaillance jusqu'au routage afin qu'il puisse éventuellement être routé vers une autre région?

Chapin: La question est de savoir si vous avez plusieurs niveaux et au sein de ceux-ci, pouvez-vous rediriger ou pouvez-vous rendre compte des échecs?

Participant 2: Oui. L'échec n'est pas une disponibilité, peut-être fonctionnelle. Vous voudrez peut-être acheminer complètement vers l'autre région.

Chapin: Nous procédons de cette manière avec un bilan de santé produit par programme. Si votre défaillance est fonctionnelle, tenez-en compte dans votre bilan de santé. Votre bilan de santé peut comprendre non seulement "Est-ce que j'existe du tout", donc c'est là ou ce n'est pas. Cela pourrait également englober: "Est-ce que je reçois le bon type de données auquel je m'attendais?" Ou, "Est-ce que je produis les résultats nécessaires?" Ou quel que soit le cas.

Vous pouvez intégrer tout cela dans un bilan de santé. Il y a aussi beaucoup de danger là-bas, et vous courez parfois le risque de ré-implémenter une bonne partie de votre système dans le bilan de santé, mais c'est certainement possible. Une grande partie de cela peut être divisée en niveaux. Route 53, par exemple. Tout cela ne doit pas nécessairement se situer au début de votre demande. Cela pourrait être différents niveaux en son sein.

Participant 3: Vous avez mentionné que la base de données doit être configurée sans données. Comment feriez-vous pour implémenter ou intégrer, par exemple, une autre région? Est-ce quelque chose que vous avez fait, ou est-ce que vous attendez juste une solution?

Chapin: Les tables globales DynamoDB doivent être vides lorsque vous souhaitez les lier, les rendre globalement disponibles. La question pour moi était, avons-nous intégré des applications qui ont déjà des données dans une architecture comme celle-ci? La réponse est non. C'est tellement nouveau que nous ne l'utilisons pas encore beaucoup et j'attends une solution. La solution à cela serait un basculement manuel; vider toutes les données, créer une sauvegarde, puis très soigneusement déplacer les choses. Ce serait une danse cependant. Ce serait une douleur.

Participant 4: Sur les bords, vous avez mentionné que ce n'est pas disponible dans la formation de nuages?

Chapin: Oui.

Participant 4: Développez simplement cela. Est-ce qu'il suffit de le configurer manuellement et ce genre de choses?

Chapin: Oui. Le commentaire était, certains de ces services ne peuvent pas être configurés dans la formation de nuage. Pour rappel, la formation en nuage est le service d'infrastructure sous forme de code d'Amazon. J'ai un gros fichier YAML ou un fichier JSON, qui contient toutes mes ressources, un tas de fonctions Lambda, des passerelles d'API, peut-être des enregistrements DNS. Certaines des pièces que nous avons montrées dans cette architecture ne peuvent pas être configurées actuellement à l'aide de ce service d'infrastructure en tant que code.

Pour certaines de ces choses, en particulier le nom de domaine personnalisé pour WebSockets, vous devez soit aller dans la console AWS et le configurer manuellement, soit vous pouvez le faire par le biais d'appels d'API, mais là encore, vous devez écrire le script dans fais le. Terraform peut supporter cela, je n'ai pas essayé, en fait. The other piece of that is that linkage between DynamoDB tables across regions is the other thing that you can't do in cloud formation, in that infrastructure-as-code tool.

Participant 5: With the database having both rights, there could be data discrepancies and maybe two sites having a split-brain concept that could lead to data ambiguity and how consistent it is. If the rights are more, there may be a replication lag. How do we handle all these?

Chapin: I agree with all of those things. I didn't hear a question in there, but the comment was basically, "You have a dual master situation, or rights going to two tables in different regions at the same time. What do you do about the data?" The answer is, architect to build your application to handle that possibility. You could use convergent data structures. For example, in this case, this being a chat application, it's pretty straightforward just to have the messages be singular, and if we have duplication, we actually handle on the client's side, which if you dig into that app is actually what it does. You design your application with that in mind if you want this kind of system. No silver bullet, no magic there. You have to put in the work.

See more presentations with transcripts