Em 1º de março, uma zona de disponibilidade na região me-central-1 da AWS, mec1-az2, foi atingida pelo que a AWS descreveu como "objects that struck the data center, creating sparks and fire". Cerca de dezoito horas depois, uma segunda zona, mec1-az3, também perdeu energia. A terceira, mec1-az1, ficou de pé o tempo todo. Com duas de três zonas comprometidas, S3 e DynamoDB começaram a falhar em toda a região, e o conselho da AWS aos clientes, em suas próprias palavras no Health Dashboard, foi "enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe". A independência das zonas de disponibilidade é projetada contra falhas de energia, falhas de refrigeração e falhas de rede. Em março ela encontrou uma causa contra a qual nunca foi projetada, e a causa não se importou com a engenharia.

Esta é a Parte 2 de Nothing Fails Alone. A Parte 1 examinou o incidente de maio em us-east-1 e argumentou que a fronteira de zona aguentou, e aguentou mesmo: uma falha de refrigeração em um data hall ficou dentro de uma zona, exatamente como projetado, e a queda que se seguiu foi construída pelo cliente. Aquele argumento estava correto, e respondia a uma pergunta específica: o isolamento de AZ contém os modos de falha contra os quais é projetado? O evento de março em me-central-1 faz uma pergunta diferente. Ele aconteceu antes de a Parte 1 ser escrita, e na época era fácil arquivar como um caso especial de guerra, uma nota de rodapé de ato de guerra sem lições para a arquitetura normal. O incidente de maio é o que tornou o formato geral visível: a Parte 1 tratava do que a fronteira de zona protege, e esta parte trata do que ela não pode proteger, que é qualquer causa que alcance mais de uma zona. Essas causas existem em tempos de paz também. A guerra apenas comprimiu a demonstração em dois dias.

O que de fato aconteceu em me-central-1

O evento abriu no AWS Health Dashboard às 04:51 PST de 1º de março como uma investigação sobre "issues with AWS services in the ME-CENTRAL-1 Region", rapidamente reduzida a um "localized power issue" em uma única zona de disponibilidade, mec1-az2. O log do dashboard é incomumente franco, e às 09:41 PST ele explicou por que a energia caiu: "At around 4:30 AM PST, one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center, creating sparks and fire. The fire department shut off power to the facility and generators as they worked to put out the fire." No dia seguinte a AWS nomeou a causa, em uma atualização que The Register cobriu no mesmo dia: ataques de drone, parte do conflito no Oriente Médio. "In the UAE, two of our facilities were directly struck", e os ataques "caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage".

Ao longo do primeiro dia, o incidente parecia um evento de zona única de manual, e a AWS disse isso na mesma atualização das 09:41: "Customers who were running their applications redundantly across the AZs are not impacted by this event." Multi-AZ era, naquela hora, a resposta correta e suficiente, e uma atualização menos de uma hora antes carregava uma ressalva que você já leu se leu a Parte 1: devido à demanda aumentada nas zonas não afetadas, "customers may experience longer than usual provisioning times". A mesma frase que a AWS publicaria durante o evento de maio em us-east-1, o incidente que a Parte 1 cobriu duas semanas atrás, mesmo que no calendário março tenha vindo primeiro. O failover em massa para as zonas sobreviventes é uma manada em disparada em todo lugar, em toda região, em todo incidente.

Então, às 22:46 PST, cerca de dezoito horas após o primeiro ataque: "a localized power issue has affected another Availability Zone in the ME-CENTRAL-1 Region (mec1-az3) ... At this point it is not possible to launch new instances in the region ... Other AWS Services, such as DynamoDB and S3 are also experiencing significant error rates and latencies." Duas de três zonas fora do ar, e a falha havia escalado para fora da camada de zona por completo.

Dezoito horas não é simultâneo, e esse é o ponto

As duas zonas não caíram juntas. Caíram com cerca de dezoito horas de diferença, pela mesma causa. Essa distinção é todo o argumento deste post, então vale ser preciso a respeito. A independência de zona é uma afirmação de probabilidade: a AWS projeta zonas sobre energia separada, refrigeração separada, planícies de inundação separadas e caminhos de rede separados, para que as falhas internas de uma instalação, um chiller que falha, um transformador que falha, um switch fabric ruim, fiquem dentro dela e não coincidam com as falhas internas de outra. Nos próprios termos dessa afirmação, março não mudou nada. Nenhuma zona derrubou a outra. Não houve transformador compartilhado, nem dependência em cascata. A engenharia de isolamento funcionou até o fim.

O que falhou foi a premissa por baixo da matemática de probabilidade: a de que falhas de zona são eventos independentes. Elas são independentes apenas quando a causa se origina dentro de uma instalação. Uma causa que se origina fora das instalações, uma tempestade, um colapso da rede elétrica, um incêndio florestal, um conflito armado, é amostrada uma vez e aplicada a todas as zonas ao seu alcance. As zonas compartilhavam uma área metropolitana, uma rede elétrica, um espaço aéreo e uma guerra. Falha correlacionada não significa duas zonas morrendo no mesmo instante; significa uma causa alcançando ambas no seu próprio ritmo. O intervalo de dezoito horas é a cara que a correlação de fato tem em um dashboard: não um crash sincronizado, mas a mesma mão batendo duas vezes.

