AWS S3 2017: um comando digitado errado

01 · CONTEXTO

Um armazenamento que o resto da AWS usa

Na manhã de 28 de fevereiro de 2017, o Amazon S3 da região US-EAST-1, na Virgínia do Norte, ficou sem atender requisições por horas. O resumo oficial da AWS é a fonte deste caso. A equipe investigava por que o sistema de cobrança do S3 andava mais devagar do que o esperado, e foi nesse trabalho de rotina que o incidente começou.

Dois subsistemas importam aqui. O índice guarda os metadados e a localização de todos os objetos da região, e é necessário para atender leituras, listagens, gravações e remoções. O subsistema de alocação decide onde guardar objetos novos, é usado nas gravações e só funciona direito com o índice funcionando.

1. Clientes enviam leituras, listagens, gravações e remoções à API de objetos.

2. Leituras, listagens e remoções consultam o índice, que sabe onde cada objeto está.

3. Uma gravação passa pela alocação, que escolhe onde guardar o objeto novo.

4. A alocação precisa do índice em funcionamento. Se o índice cai, as gravações caem junto.

02 · O COMANDO

Uma entrada errada num procedimento conhecido

Às 9:37 da manhã, horário do Pacífico, um membro autorizado da equipe seguiu um procedimento estabelecido e executou um comando para retirar poucos servidores de um subsistema usado pela cobrança. Uma das entradas do comando foi digitada errada, e um conjunto maior de servidores do que o pretendido foi removido.

1. O comando deveria retirar uma pequena quantidade de servidores do subsistema usado pela cobrança.

2. Com a entrada errada, o comando também retirou servidores que sustentavam o índice e a alocação.

3. Sem uma parte significativa da capacidade, cada um dos dois subsistemas precisou de reinício completo, e o serviço não conseguiu atender requisições enquanto isso.

4. Como a alocação depende do índice, a recuperação teve uma ordem: primeiro o índice, depois a alocação.

O sistema era feito justamente para isso: os subsistemas do S3 foram projetados para suportar a remoção ou a falha de capacidade significativa com pouco ou nenhum impacto aos clientes. O que falhou não foi a ideia de tirar capacidade, e sim o limite do quanto se podia tirar de uma vez.

03 · CASCATA

Quem dependia do armazenamento caiu junto

Outros serviços da AWS na região que dependem do S3 para armazenamento também foram afetados enquanto as APIs estavam fora: o console do S3, o lançamento de novas instâncias do EC2, volumes do EBS quando os dados vinham de um snapshot guardado no S3, e o AWS Lambda.

1. As APIs do armazenamento de objetos ficaram indisponíveis.

2. O console, o lançamento de instâncias, os volumes restaurados de snapshots e as funções sem servidor dependiam dele e foram afetados.

3. O console de administração do painel de status também dependia do armazenamento. Por isso o estado de cada serviço não podia ser atualizado no painel.

Até as 11:37 da manhã, a AWS não conseguiu atualizar o status individual dos serviços no painel de status, por causa de uma dependência do console de administração do painel no S3. Nesse intervalo, o aviso aos clientes foi feito pelo Twitter da AWS e por um texto de banner. Depois do evento, o console de administração do painel passou a rodar em várias regiões.

04 · RECUPERAÇÃO

Um reinício que não era feito havia anos

Remover e repor capacidade é uma prática central de operação do S3 desde o lançamento. Já o reinício completo do índice e da alocação, nas regiões maiores, não acontecia havia muitos anos. Com o crescimento enorme do serviço, reiniciar e rodar as verificações de segurança que validam a integridade dos metadados levou mais tempo do que a AWS esperava.

Mesmo com o armazenamento de volta, alguns serviços que dependiam dele tinham acumulado uma fila de trabalho durante a interrupção e precisaram de tempo extra para se recuperar por completo.

05 · CORREÇÕES E LIÇÕES

Salvaguardas na ferramenta e células menores

A própria AWS apontou que a ferramenta permitia remover capacidade demais e rápido demais. Ela foi alterada para remover capacidade mais devagar e para barrar a remoção quando isso levaria qualquer subsistema abaixo do nível mínimo de capacidade exigido. As demais ferramentas operacionais também passaram por auditoria em busca de salvaguardas semelhantes.

Uma das técnicas mais importantes da AWS para recuperar serviços é dividi-los em partições pequenas, chamadas de células, o que permite avaliar e testar a recuperação até do maior serviço e reduz o raio de explosão. Mesmo assim, o índice demorou mais do que o esperado para voltar. O particionamento adicional dele, que já estava planejado, foi repriorizado para começar imediatamente.

1. Em vez de um bloco único, o serviço é fatiado em células independentes, e um roteador leva cada requisição à célula responsável.

2. Se uma célula precisa de reinício completo, as outras seguem atendendo. O estrago fica limitado a uma fração do todo.

3. Cada célula é pequena o bastante para ter o reinício e a validação ensaiados e cronometrados com frequência.