A Heroku executava todos os clientes em uma única região da AWS — e então o EBS quebrou por 80 horas

Em 21 de abril de 2011, às 8h15 UTC, alertas de monitoramento dispararam em toda a Heroku: timeouts atingiam seus serviços web, de cache e de roteamento. O gatilho foi a montante — às 12h47 PDT, uma alteração de rede da AWS em uma única zona de disponibilidade do US-East deslocou o tráfego primário do EBS para uma rede de replicação de menor capacidade, isolando nós do EBS e desencadeando uma tempestade de re-espelhamento que deixou 13% dos volumes da zona travados, segundo o próprio relato da AWS.

O EC2 em si se recuperou em cerca de 12 horas, mas o EBS permaneceu degradado por mais de 80. A Heroku — que executava toda a sua plataforma no US-East, com seus bancos de dados no EBS — não tinha para onde fazer failover: não havia uma segunda região. A maioria dos aplicativos voltou em até 16 horas; aplicativos gratuitos em servidores de banco de dados compartilhados levaram até três dias.

O post-mortem da Heroku recusou a desculpa óbvia: "A Heroku assume 100% da responsabilidade pela indisponibilidade que afetou nossos clientes." As três lições que tirou: zonas de disponibilidade em uma região não particionam o risco da forma como a equipe havia presumido; armazenamento em bloco não é uma tecnologia amigável à nuvem; e uma plataforma que promete abstrair a infraestrutura assume as consequências quando essa infraestrutura falha.

A maioria dos aplicativos voltou em até 16 horas; aplicativos gratuitos em bancos de dados compartilhados ficaram fora do ar por até 3 dias; o EBS do US-East ficou degradado por mais de 80 horas

Toda a plataforma vivia em uma única região da AWS, e suas zonas de disponibilidade acabaram compartilhando modos de falha que a Heroku presumira estarem particionados.

Serviços com estado ficavam no EBS, que permaneceu quebrado muito depois de o EC2 se recuperar — uma dependência que a Heroku não pôde contornar nem substituir no meio do incidente.

O manual padrão — matar instâncias não saudáveis, substituí-las, esperar pela AWS — pressupunha indisponibilidades de uma ou duas horas. Esta durou dias.

A multi-região havia sido despriorizada por anos como um grande projeto com pouco ganho de disponibilidade. A indisponibilidade de abril reajustou seu valor em um fim de semana.

Zonas de disponibilidade em uma única região de nuvem não são redundância. Se todos os clientes rodam na mesma região e no mesmo armazenamento em bloco, um erro de rede a montante se torna a indisponibilidade de todos.

A Heroku disse que trataria a multi-região como prioridade muito mais alta e reduziria sua dependência do EBS, e começou mudanças arquiteturais destinadas a permitir que a plataforma sobrevivesse a falhas no nível de IaaS. O resumo da AWS sobre o evento tornou-se uma das análises de falha mais lidas do setor, e "não coloque tudo em uma única região" virou conselho padrão de nuvem. A Heroku, no entanto, manteve uma postura fortemente de região única por anos depois disso, e a concentração que identificou continuou ressurgindo em incidentes posteriores.