Résumé

  • Les incidents des 8 et 9 octobre sur Cloud Storage ont duré 18 heures et 11 minutes au total, dans us-central1 puis us-central1-b ; les symptômes publiés concernaient surtout les écritures.
  • Google attribue le premier épisode à une optimisation de routage qui a contourné la prise en compte des capacités, et la récurrence à un retour arrière incomplet ; aucun client ni préjudice chiffré n’est nommé.

Une panne de stockage cloud est souvent ramenée à l’emplacement des copies. Le rapport de Google invite à poser une autre question : par quel chemin une requête d’écriture passe-t-elle avant de devenir un objet stocké ? Le 8 octobre, les clients de Cloud Storage utilisant us-central1 ont connu une hausse de latence et d’erreurs d’écriture pendant 12 h 30. Le problème est revenu le lendemain dans la zone us-central1-b pendant 5 h 41. Google annonce 18 h 11 de durée cumulée, mais il s’agit de deux épisodes séparés par une reprise, et non d’une panne continue de dix-huit heures.

Les symptômes publics sont précis. Google rapporte principalement des réponses HTTP 503 UNAVAILABLE sur les opérations WriteObject et des expirations côté client ; les écritures qui aboutissaient prenaient davantage de temps. Le rapport final indique que les autres régions Cloud Storage et les autres services Google Cloud n’ont pas été touchés par cet événement précis. Une section préliminaire évoquait des effets mineurs sur les lectures, mais le résumé final des impacts ne les chiffre pas. Le dossier étaye donc un problème circonscrit au chemin d’écriture d’une région, puis d’une zone lors de la récurrence.

Il ne montre pas que tous les clients étaient concernés, que toutes les écritures échouaient ni que des objets stockés ont été perdus.

Google situe le premier déclencheur dans la mise à jour d’une configuration de tri du trafic, conçue pour répondre à des contraintes locales de capacité. L’optimisation a contourné la logique habituelle de routage tenant compte de la capacité. Une petite fraction des nœuds dorsaux, disposant de peu de capacité de traitement, a alors reçu une part disproportionnée du trafic d’écriture. Ces nœuds ont épuisé leurs ressources ; les services d’ingestion d’objets ont commencé à expirer ; les requêtes qui leur étaient adressées sont devenues lentes ou ont échoué.

Un incident distinct de base de données a aussi provoqué des erreurs de traitement des métadonnées durant une partie de la première période. La causalité est donc stratifiée : une décision de répartition a modifié la distribution des requêtes, concentré la charge et coïncidé avec une défaillance secondaire des métadonnées.

La récurrence du lendemain est l’élément opérationnel le plus instructif. Google l’attribue au retour arrière incomplet d’une fonction de planification des téléversements, qui a perturbé l’équilibrage de charge et surchargé de plus petits nœuds. La première mesure de rétablissement n’avait pas rétabli entièrement l’état de sûreté antérieur. Cela ne prouve ni que tout retour arrière est peu fiable ni qu’une panne régionale plus vaste a eu lieu.

Cela montre pourquoi la clôture d’un incident et l’état réel de la configuration sont deux choses différentes : un service peut sembler revenu à la normale alors qu’un changement résiduel laisse le même chemin de panne ouvert.

Le récit du rétablissement comporte aussi une limite utile aux exploitants. Google a d’abord essayé d’ajouter de la capacité d’urgence, mais indique que les limites de capacité régionales l’en ont empêché. Les ingénieurs ont alors retiré du trafic aux nœuds saturés, désactivé ou annulé l’optimisation, annulé une mise à jour distincte de la base de données et redirigé le trafic. Après stabilisation de la charge et de l’utilisation, les nœuds retirés ont été remis en service.

La capacité supplémentaire n’est pas toujours une issue d’urgence ; le routage, l’isolement du trafic et l’exactitude du retour arrière peuvent rester les contrôles disponibles lorsqu’une région ne peut pas simplement grandir à la demande.

La documentation de Cloud Storage permet de situer l’événement sans aller au-delà des faits. Google indique qu’un bucket régional stocke des données de façon redondante dans au moins deux zones de la région choisie. Les buckets bi-régionaux et multirégionaux répliquent entre régions de manière asynchrone après le stockage initial de l’écriture dans une région et deux zones. Google décrit un service automatique depuis une autre région en cas de panne régionale pour ces configurations plus larges, tout en précisant que la réplication est asynchrone.

Sa documentation de cohérence affirme qu’une écriture d’objet réussie devient immédiatement lisible. Elle ne précise toutefois pas les emplacements de buckets utilisés par les clients touchés.

Cette distinction compte. Le rapport ne dit pas que la réplication multirégionale a échoué, que des données ont été perdues ou que des copies géographiques sont devenues indisponibles. Il décrit plutôt un goulot d’étranglement sur le chemin d’acceptation des nouvelles écritures. La redondance géographique peut limiter l’exposition à une panne localisée, mais l’architecture doit aussi tenir compte des contrôles logiciels et de capacité partagés par le service d’écriture.

La résilience du stockage ne se résume pas à une propriété : la durabilité des copies, l’ingestion réussie, le traitement des métadonnées, l’accès en lecture et le rétablissement applicatif ont des dépendances distinctes.

Les mesures préventives annoncées par Google suivent cette chaîne. L’entreprise dit qu’elle testera les changements de répartition dans de petites régions avant de les déployer dans des régions plus grandes et plus sollicitées ; que le routage appliquera strictement les contraintes de capacité ; et qu’elle améliorera le déplacement interne des données dans les cellules très utilisées. Ce sont des actions futures rapportées par Google, pas des contrôles dont l’achèvement a été vérifié indépendamment.

Le dossier public ne donne ni résultats de tests, ni volumes de requêtes touchées, ni clients identifiés, ni répartition des types de buckets, ni pertes mesurées. La conclusion utile est plus étroite : une optimisation de routage et un retour arrière incomplet ont pu neutraliser deux fois une protection locale de capacité, tandis que la question de la redondance géographique restait distincte.

Sources : rapport final de Google, disponibilité et durabilité de Cloud Storage, emplacements des buckets, cohérence, stratégie de nouvelle tentative.