• Cloudflare R2 a renvoyé un nombre accru d’erreurs 503 dans l’est de l’Amérique du Nord entre 21 h 10 UTC le 4 septembre et le début du 5 septembre
  • Les applications qui dépendent de R2 peuvent afficher des erreurs de stockage aux utilisateurs, même lorsque l’incident se limite à un seul produit et à une seule région

Les faits

Cloudflare a indiqué qu’un incident touchant le stockage d’objets R2 dans l’est de l’Amérique du Nord avait été résolu à 00 h 42 UTC le 5 septembre. L’incident avait commencé à 21 h 10 UTC le 4 septembre, lorsque les clients de la région ont rencontré un nombre accru d’erreurs HTTP 503. L’historique de la page d’état de Cloudflare indique que les ingénieurs ont identifié la cause, appliqué un correctif et surveillé le service avant de clore l’incident.

L’incident a été signalé pour R2 dans l’est de l’Amérique du Nord, et non comme une panne mondiale de Cloudflare. R2 est le service de stockage d’objets de Cloudflare, utilisé pour conserver des fichiers, des ressources et d’autres données applicatives. Une application qui dépend d’objets stockés par l’intermédiaire du service touché peut donc renvoyer des erreurs aux utilisateurs lorsque l’accès à ce stockage est perturbé.

L’analyse

L’incident était suffisamment circonscrit pour être décrit par produit et par région, mais les applications utilisant ce service R2 pouvaient malgré tout échouer lorsqu’elles tentaient de récupérer des données stockées. Pour une équipe applicative, la localisation de la défaillance est donc importante: une erreur 503 de R2 indique qu’une requête de stockage n’a pas pu aboutir, et non que l’ensemble de la plateforme Cloudflare était indisponible.

La prochaine étape du diagnostic dépend de la connaissance des parties d’une application qui s’appuient sur R2 dans la région touchée. Un service qui a besoin de ces objets pour une fonction critique peut être immédiatement affecté par l’incident, tandis qu’un autre peut continuer à fonctionner avec seulement une partie de son contenu indisponible.

Les informations fournies n’établissent ni interruption de service chez les clients ni perte de données; l’impact ne doit donc pas être extrapolé au-delà de la hausse des erreurs signalée par Cloudflare. Pour les lecteurs de BTW, la décision en matière de résilience doit donc être prise au niveau de chaque charge de travail. Les équipes doivent savoir quelles fonctions applicatives dépendent du service de stockage avant de déterminer le niveau de protection nécessaire pour cette dépendance.

À surveiller

Il faudra surveiller toute explication publiée par Cloudflare après l’incident, ainsi que tout nouvel incident R2 dans l’est de l’Amérique du Nord. Davantage de détails sur la cause et le rétablissement permettraient de préciser le périmètre de la défaillance et de déterminer si le même schéma régional se répète. Des signalements de clients faisant état de problèmes d’accès ayant persisté après l’heure de résolution annoncée par Cloudflare aideraient également à établir si le rétablissement s’est prolongé au-delà de la mise à jour publiée sur la page d’état du fournisseur.