É por isso que o enquadramento de caso-especial-de-guerra falha. Drones são exóticos; infraestrutura metropolitana compartilhada não é. Toda região multi-AZ concentra suas zonas dentro de milissegundos de um dígito umas das outras, o que na prática significa o mesmo raio de explosão em escala de cidade para clima, serviços públicos e política. O evento de março é a ponta extrema de uma família de causas que inclui todo evento grande o suficiente para ser batizado com o nome da cidade onde aconteceu. Quando a InfoQ analisou o incidente mais tarde naquele mês sob o título "War in Iran Damages Multiple AWS Data Centers, Challenging Multi-AZ Assumptions", a discussão da comunidade que ela resumia já havia passado dos drones para o caso geral: zonas são um aglomerado de prédios na mesma cidade, e as premissas que valem a pena questionar são sobre tudo o que pode alcançar uma cidade.

Quando a própria região é o domínio de falha

A atualização mais instrutiva de todo o log veio às 02:53 PST de 2 de março, quando a AWS explicou o que duas zonas perdidas fazem com o S3: "Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone ... As the second AZ became impaired, S3 error rates increased. With two Availability Zones significantly impacted, customers are seeing high failure rates for data ingest and egress."

Leia essa frase como um documento de arquitetura, porque é isso que ela é. S3 e DynamoDB são os serviços para os quais você não arquiteta contra falha de zona, porque a AWS faz isso por você, replicando entre zonas para que a perda de uma zona seja invisível. Esse design tem uma tolerância declarada: uma zona. A segunda zona a excedeu, e os serviços em que toda arquitetura "resiliente" na região se apoiava, para estado, para backups, para os dados de coordenação do próprio failover, começaram a recusar leituras e escritas em toda a região. Sua aplicação multi-AZ não perdeu apenas suas instâncias; perdeu o substrato regional sobre o qual planejava se recuperar. mec1-az1 estava saudável, e não importou, porque uma zona saudável ligada a um control plane regional comprometido é um cômodo com as luzes acesas em um prédio sem encanamento. Esta é a parte que o multi-AZ não pode responder. Os serviços regionais são construídos sobre as mesmas três zonas que você usa, e a tolerância deles a perda de zona correlacionada é um número que a AWS escolheu, não um número que você escolheu.

"Ideally in Europe"

Às 06:22 PST de 2 de março, a orientação da AWS havia chegado à sua frase mais direta: "We recommend customers enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe."

Essa frase merece uma leitura mais lenta do que teve em março. Primeiro, o provedor dono da região disse aos clientes para saírem dela. Esse é o teto da redundância dentro da região, declarado pelo fornecedor: existe uma classe de evento para a qual a quantidade correta de me-central-1 no seu plano de recuperação é nenhuma, e você descobre em qual classe está no meio do incidente, por um dashboard. Segundo, "ideally in Europe" está fazendo um trabalho silencioso e cuidadoso. A alternativa mais próxima, me-south-1 no Bahrein, fica a um pulo de distância e seria a escolha reflexa de DR por questões de latência, e uma instalação lá havia sido afetada por um ataque próximo na mesma campanha. A AWS estava dizendo aos clientes, sem soletrar, que a causa correlacionada tinha uma geografia, e que uma região de recuperação útil é uma fora dessa geografia, não meramente fora do ARN da região. Distância do seu primário não é um checkbox de compliance; é uma aposta sobre o quão longe suas causas correlacionadas viajam. Escolha sua região de DR perguntando o que poderia plausivelmente atingir ambas, não o que mantém a latência de replicação bonita.

Terceiro, o conselho só funciona para clientes que puderam segui-lo. "Recover from remote backups" pressupõe que os backups remotos existam, criados antes de 1º de março, porque o mesmo log de atualizações mostra "data ingest and egress" do S3 falhando em toda a região durante o evento. Copiar seus dados para fora de uma região é uma atividade de tempo de paz. Quando o provedor já está aconselhando isso, a janela para começar já se fechou.

Vários meses

A última atualização do evento, datada de 30 de abril, tem um parágrafo de comprimento e encerra a história sem encerrá-la: a região "has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications", os clientes deveriam "migrate all accessible resources to other Regions and restore inaccessible resources from remote backups as soon as possible", as operações de cobrança estão suspensas, e a recuperação "is expected to take several months".

