Dans cet article, nous aimerions partager les détails de l'interruption de service survenue dans le nord de la Virginie (US-EAST-1) le 25 novembre 2020.
Amazon Kinesis collecte, traite et analyse les données de streaming en temps réel. En plus de son utilisation directe par les clients, il est impliqué dans un certain nombre de services AWS. Ces services ont également souffert d'une panne. Le déclencheur (mais pas la cause principale) de cet événement était l'ajout relativement faible de capacité au service, commençant à 2 h 44 PST et se terminant à 3 h 47.
À propos de l'appareil Kinesis
Kinesis utilise un grand nombre de clusters "back-end" de cellules (cellules) qui traitent les flux de données. Ce sont les bêtes de somme de Kinesis. Ils sont responsables de la distribution, de l'accès et de la mise à l'échelle du streaming. Les flux sont distribués par les serveurs frontaux aux serveurs principaux à l'aide de la partition. Le cluster backend "possède" de nombreux fragments et fournit une mise à l'échelle cohérente et une isolation des pannes. Le travail frontal dans notre cas est petit, mais important. Il est responsable de l'authentification, de la limitation et du routage des demandes vers les fragments de thread appropriés sur les clusters backend.
Nous ajoutions de nouvelles capacités au parc de machines frontales. Chaque serveur frontal forme un cache de données, y compris des informations sur l'appartenance et les propriétaires de fragments (parmi les clusters principaux), formant ce que l'on appelle une carte de partition. Il obtient ces informations en envoyant des demandes au service qui fournit des informations d'appartenance et en récupérant les données de configuration de DynamoDB.
De plus, chaque serveur traite en permanence les messages des autres serveurs frontaux Kinesis. Pour ce faire, des threads sont créés dans le système d'exploitation de chaque machine frontale pour chacun des serveurs frontaux. Lorsque de nouvelles capacités sont ajoutées, les serveurs qui fonctionnent déjà dans le parc frontend découvrent les nouveaux membres et créent les flux correspondants. Il faut jusqu'à une heure à chaque serveur frontal existant pour connaître les nouvelles machines.
Diagnostics et résolution de problèmes
À 5h15 PST, les premiers messages d'erreur sont apparus lors de l'écriture et de la récupération des enregistrements Kinesis. Nos équipes ont immédiatement commencé à étudier les logs. Les soupçons sont immédiatement tombés sur les nouvelles capacités, mais certaines des erreurs n'étaient en aucun cas liées aux nouvelles machines et, très probablement, ne seraient pas allées nulle part, même si nous supprimions toutes les nouvelles capacités.
Néanmoins, par précaution, nous avons néanmoins commencé à les supprimer, en essayant en cours de route d'établir la cause d'autres erreurs. Leur grande variété a ralenti notre diagnostic. Nous avons vu des bogues dans tous les aspects de toutes sortes d'appels effectués par les membres existants et nouveaux du parc de machines frontales, ce qui a rendu assez difficile la séparation des effets secondaires de la cause première.
À 7 h 51 PST, nous avons réduit les suspects à quelques candidats et déterminé que l'une des causes les plus probables nécessiterait un redémarrage complet du front-end. L'équipe Kinesis savait très bien que ce processus devait être lent et détaillé.
Le fait est que le remplissage de la carte de partition est en concurrence avec le traitement des demandes entrantes pour les ressources du serveur frontal. Ainsi, la remise en ligne trop rapide des serveurs frontaux créera un conflit entre les deux processus et en laissera trop peu pour traiter les demandes entrantes. Le résultat est prévisible: une augmentation des taux d'erreur et une augmentation des latences. De plus, la lenteur des serveurs frontaux peut être perçue comme un signe de mauvaise santé, ce qui peut entraîner leur retrait de la liste des serveurs disponibles, ce qui ralentira encore davantage le processus de récupération.
Toutes les solutions possibles impliquaient de modifier la configuration de chaque serveur frontal et de le redémarrer. Alors que notre principal candidat pour la source de nos problèmes (un problème qui semblait mettre la mémoire sous pression) semblait prometteur, si nous nous trompions, nous risquions de doubler le temps de récupération, car nous devions tout réparer et tout redémarrer. Pour accélérer le redémarrage, parallèlement à l'enquête, nous avons commencé à apporter des modifications à la configuration des serveurs frontaux, vous permettant de recevoir des données directement du magasin de métadonnées au moment du démarrage, et non des voisins frontaux.
raison principale
À 21 h 39 PST, nous avons enfin pu confirmer la cause première du crash. Il s'est avéré que ce n'était pas lié à la mémoire. L'ajout de nouvelles capacités a entraîné le nombre de threads sur tous les serveurs frontaux dépassant le maximum possible, autorisé par la configuration du système. Étant donné que la limite a été dépassée, le cache (cartes de partition) n'a pas pu être créé. Par conséquent, les serveurs frontaux n'ont pas pu transmettre les demandes aux clusters principaux.
Nous ne voulions pas augmenter la limite de thread dans le système d'exploitation sans tests préliminaires, et comme la capacité supplémentaire avait déjà été supprimée à ce moment-là, nous avons décidé que le risque de dépasser la limite du système sur le nombre de threads était minime et avons continué à redémarrer les serveurs. Le premier groupe de nouvelles interfaces a commencé à accepter le trafic Kinesis à 10h07 PST.
La flotte frontale se compose de plusieurs milliers de serveurs, et pour les raisons décrites ci-dessus, nous pourrions ajouter des serveurs à une vitesse ne dépassant pas quelques centaines par heure. Nous avons continué à ajouter lentement du trafic vers le frontend, notant la baisse constante des erreurs de service Kinesis depuis midi. Le service a complètement rebondi à 22h23 PST.
Qu'avons-nous appris
Nous avons tiré plusieurs leçons de l'incident de Kinesis et prévoyons d'apporter des corrections dans un proche avenir.
- , CPU . , , , . , . , .
- .
- , . , .
- -. - AWS ( CloudWatch) , -.
- (cellularization) ( , ). ( -) . Kinesis , , , . / , , .
Le crash a également affecté certains services utilisant Kinesis.
Amazon Cognito utilise Kinesis Data Streams pour collecter et analyser les modèles d'accès aux API. Bien que ces informations soient extrêmement utiles pour le fonctionnement du service Cognito, leur livraison n'est pas garantie (au mieux) . Les données sont mises en mémoire tampon localement pour aider le service à faire face à la latence ou à de courtes périodes d'indisponibilité dans le service Kinesis Data Streams.
Malheureusement, l'indisponibilité prolongée de Kinesis Data Streams a révélé un bogue latent dans le code de mise en mémoire tampon qui a amené les serveurs Web Cognito à commencer à bloquer les tampons Kinesis Data Stream. En conséquence, les consommateurs de Cognito ont été confrontés à des problèmes d'API et à une latence accrue pour les groupes d'utilisateurs et les groupes d'identité Cognito. Les utilisateurs externes n'ont pas pu s'authentifier ou obtenir des informations d'identification AWS temporaires.
Au début de la panne, l'équipe de Cognito a tenté d'atténuer l'impact des bogues de Kinesis en ajoutant de la capacité supplémentaire et en augmentant ainsi la capacité de mise en mémoire tampon des appels de Kinesis. Au départ, cela a eu un effet positif sur le service, mais à 7 h 01 HNP, le taux d'erreur avait considérablement augmenté. En parallèle, l'équipe a travaillé pour réduire la dépendance de Cognito vis-à-vis de Kinesis. A 10h15, cette solution a été déployée et le taux d'erreur a commencé à baisser. À 12 h 15, le taux d'erreur avait considérablement baissé et à 14 h 18, heure du Pacifique, Cognito fonctionnait normalement. Pour éviter que ce problème ne se reproduise, nous avons modifié les serveurs Web Cognito. Ils peuvent désormais tolérer les erreurs d'API Kinesis sans épuiser leurs tampons (ce qui entraîne des problèmes pour les utilisateurs).
CloudWatchutilise Kinesis Data Streams pour traiter les métriques et les journaux. À partir de 5 h 15, CloudWatch rencontrait des erreurs et des latences croissantes pour les API PutMetricData et PutLogEvents, et les alertes sont entrées en état
INSUFFICIENT_DATA. Alors que certaines métriques CloudWatch ont continué à être traitées pendant la panne, la plupart d'entre elles ont été victimes de nombreuses erreurs et d'une latence accrue.
À 17 h 47 PST, les premiers signes de récupération sont apparus au fur et à mesure que la situation de Kinesis Data Stream s'améliorait, et à 22 h 31, les métriques et alertes CloudWatch s'étaient complètement rétablies. Dans les heures qui ont suivi, le traitement des métriques et des journaux retardés s'est poursuivi. Alors que CloudWatch était aux prises avec des bogues, les clients internes et externes n'étaient pas en mesure de fournir des données de métriques à CloudWatch. En conséquence, il existe des lacunes dans les données de métriques CloudWatch.
Pour le moment, le service CloudWatch s'appuie sur Kinesis pour collecter les métriques et les journaux, mais son équipe mettra bientôt en œuvre un changement après quoi CloudWatch stockera les données pendant trois heures dans le stockage local. Cette modification permettra aux utilisateurs et aux services liés aux métriques CloudWatch (y compris AutoScaling) d'accéder directement aux métriques nouvellement collectées (dans la banque de données CloudWatch sur site). Cette idée a déjà été mise en œuvre dans la région US-EAST-1 et dans les semaines à venir, nous prévoyons de la déployer à l'échelle mondiale.
Deux autres services sont devenus les otages de problèmes avec les métriques CloudWatch:
- Premièrement, les politiques d' AutoScaling basées sur les métriques CloudWatch ont connu une latence jusqu'à 17 h 47, moment où CloudWatch a commencé à rebondir.
- -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .
CloudWatch Events et EventBridge ont connu une augmentation des erreurs d'API et de la latence dans le traitement des événements à partir de 5 h 15 HE. Après avoir amélioré la disponibilité, Kinesis EventBridge a repris la livraison des nouveaux événements aux destinataires, tout en traitant l'arriéré d'événements en cours de route.
Elastic Container Service (ECS) et Elastic Kubernetes Service (EKS) utilisent EventBridge dans leurs flux de travail internes pour gérer les clusters clients et les tâches. Cela a affecté le provisionnement de nouveaux clusters, retardé la mise à l'échelle des clusters existants et affecté le déprovisionnement des tâches. À 16 h 15 PST, la plupart de ces problèmes avaient été résolus.
Notification client
En plus des difficultés de services, au tout début de l'incident, nous avons rencontré certains retards dans la communication des informations sur l'état des services aux clients.
Nous avons deux manières de communiquer avec les clients lors d'événements opérationnels:
- Service Health Dashboard - Un tableau de bord accessible au public pour alerter les problèmes opérationnels importants;
- Tableau de bord de santé personnel - pour une notification directe des clients concernés.
Lors d'événements comme celui-ci, nous publions généralement des informations dans le tableau de bord Service Health. Cependant, dans ce cas, au tout début de l'incident, nous n'avons pas pu mettre à jour les informations du tableau de bord Service Health, car l'outil utilisé pour publier les mises à jour est utilisé par Cognito en panne.
Nous avons une méthode de secours pour mettre à jour le tableau de bord Service Health avec des dépendances de service minimales. Cela a fonctionné comme prévu, mais nous avons connu des retards lors de la publication des informations sur le tableau de bord Service Health au début de l'événement. Le fait est que cet outil de sauvegarde est beaucoup moins automatisé et moins familier aux opérateurs de helpdesk.
Pour garantir la livraison en temps opportun des mises à jour à tous les clients concernés, l'équipe de support a profité du tableau de bord de santé personnel pour les alerter des problèmes de service potentiels. Nous avons également mis en place une bannière mondiale avec des informations à jour dans le tableau de bord Service Health pour nous assurer que les utilisateurs sont pleinement informés de l'incident. Jusqu'à la fin du crash, une combinaison du tableau de bord de la santé des services (avec des résumés sur les bannières mondiales et des détails sur le fonctionnement de services spécifiques) et le tableau de bord de la santé personnelle s'est poursuivie, où nous avons essayé de garder les clients touchés par des problèmes de services à jour. Sur la base de notre expérience, nous avons introduit des exercices obligatoires avec un système de secours pour publier des messages sur le tableau de bord Service Health dans notre formation régulière d'ingénieur de support.
...
Enfin, je tiens à m'excuser pour l'impact négatif que cet incident a eu sur nos clients. Nous sommes fiers de la haute disponibilité d'Amazon Kinesis et sommes bien conscients de l'importance de ce service et d'autres services AWS pour nos clients, leurs applications / utilisateurs finaux et leurs activités. Nous ferons de notre mieux pour tirer les leçons de cet incident et l'utiliser pour améliorer encore l'accessibilité.
PS
Lisez aussi sur notre blog: