AWS : Voici ce qui n’a pas fonctionné lors de notre grande panne de cloud computing | ZDNet

La dernière des pannes majeures d’AWS s’est produite à 7h30 PST le mardi 7 décembre, a duré cinq heures et a affecté les clients utilisant certaines interfaces d’application dans la région US-EAST-1. Dans un cloud public à l’échelle d’AWS, une panne de cinq heures est un incident majeur.

Selon l’explication d’AWS sur ce qui s’est mal passé, la source de la panne était un problème dans son réseau interne qui héberge des « services de base » tels que la surveillance des applications/services, le service de nom de domaine (DNS) interne d’AWS, l’autorisation et des parties du Plan de contrôle du réseau Elastic Cloud 2 (EC2). Le DNS était important dans ce cas car c’est le système utilisé pour traduire les noms de domaine lisibles par l’homme en adresses Internet (IP) numériques.

VOIR: Avoir un seul fournisseur de cloud, c’est la dernière décennie

Le réseau interne d’AWS sous-tend des parties du réseau AWS principal auquel la plupart des clients se connectent afin de fournir leurs services de contenu. Normalement, lorsque le réseau principal évolue pour répondre à une augmentation de la demande de ressources, le réseau interne doit évoluer proportionnellement via des périphériques réseau qui gèrent la traduction d’adresses réseau (NAT) entre les deux réseaux.

Cependant, mardi la semaine dernière, la mise à l’échelle entre les réseaux ne s’est pas déroulée sans heurts, les appareils AWS NAT sur le réseau interne devenant « submergés », bloquant les messages de traduction entre les réseaux avec de graves effets d’entraînement pour plusieurs services clients qui , techniquement, n’ont pas été directement impactés.

« À 7 h 30 PST, une activité automatisée visant à faire évoluer la capacité de l’un des services AWS hébergés dans le réseau AWS principal a déclenché un comportement inattendu de la part d’un grand nombre de clients au sein du réseau interne », déclare AWS dans son post-mortem.

« Cela a entraîné une forte augmentation de l’activité de connexion qui a submergé les périphériques réseau entre le réseau interne et le réseau AWS principal, entraînant des retards de communication entre ces réseaux. »

Les retards ont entraîné une latence et des erreurs pour les services fondamentaux qui communiquent entre les réseaux, déclenchant encore plus de tentatives de connexion infructueuses qui ont finalement conduit à des « problèmes de congestion et de performances persistants » sur les périphériques réseau internes.

La connexion entre les deux réseaux étant bloquée, l’équipe d’exploitation interne d’AWS a rapidement perdu la visibilité sur ses services de surveillance en temps réel et a été forcée de s’appuyer sur les journaux d’événements passés pour déterminer la cause de la congestion. Après avoir identifié un pic d’erreurs DNS internes, les équipes ont détourné le trafic DNS interne des chemins bloqués. Ces travaux ont été achevés deux heures après la panne initiale à 9 h 28 HNP.

Cela a atténué l’impact sur les services destinés aux clients, mais n’a pas complètement corrigé les services AWS affectés ni débloqué la congestion des appareils NAT. De plus, l’équipe d’exploitation interne d’AWS manquait toujours de données de surveillance en temps réel, ce qui ralentissait par la suite la récupération et la restauration.

Outre le manque de visibilité en temps réel, les systèmes de déploiement internes d’AWS ont été entravés, ralentissant à nouveau la correction. La troisième cause majeure de sa réponse non optimale était la crainte qu’un correctif pour les communications réseau interne-principal ne perturbe d’autres services AWS destinés aux clients qui n’ont pas été affectés.

« Étant donné que de nombreux services AWS sur le réseau AWS principal et les applications clientes AWS fonctionnaient toujours normalement, nous voulions être extrêmement délibérés tout en apportant des modifications pour éviter d’avoir un impact sur les charges de travail opérationnelles », a déclaré AWS.

Alors, quels services clients AWS ont été impactés ?

Tout d’abord, le réseau AWS principal n’a pas été affecté, de sorte que les charges de travail des clients AWS n’ont « pas été directement affectées », déclare AWS. Au contraire, les clients ont été affectés par les services AWS qui reposent sur son réseau interne.

Cependant, les effets d’entraînement du problème de réseau interne ont été considérables pour les services AWS destinés aux clients, affectant tout, des services de calcul, de conteneurs et de distribution de contenu aux bases de données, à la virtualisation des postes de travail et aux outils d’optimisation de réseau.

Les plans de contrôle AWS sont utilisés pour créer et gérer les ressources AWS. Ces plans de contrôle ont été affectés car ils sont hébergés sur le réseau interne. Ainsi, alors que les instances EC2 n’étaient pas affectées, les API EC2 que les clients utilisent pour lancer de nouvelles instances EC2 l’étaient. Une latence et des taux d’erreur plus élevés ont été les premiers impacts que les clients ont vus à 7h30 PST.

VOIR: La sécurité du cloud en 2021 : un guide d’entreprise sur les outils essentiels et les meilleures pratiques

Une fois cette capacité supprimée, les clients ont eu des problèmes avec Amazon RDS (services de base de données relationnelle) et la plate-forme de Big Data Amazon EMR, tandis que les clients avec le service de virtualisation de bureau géré d’Amazon Workspaces ne pouvaient pas créer de nouvelles ressources.

De même, les Elastic Cloud Balancers (ELB) d’AWS n’ont pas été directement affectés mais, comme les API ELB l’étaient, les clients ne pouvaient pas ajouter de nouvelles instances aux ELB existants aussi rapidement que d’habitude.

Les API Route 53 (CDN) ont également été altérées pendant cinq heures, empêchant les clients de modifier les entrées DNS. Il y a également eu des échecs de connexion à la console AWS, une latence affectant Amazon Secure Token Services pour les services d’identité tiers, des retards vers CloudWatch et un accès altéré aux compartiments Amazon S3, aux tables DynamoDB via les points de terminaison VPC et des problèmes d’appel des fonctions Lambda sans serveur.

L’incident du 7 décembre partageait au moins un trait avec une panne majeure survenue à la même époque l’année dernière : il a empêché AWS de communiquer rapidement avec les clients au sujet de l’incident via le tableau de bord AWS Service Health.

« La dégradation de nos systèmes de surveillance a retardé notre compréhension de cet événement et la congestion du réseau a empêché nos outils de tableau de bord de santé des services de basculer de manière appropriée vers notre région de veille », a expliqué AWS.

De plus, le centre de contact d’assistance AWS s’appuie sur le réseau interne d’AWS, de sorte que le personnel n’a pas pu créer de nouveaux cas à vitesse normale pendant les cinq heures d’interruption.

AWS annonce qu’il publiera une nouvelle version de son tableau de bord de santé des services au début de 2022, qui s’exécutera dans plusieurs régions pour « s’assurer que nous n’avons pas de retards dans la communication avec les clients ».

Des pannes de cloud se produisent. Google Cloud a eu sa part de tarif et Microsoft a dû expliquer en octobre sa panne de huit heures. Bien que rares, les pannes rappellent que le cloud public est peut-être plus fiable que les centres de données conventionnels, mais les choses tournent mal, parfois de manière catastrophique, et peuvent avoir un impact sur un grand nombre de services critiques.

« Enfin, nous voulons nous excuser pour l’impact que cet événement a causé à nos clients », a déclaré AWS. « Bien que nous soyons fiers de notre historique de disponibilité, nous savons à quel point nos services sont essentiels pour nos clients, leurs applications, leurs utilisateurs finaux et leurs entreprises. Nous savons que cet événement a eu un impact significatif sur de nombreux clients. Nous ferons tout notre possible. d’apprendre de cet événement et de l’utiliser pour améliorer encore plus notre disponibilité. »