Amazon s’explique sur la panne de la semaine dernière

Spread the love
Amazon s'explique sur la panne de la semaine dernière

Amazon Web Services (AWS) est revenu sur la cause de la panne générale de mercredi dernier, qui a touché des milliers de services en ligne pendant plusieurs heures.

AWS explique que la panne s’est produite dans sa région de Virginie du Nord, US-East 1. Elle s’est produite après un « ajout de capacités » à sa flotte de serveurs Kinesis.

Kinesis est utilisé par les développeurs, aux côtés d’autres services comme CloudWatch et l’authentification Cognito, pour capturer des données et des flux vidéo et les faire passer par les plateformes d’apprentissage automatique d’AWS. L’interface du service Kinesis gère l’authentification et distribue les charges de travail aux clusters de calcul via un mécanisme de base de données appelé sharding.

publicité

Déroulé de la panne

Comme le note AWS dans un résumé de la panne, l’ajout de capacités a déclenché la panne, mais n’en est pas la cause première. AWS ajoute des capacités pendant une heure, après 11h44 (heure française). Suite à cela, tous les serveurs de la flotte frontale Kinesis commencent à dépasser le nombre maximum de threads autorisé par la configuration actuelle du système d’exploitation.

La première alarme se déclenche à 14h15. Les ingénieurs d’AWS passent les cinq heures suivantes à essayer de résoudre le problème. Le fonctionnement des serveurs Kinesis est entièrement rétabli à 7h23, le lendemain matin.

Amazon explique comment les serveurs frontaux distribuent les données sur son back-end Kinesis : chaque serveur de la flotte de serveurs frontaux conserve un cache d’informations, comprenant les détails des membres et la propriété des shards pour les clusters back-end, appelé “shard-map”. Ces informations sont obtenues par des appels à un microservice qui distribue les informations sur les membres, la récupération des informations de configuration de DynamoDB et le traitement continu des messages provenant d’autres serveurs frontaux Kinesis.

Dépassement du nombre de threads autorisé

« Pour la communication [Kinesis], chaque serveur frontal crée des threads de système d’exploitation pour chacun des autres serveurs de la flotte frontale. Lors de tout ajout de capacité, les serveurs qui sont déjà des membres actifs de la flotte apprennent que de nouveaux serveurs les rejoignent et établissent les threads appropriés. Il faut jusqu’à une heure pour qu’un membre de la flotte frontale apprenne l’existence de nouveaux participants. »

Comme le nombre de threads a dépassé le nombre autorisé par la configuration du système d’exploitation, les serveurs frontaux se sont retrouvés avec des « shard-maps inutiles » et n’ont pas pu acheminer les requêtes vers les clusters back-end Kinesis.

AWS avait déjà réduit la capacité supplémentaire qui avait déclenché l’événement, mais craignait d’augmenter la limite des threads, au cas où cela retarderait la reprise.

Une page d’état de service non mise à jour

Dans un premier temps, AWS passe à des serveurs disposant de meilleurs processeurs et de plus de mémoire, et réduit le nombre total de serveurs et de threads requis par chaque serveur pour communiquer au sein de la flotte. L’entreprise teste également une augmentation des limites du nombre de threads dans la configuration de son système d’exploitation et travaille à« améliorer radicalement le temps de démarrage à froid pour la flotte du front ».

CloudWatch et d’autres services AWS importants seront transférés dans une flotte frontale séparée et cloisonnée. Le fournisseur travaille également sur un projet plus vaste visant à isoler les défaillances d’un service pour éviter qu’elles n’affectent les autres services.

AWS a également reconnu les retards dans la mise à jour de son tableau de bord public de l’état des services pendant l’incident. La société explique que l’outil utilisé par ses ingénieurs de support pour mettre à jour le tableau de bord public a été affecté par la panne. Cependant, AWS a informé ses clients via le Personal Health Dashboard.

Source : ZDNet.com

Leave a Reply