Le 25 novembre dernier, à partir de 5 h 15 heure normale du pacifique (HNP) (correspondant à 14 h 15 heure de Paris), les services d’Amazon ont commencé à être indisponibles. Cette indisponibilité a perduré toute la nuit jusqu’au lendemain à 7 h 31 heure de Paris où les derniers services cloud ont été entièrement remis en fonction.Pour comprendre comment une panne d’une telle ampleur est survenue, Amazon, le géant de services cloud, explique que de 2 h 44 à 3 h 47 heure normale du Pacifique, l’entreprise a procédé à un ajout de capacité pour améliorer l’efficacité de Kinesis. Amazon Kinesis est un service de traitement en temps réel des données en streaming. Il s’appuie sur un grand nombre de clusters de cellules « ;back-end ;» pour le traitement de ces flux. Les flux sont répartis sur le back-end via un mécanisme de partitionnement appartenant à une flotte de serveurs « ;front-end ;». En plus d’être utilisé par les clients, Kinesis est également utilisé par Amazon pour gérer plusieurs autres services AWS (Amazon Web Services).
Alors que les ingénieurs d’Amazon avaient achevé l’augmentation de la capacité de la partie frontale, des erreurs ont commencé à se déclencher un peu plus d’une heure après l’achèvement de ces travaux. Il faut noter qu’après tout ajout de capacité, il faut attendre jusqu’à une heure pour que les serveurs qui sont déjà des membres opérationnels de la flotte détectent les nouveaux serveurs ajoutés et établissent les threads appropriés. Au vu de ces messages d’erreur, les équipes d’Amazon ont commencé à supprimer la nouvelle capacité tout en recherchant les autres erreurs. Toutefois, le travail de diagnostic a été ralenti par la variété des erreurs observées. Après plusieurs recherches, la division AWS a pu réduire la cause du problème à quelques candidats à 7 h 51 HNP et déterminer que l’une des sources les plus probables du problème nécessiterait un redémarrage complet de la flotte frontale. Cependant, l’équipe de Kinesis savait que ce serait un processus long et minutieux, car Kinesis contient des milliers de serveurs et seules quelques centaines de serveurs peuvent être redémarrés par heure.
À 9 h 39 HNP, l’équipe a pu confirmer que la cause du problème n’était pas motivée par une pression de mémoire, mais plutôt liée à un dépassement du nombre maximum de threads (files d’exécution) autorisé au niveau de chaque configuration du système d’exploitation (SE) des serveurs de la flotte. Et à mesure que cette limite était dépassée, la construction du cache ne se terminait pas et les serveurs frontaux se retrouvaient avec des cartes de partition inutiles qui les empêchaient d’acheminer les demandes vers les clusters back-end. À partir de 10 h 7 HNP, l’équipe d’Amazon a commencé à remettre en état de marche le premier groupe des serveurs frontaux. Heure après heure, les ingénieurs d’Amazon ont lentement accru le trafic de la flotte de serveurs frontaux et à partir de midi, le taux d’erreurs a commencé à décroître progressivement au niveau de Kinesis. À 22 h 23, Kinesis a été complètement restauré.
Bien évidemment durant tout le temps de la panne, plusieurs services dépendant de Kinesis ont été affectés. Amazon Cognito qui utilise Kinesis Data Streams pour collecter et analyser les modèles d’accès aux API a dans un premier temps fonctionné avec une latence élevée pour finalement s’interrompre. En conséquence, les clients Cognito ont connu des échecs d’API élevés et des latences accrues pour les groupes d’utilisateurs et les groupes d’identités Cognito, ce qui empêchait les utilisateurs externes de s’authentifier ou d’obtenir des informations d’identification AWS temporaires. Ce service a été pleinement rétabli à 14 h 18 HNP.
CloudWatch qui utilise Kinesis Data Streams pour le traitement des métriques et des données de journal a également enregistré une augmentation des taux d’erreur et des latences pour les API PutMetricData et PutLogEvents ; de même, les alarmes sont passées à l’état INSUFFICIENT_DATA. Alors que certaines métriques CloudWatch ont continué à être traitées tout au long de l’événement, l’augmentation des taux d’erreur et des latences a empêché la grande majorité des métriques d’être traitées avec succès. À 17 h 47 HNP, CloudWatch a commencé à voir des signes précoces de récupération à mesure que la disponibilité de Kinesis Data Stream s’améliorait et à 22 h 31 HNP, les métriques et les alarmes CloudWatch étaient complètement rétablies. Pour éviter que ce problème ne se reproduise, Amazon a modifié les serveurs Web Cognito afin qu’ils puissent gérer les erreurs d’API Kinesis sans épuiser leurs tampons.
CloudWatch Events et EventBridge ont aussi connu une augmentation d’erreurs d’API, ainsi que des retards dans le traitement des événements à partir de 5 h 15 HNP. Au fur et à mesure que la disponibilité de Kinesis s’améliorait, EventBridge a commencé à fournir de nouveaux événements et à traiter lentement les événements plus anciens. Étant donné qu’Elastic Container Service (ECS) et Elastic Kubernetes Service (EKS) utilisent tous deux EventBridge pour piloter les flux de travail internes utilisés pour gérer les clusters et les tâches des clients, cela a eu un impact sur l’approvisionnement des nouveaux clusters, retardé la mise à l’échelle des clusters existants et causé un impact sur le dé-provisionnement des tâches. À 16 h 15 HNP, la majorité de ces problèmes avaient été résolus.
Deux autres services ont également été touchés en raison des problèmes liés aux métriques CloudWatch. Premièrement, les politiques d’AutoScaling réactives qui reposent sur les métriques CloudWatch ont connu des retards jusqu’à ce que les métriques CloudWatch commencent à récupérer à 17 h 47 HNP. Et deuxièmement, les appels de fonction Lambda ont connu des erreurs à cause du fait qu’ils s’appuient sur la publication des métriques de CloudWatch dans le cadre des appels. À 10 h 36 HNP, les ingénieurs ont pris des mesures qui ont permis de résoudre les taux d’erreur accrus pour les appels de fonction. En dehors des problèmes de service, Amazon rapporte également qu’il a eu des difficultés pour communiquer avec clients sur l’état de ses services.
À la suite de ces incidents, Amazon présente ses excuses à ses clients pour l’impact que cet événement a eu sur leurs activités et déclare qu'il compte tirer des leçons pour améliorer encore plus la disponibilité de ses infrastructures et services cloud. À très court terme, l’entreprise prévoit de passer à des serveurs dotés de CPU et de mémoire plus grands afin de réduire le nombre total de serveurs et, par conséquent, les threads requis par serveur pour communiquer à travers son parc.
Source : Amazon
Et vous ?
Que pensez-vous de cette panne ;? De quoi remettre en cause la fiabilité des services cloud d’Amazon ;? Avez-vous été impacté par cette panne ;? Comment l’avez-vous gérée à votre niveau ;?Voir aussi
Cloud AWS : Amazon S3 touché par de fortes perturbations ce 28 février, rendant ainsi plusieurs sites et services inaccessibles Panne OVH : l'hébergeur revient sur le dernier incident qu'il a connu avec plus de détails Des possesseurs d'aspirateurs et de sonnettes dits « intelligents » se retrouvent dans l'incapacité d'en faire usage les serveurs d'Amazon étant en panne : l'IoT est-il plus dangereux qu'utile ? Des millions de sites web à travers le monde tombent en panne à la suite d'une panne de Cloudflare causée par un mauvais déploiement de logiciel