• Cloudflare R2 devolvió un número elevado de errores 503 en el este de Norteamérica desde las 21:10 UTC del 4 de septiembre hasta primeras horas del 5 de septiembre
  • Las aplicaciones que dependen de R2 pueden mostrar errores de almacenamiento a los usuarios incluso cuando el incidente se limita a un solo producto y una sola región

El hecho

Cloudflare marcó como resuelto a las 00:42 UTC del 5 de septiembre un incidente del almacenamiento de objetos R2 en el este de Norteamérica. El incidente comenzó a las 21:10 UTC del 4 de septiembre, cuando los clientes de la región experimentaron un número elevado de errores HTTP 503. El historial de estado de Cloudflare indica que los ingenieros identificaron la causa, aplicaron una solución y supervisaron el servicio antes de cerrar el incidente.

El incidente se notificó para R2 en el este de Norteamérica, no como una interrupción global de Cloudflare. R2 es el servicio de almacenamiento de objetos de Cloudflare, utilizado para guardar archivos, recursos y otros datos de aplicaciones. Por tanto, una aplicación que dependa de objetos almacenados mediante el servicio afectado puede devolver errores a los usuarios cuando se interrumpe el acceso a ese almacenamiento.

La evaluación

El incidente fue lo bastante acotado como para describirse por producto y región, pero las aplicaciones que usaban ese servicio R2 aun así podían fallar cuando intentaban recuperar datos almacenados. Para el equipo responsable de una aplicación, eso hace que la ubicación del fallo sea importante: un error 503 de R2 señala una solicitud de almacenamiento que no pudo completarse y no constituye una prueba de que toda la plataforma de Cloudflare no estuviera disponible.

El siguiente paso del diagnóstico depende de saber qué partes de una aplicación dependen de R2 en la región afectada. Un servicio que necesite esos objetos para una función crítica puede notar sus efectos de inmediato, mientras que otro puede seguir funcionando aunque una parte de su contenido no esté disponible.

La información facilitada no acredita interrupciones a nivel de cliente ni pérdida de datos, por lo que el impacto no debe ampliarse más allá del elevado nivel de errores comunicado por Cloudflare. Para los lectores de BTW, la decisión sobre resiliencia debe tomarse, por tanto, a nivel de carga de trabajo. Los equipos deben saber qué funciones de la aplicación dependen del servicio de almacenamiento antes de decidir cuánta protección requiere esa dependencia.

Qué observar

Conviene vigilar cualquier explicación posterior al incidente que publique Cloudflare y nuevos incidentes de R2 en el este de Norteamérica. Más detalles sobre la causa y la recuperación aclararían el límite del fallo y si se está repitiendo el mismo patrón regional. Los informes de clientes que indiquen que los problemas de acceso continuaron después de la hora de resolución de Cloudflare también ayudarían a establecer si la recuperación se prolongó más allá de la actualización de estado del proveedor.