Coloque isso contra um documento de DR padrão. Um RTO é escrito como uma duração, e quase todo RTO que revisei silenciosamente assume que o alvo de recuperação é o lugar onde você já está: restaure o snapshot, relance a frota, mesma região, horas no pior caso. "Several months" não estressa esse número, ele apaga o eixo em que foi escrito. Se a região não vai voltar neste trimestre, seu tempo de recuperação real é o quanto durar uma reconstrução cross-region a frio, incluindo as partes que ninguém ensaiou: IAM e rede recriados a partir de código que você espera ter, dados restaurados de réplicas que você espera ter feito, DNS redirecionado, capacidade encontrada em uma região de destino absorvendo o êxodo de todo mundo de uma vez. Para times com replicação cross-region já fluindo, março foi uma semana ruim. Para times cujo plano de DR era snapshots dentro da região, foi um projeto de migração anunciado por artilharia.

O lab: em quais zonas físicas você está de fato?

A Parte 1 encerrou sua seção de lab notando que os relatórios de incidente da AWS nomeiam zonas por ID, use1-az4, e que sem o mapeamento de ID para nome você não consegue dizer se aquela era a sua us-east-1a. Março é o incidente em que isso deixa de ser trivialidade. O dashboard disse mec1-az2, depois mec1-az3. Para saber se suas cargas de trabalho estavam nas zonas atingidas ou na sobrevivente, você tinha que resolver esses IDs contra a sua conta, no meio do incidente, porque um nome de zona como me-central-1a é um alias com escopo de conta: a AWS atribui letras a zonas físicas de forma independente por conta, então a me-central-1a de duas contas costuma ser zonas físicas diferentes. "Estamos espalhados por a, b e c" é uma afirmação sobre a nomenclatura da sua conta, não sobre a colocação física.

O lab desta parte, 02-az-id-truth, é deliberadamente o menor da série: um único script somente leitura cujas únicas chamadas de API são DescribeAvailabilityZones e GetCallerIdentity, esta última apenas para rotular a saída. Ele imprime o mapeamento de nome para ID da conta e região atuais. Esta é a saída real para uma das minhas contas:

$ python3 az_ids.py --region us-east-1
Region: us-east-1

ZONE NAME  | ZONE ID  | STATE
---------------------------------
us-east-1a | use1-az1 | available
us-east-1b | use1-az2 | available
us-east-1c | use1-az4 | available
us-east-1d | use1-az6 | available
us-east-1e | use1-az3 | available
us-east-1f | use1-az5 | available
...

Nesta conta, use1-az4, a zona no relatório de incidente de maio, é us-east-1c. Um engenheiro aqui que tivesse lido "use1-az4" em maio e olhado de relance para um diagrama rotulado "us-east-1a" teria relaxado quanto à zona errada e se preocupado com uma saudável. O script também aceita --compare <profile>, que lê o mapeamento de uma segunda conta na mesma região e imprime os dois lado a lado com um veredito por nome sobre se eles resolvem para a mesma zona física, e então conta as divergências; o mesmo nome resolvendo para IDs diferentes entre contas é o caso normal, não a exceção. Um runbook compartilhado que diz "evacuate us-east-1a" faz coisas diferentes em contas diferentes. Runbooks, decisões de colocação e consultas de incidente pertencem aos IDs de zona. Há um flag --json para alimentar o mapeamento em ferramentas de inventário, e o código de saída é 0 sempre que a execução conclui, reservando o 2 para execuções que não podem acontecer de jeito nenhum: sem boto3, sem credenciais, sem região, um profile desconhecido, ou a própria chamada describe falhando.

Modos de falha e o que observar

Seja honesto sobre os limites primeiro: um cliente não consegue arquitetar me-central-1 para fora de uma guerra. Nada no seu Terraform impede a causa correlacionada; o que você controla é se ela te encontra com seus dados já em outro lugar. A lista de observação que decorre de março é curta. Enumere as causas que alcançam todas as suas zonas de uma vez: a metrópole compartilhada, a rede elétrica compartilhada, o clima compartilhado, a jurisdição compartilhada, e trate a resposta como sua probabilidade real de perda de região, que é baixa mas não o zero que a matemática de zona silenciosamente assumia. Mantenha backups cross-region para qualquer coisa que você não consiga regenerar, em uma região escolhida por estar fora da geografia correlacionada, e teste o restore, porque a versão de março desse teste tinha um corpo de bombeiros dentro dela. Escreva RTOs duas vezes, uma para recuperação dentro da região e outra assumindo que a região se foi por um trimestre, e coloque o segundo número diante de quem é dono do risco. E mantenha um inventário dos seus IDs de zona física por conta, porque quando o próximo relatório citar um ID de zona, a hora de aprender seu mapeamento não é durante o evento. A fronteira de zona é real, e a Parte 1 a mostrou aguentando. Março mostrou a coisa acima dela: zonas podem estar perfeitamente isoladas umas das outras e ainda assim não estar isoladas do mundo.

Leia isto a seguir

Para consultoria em AWS, arquitetura de nuvem, revisões de resiliência e trabalho de plataforma, comece em ercanermis.com.

Referências