Résumé

  • L'ajout de serveurs Kinesis a augmenté le travail de communication de chaque serveur frontal, jusqu'à dépasser une limite de threads fixée par le système d'exploitation.
  • Une fois le problème identifié, il fallait encore reconstruire les informations de routage sans étouffer les demandes des clients. Le redémarrage avait sa propre limite de débit.

Pour améliorer Kinesis après sa panne du 25 novembre 2020, AWS comptait notamment mettre en service des machines plus puissantes. L'objectif était d'avoir moins de serveurs. Voilà un remède que les affiches vantant une croissance sans limite auraient eu du mal à illustrer.

Le compte rendu d'AWS explique ce paradoxe avec une franchise utile. Dans la région de Virginie du Nord, une modeste augmentation du nombre de serveurs frontaux avait fait dépasser à toute la flotte un plafond de threads du système d'exploitation. L'extension avait déclenché l'incident ; le plafond et la manière dont la flotte communiquait expliquaient la panne.

La différence est commerciale autant que technique. Une machine neuve peut apporter de la puissance tout en donnant du travail aux machines déjà en place. Pour acheter la première, il faut savoir combien coûte le second.

Un carnet d'adresses devenu trop lourd

Les serveurs frontaux de Kinesis authentifiaient les demandes, limitaient leur débit et les dirigeaient vers les bonnes partitions des groupes de serveurs de traitement. Chacun détenait une carte indiquant les membres et la répartition de ces partitions. Les échanges entre serveurs frontaux participaient à la construction de cette carte et nécessitaient des threads pour communiquer avec les autres membres.

L'arrivée de nouveaux membres alourdissait donc le travail des anciens. Leur découverte pouvait prendre jusqu'à une heure. L'opération d'installation était finie avant que toutes ses conséquences aient nécessairement rejoint chaque machine.

Une fois le plafond atteint, les cartes ne se construisaient plus correctement. Disposer de serveurs de traitement ne suffisait plus : le frontal ne savait pas leur acheminer utilement les demandes. Le service avait perdu son organisation avant d'avoir épuisé sa promesse de calcul.

AWS avait déjà organisé le traitement en cellules. Ce cloisonnement ne réglait pas la taille du réseau de coordination des frontaux. Une isolation se juge à la frontière précise qu'elle protège ; le mot « cellule » ne fait pas office de passeport pour toute l'architecture.

Le redémarrage aussi se paie en temps

Les équipes ont retiré les serveurs ajoutés. Elles ont préféré tester davantage avant de relever la limite du système. Restait à relancer les frontaux.

C'est là que la flotte a présenté sa deuxième facture, réglable en heures. Au démarrage, reconstruire les cartes consommait des ressources également nécessaires au traitement des demandes. Remettre trop de machines en service trop vite pouvait les rendre lentes, puis les faire déclarer défaillantes et retirer à nouveau. L'empressement menaçait de défaire la réparation.

AWS a changé le démarrage pour lire directement les métadonnées de référence plutôt que de s'appuyer sur les voisins. La flotte comptait plusieurs milliers de serveurs, mais seuls quelques centaines pouvaient être réintroduits chaque heure. Un premier groupe a repris du trafic à 10 h 07, heure normale du Pacifique ; Kinesis a retrouvé un fonctionnement normal à 22 h 23. Les erreurs diminuaient pendant cette remontée en charge.

Une capacité installée peut donc rester provisoirement indisponible parce que le système ne peut pas la réintégrer sans se gêner lui-même. Le prix d'une heure de service raconte mal cette attente. Il faut aussi connaître la vitesse à laquelle les heures de service redeviennent disponibles.

Les dépendances ont leurs propres façons de tomber

Cognito utilisait Kinesis pour analyser les habitudes d'accès à ses interfaces. La transmission était conçue pour fonctionner au mieux, avec une mise en mémoire tampon locale. Une interruption prolongée a révélé un défaut latent : les données accumulées ont fini par bloquer les serveurs web. Certains utilisateurs ne pouvaient plus s'authentifier ou obtenir des identifiants temporaires.

Un flux d'observation s'était invité dans le parcours qui autorise l'action. Le tampon avait acheté du temps ; son comportement une fois saturé décidait de la suite.

CloudWatch a rencontré des difficultés pour traiter métriques et journaux, et certaines alarmes manquaient de données. L'ajustement automatique de capacité fondé sur ces métriques prenait du retard. Chez Lambda, l'accumulation des métriques a provoqué une contention mémoire sur les hôtes d'exécution. Même panne amont, dépenses de ressources différentes en aval.

Le système habituel de publication de l'état des services dépendait lui-même de Cognito. Un outil de secours fonctionnait, mais ses opérations plus manuelles et moins familières ont retardé les publications. Les clients attendaient aussi des explications, pas seulement des réponses aux requêtes.

Ce que les grandes machines achetaient réellement

Réduire le nombre de frontaux en utilisant des machines plus puissantes diminuait le nombre de correspondants que chacun devait suivre. AWS annonçait également une surveillance plus fine des threads, des essais sur la limite, une séparation du cache, des frontaux partitionnés pour certains grands services et une accélération du découpage en cellules.

Ces mesures visaient plusieurs objets distincts : de la marge, une alerte, un démarrage plus facile et une propagation plus courte des problèmes. Les additionner sous une seule étiquette de « capacité » ferait disparaître leur intérêt.

La présentation de la stabilité statique d'AWS pose une question simple : le travail peut-il continuer quand une dépendance est dégradée ? Son texte sur la tolérance aux pannes et leur isolation rappelle aussi que des ressources préparées à l'avance ont un coût. La capacité de secours occupe du capital ; la capacité qu'on espère créer pendant l'incident occupe l'agenda des clients.

Le rapport historique ne livre ni les limites actuelles des frontaux ni un essai récent de redémarrage complet. Un tel essai, assorti de ses conditions, permettrait de juger l'état présent. L'affaire de 2020 livre déjà une bonne question d'achat : combien de temps faut-il au système pour redevenir assez organisé pour nous servir ?