Amazon Web Services (AWS) tombe rarement en panne de manière inattendue, mais lorsque cela survient, le géant américain du Cloud computing fait généralement preuve de transparence. La preuve après l’une des dernières pannes majeures d’AWS, survenue mardi dernier. Celle-ci a duré cinq heures et a affecté les clients utilisant certaines interfaces d’application outre-Atlantique. Dans un Cloud public de l’envergure d’AWS, une panne de cinq heures est un incident majeur.
Selon l’explication d’AWS sur ce qui s’est passé, la source de la panne était un problème dans son réseau interne qui héberge des « services fondamentaux » 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 il s’agit du système utilisé pour traduire les noms de domaine lisibles par l’homme en adresses numériques Internet (IP).
Le réseau interne d’AWS est à la base de certaines parties du réseau principal d’AWS auquel la plupart des clients se connectent pour fournir leurs services de contenu. Normalement, lorsque le réseau principal s’étend pour répondre à une augmentation de la demande de ressources, le réseau interne devrait s’étendre proportionnellement via des dispositifs de mise en réseau qui gèrent la traduction d’adresses réseau (NAT) entre les deux réseaux. Ce mardi, la mise à l’échelle inter-réseaux ne s’est toutefois pas déroulée sans heurts, les dispositifs NAT d’AWS sur le réseau interne étant « débordés » et bloquant les messages de traduction entre les réseaux, ce qui a eu de graves répercussions sur plusieurs services clients qui, techniquement, n’ont pas été directement touchés.
Des dysfonctionnements majeurs
« Une activité automatisée visant à mettre à l’échelle 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 à l’intérieur du réseau interne », indique AWS dans un post d’entreprise. « Cela a entraîné une forte augmentation de l’activité de connexion qui a submergé les dispositifs de mise en réseau entre le réseau interne et le réseau AWS principal, ce qui a entraîné des retards pour la communication entre ces réseaux. » Ces retards ont engendré de la latence et des erreurs pour les services fondamentaux parlant entre les réseaux, déclenchant encore plus de tentatives de connexion ratées qui ont finalement conduit à « des problèmes persistants de congestion et de performance » sur les dispositifs du réseau interne.
La connexion entre les deux réseaux étant bloquée, l’équipe d’exploitation interne d’AWS a rapidement perdu la visibilité de ses services de surveillance en temps réel et a dû se fier aux 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. Ce travail a été achevé deux heures après la panne initiale. Cela a permis d’atténuer l’impact sur les services destinés aux clients, mais n’a pas permis de réparer complètement les services AWS affectés ni de débloquer la congestion des dispositifs NAT. En outre, l’équipe d’exploitation interne d’AWS ne disposait toujours pas de données de surveillance en temps réel, ce qui a ralenti la reprise et la restauration.
Outre le manque de visibilité en temps réel, les systèmes de déploiement internes d’AWS étaient entravés, ce qui ralentissait à nouveau les mesures correctives. La troisième cause majeure de cette réponse non optimale était la crainte qu’une correction des communications entre le réseau interne et le réseau principal ne perturbe d’autres services AWS orientés client qui n’étaient pas affectés. « Étant donné que de nombreux services AWS sur le réseau principal AWS et les applications des clients AWS fonctionnaient encore normalement, nous avons voulu être extrêmement prudents lors des modifications afin d’éviter d’avoir un impact sur les charges de travail en cours », ont fait savoir les équipes d’AWS.
Quels sont donc les services des clients AWS qui ont été touchés ?
Tout d’abord, le réseau principal d’AWS n’a pas été affecté, de sorte que les charges de travail des clients d’AWS n’ont pas été « directement touchées », selon AWS. Les clients ont plutôt été affectés par les services d’AWS qui reposent sur son réseau interne. Cependant, les répercussions de ce problème de réseau interne ont été très importantes pour les services AWS destinés aux clients, allant 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 des réseaux.
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, si les instances EC2 n’ont pas été touchées, les API EC2 que les clients utilisent pour lancer de nouvelles instances EC2 l’ont été. Une latence et des taux d’erreur plus élevés ont été les premiers impacts que les clients ont pu constater mardi matin.
Avec cette capacité disparue, les clients ont eu des problèmes avec Amazon RDS (services de bases de données relationnelles) et la plateforme 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. Dans le même temps, les Elastic Cloud Balancers (ELB) d’AWS n’ont pas été directement affectés mais, comme les API ELB l’ont été, les clients n’ont pas pu ajouter de nouvelles instances aux ELB existants aussi rapidement que d’habitude.
Un incident loin d’être isolé
Les API de 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 les services de jetons sécurisés Amazon Secure Token pour les services d’identité tiers, des retards pour CloudWatch, et un accès altéré aux buckets Amazon S3, aux tables DynamoDB via les points de terminaison VPC, et des problèmes pour invoquer les fonctions Lambda sans serveur.
L’incident du 7 décembre partage au moins un trait avec une panne majeure survenue l’année dernière à la même époque : 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é notre outil Service Health Dashboard de basculer de manière appropriée vers notre région de secours », explique AWS. En outre, le centre d’assistance d’AWS s’appuie sur le réseau interne d’AWS, de sorte que le personnel n’a pas pu créer de nouveaux cas à une vitesse normale pendant les cinq heures de perturbation.
Le géant américain indique qu’il publiera une nouvelle version de son tableau de bord de santé des services début 2022, qui fonctionnera dans plusieurs régions afin de « s’assurer que nous n’avons pas de retard dans la communication avec les clients. » Rappelons que les pannes de cloud se produisent de temps à autre. Google Cloud a eu sa part du gâteau et Microsoft, en octobre, a dû expliquer sa panne de huit heures. Bien que rares, ces pannes rappellent que le cloud public est peut-être plus fiable que les centres de données traditionnels, mais que les choses peuvent mal tourner, parfois de façon catastrophique, et avoir un impact sur un grand nombre de services critiques.
Source : ZDNet.com
