Heroku ejecutaba a todos sus clientes en una sola región de AWS — y luego EBS falló durante 80 horas

El 21 de abril de 2011 a las 8:15 UTC, las alertas de monitoreo se dispararon en Heroku: los tiempos de espera estaban afectando sus servicios web, de caché y de enrutamiento. El desencadenante fue externo: a las 12:47 a. m. PDT, un cambio de red en AWS dentro de una sola zona de disponibilidad de US-East trasladó el tráfico primario de EBS a una red de replicación de menor capacidad, aisló los nodos de EBS y desató una tormenta de re-espejado que dejó atascado el 13 % de los volúmenes de la zona, según el propio relato de AWS.

EC2 se recuperó en unas 12 horas, pero EBS permaneció degradado durante más de 80. Heroku —que ejecutaba toda su plataforma en US-East, con sus bases de datos en EBS— no tenía a dónde conmutar por error: no había una segunda región. La mayoría de las aplicaciones volvieron en un plazo de 16 horas; las aplicaciones gratuitas en servidores de bases de datos compartidos tardaron hasta tres días.

El análisis posterior de Heroku rechazó la excusa obvia: «Heroku asume el 100 % de la responsabilidad por la caída que afectó a nuestros clientes». Las tres lecciones que extrajo: las zonas de disponibilidad dentro de una región no particionan el riesgo como el equipo había supuesto; el almacenamiento en bloque no es una tecnología adecuada para la nube; y una plataforma que promete abstraer la infraestructura asume las consecuencias cuando esa infraestructura falla.

La mayoría de las aplicaciones volvieron en un plazo de 16 horas; las aplicaciones gratuitas en bases de datos compartidas permanecieron caídas hasta 3 días; EBS de US-East estuvo degradado durante más de 80 horas

Toda la plataforma vivía en una sola región de AWS, y sus zonas de disponibilidad resultaron compartir modos de fallo que Heroku había supuesto que estaban particionados.

Los servicios con estado residían en EBS, que siguió averiado mucho después de que EC2 se recuperara: una dependencia que Heroku no podía sortear ni reemplazar en medio del incidente.

El manual estándar —matar las instancias no saludables, reemplazarlas, esperar a AWS— suponía que las caídas duran una o dos horas. Esta duró días.

La arquitectura multirregión se había despriorizado durante años por considerarse un proyecto grande con poco beneficio en disponibilidad. La caída de abril le reajustó el precio en un solo fin de semana.

Las zonas de disponibilidad dentro de una región de nube no son redundancia. Si todos los clientes se ejecutan en la misma región sobre el mismo almacenamiento en bloque, un solo error de red externo se convierte en la caída de todos.

Heroku dijo que trataría la multirregión como una prioridad mucho mayor y reduciría su dependencia de EBS, y comenzó cambios arquitectónicos destinados a permitir que la plataforma sobreviviera a fallos a nivel de IaaS. El resumen de AWS del evento se convirtió en uno de los análisis de fallos más leídos de la industria, y «no pongas todo en una sola región» se volvió un consejo estándar para la nube. No obstante, Heroku mantuvo una postura marcadamente de región única durante años después, y la concentración que identificó siguió reapareciendo en incidentes posteriores.