Netflix: engenharia do caos

01 · CONTEXTO

Da corrupção de banco de dados à nuvem

A jornada do Netflix para a nuvem começou depois de uma grande corrupção de banco de dados, que por três dias impediu o envio de DVDs aos membros. A lição foi abandonar pontos únicos de falha escalados verticalmente, como bancos relacionais no datacenter, e ir para sistemas distribuídos e escaláveis na horizontal.

A AWS foi escolhida como provedor, e a arquitetura deixou de ser um app monolítico para virar centenas de microsserviços. A migração só terminou no início de janeiro de 2016, depois de sete anos de esforço.

02 · POR QUE DERRUBAR

Quebrar de propósito para não quebrar por acaso

Se falhas de instância são certas, esperar que elas aconteçam por acidente deixa o time descobrir a fraqueza na pior hora. O Chaos Monkey faz o contrário: seleciona ao acaso instâncias que hospedam serviços de produção e as encerra, para que os engenheiros projetem serviços que suportem a perda de uma instância.

Ele só fica ativo em horário comercial, de modo que há gente à mão para responder se algo falhar. Isso importa porque a empresa altera código e configuração de runtime centenas de vezes por dia, então a fragilidade pode reaparecer a qualquer mudança. Foi um sucesso cultural: hoje, dentro da empresa, todos projetam seus serviços para tolerar falha de instância como rotina.

1. Os clientes chegam ao balanceador, que reparte as requisições entre as instâncias do serviço.

2. O agente de caos escolhe a instância B ao acaso e a encerra durante o expediente.

3. O balanceador deixa de enviar tráfego à instância B e as instâncias A e C absorvem a carga. O usuário não percebe, e é isso que o projeto deve garantir.

4. O monitoramento registra a perda e os engenheiros, presentes por ser horário comercial, podem agir se o serviço degradar.

Repare no que o diagrama pressupõe: a instância encerrada não guardava nada que não pudesse ser recriado, e o balanceador sabe parar de usá-la. Serviços sem estado local insubstituível e verificações de saúde são o que torna a morte de uma instância um evento banal. A fonte não detalha esses mecanismos, então isto é a leitura do autor sobre o que o Chaos Monkey exige.

03 · SIMIAN ARMY

De uma instância para o exército de falhas

O Chaos Monkey virou parte de um conjunto maior, o Simian Army, descrito como serviços (os Monkeys) na nuvem que geram vários tipos de falha. O repositório público cita Chaos Monkey, Janitor Monkey e Conformity Monkey entre os membros, e hoje está arquivado e somente leitura.

A escala da falha sobe por degraus. O Chaos Monkey encerra instâncias; o Chaos Gorilla desliga uma zona de disponibilidade inteira da AWS; e o Chaos Kong simula uma interrupção que afeta uma região inteira.

04 · DO INSTANCE-KILL À REGIÃO

Chaos Kong e a evacuação de região

O plano de controle do Netflix roda na AWS, replicado em três regiões geográficas: Virgínia do Norte, Oregon e Irlanda. Se uma interrupção se limita a uma região, é possível redirecionar os clientes dela para uma região saudável.

1. Em operação normal, o direcionamento global reparte os clientes entre as três regiões, todas lendo dados replicados.

2. No exercício, trata-se a região da Virgínia como perdida. A fonte esclarece que a região não é realmente desligada: age-se sob a suposição de que ela caiu.

3. O direcionamento global passa a mandar os clientes da região perdida para as outras duas.

4. Oregon e Irlanda recebem a carga extra. Isso só funciona se houver capacidade reservada: o Netflix declara manter capacidade para um deslocamento total de tráfego de uma região para outra.

5. Durante o exercício, a hipótese é que a métrica de estado estável, inícios de reprodução por segundo, sofra impacto mínimo.

O Chaos Kong roda como exercício programado, uma vez por mês, enquanto o Chaos Monkey roda continuamente nos dias úteis. Esse ritmo reflete o risco: o exercício regional é raro e planejado, a morte de instância é rotina.

Do ponto de vista de arquitetura, evacuar uma região exige que as outras regiões já tenham os dados e a capacidade para servir o usuário. Por isso o teste regional é ao mesmo tempo prova e pressão de projeto para arquitetura multirregião e para padrões de disponibilidade.

05 · PRINCÍPIOS E EXPERIMENTOS

Do vandalismo ao método científico

Com o tempo, o time percebeu que a prática era mais sutil que quebrar coisas em produção, e a nomeou engenharia do caos: a disciplina de experimentar num sistema distribuído para ganhar confiança em sua capacidade de suportar condições turbulentas em produção.

O primeiro passo é definir um estado estável: uma saída mensurável que indica comportamento normal. No Netflix, o principal indicador de saúde são os inícios de reprodução por segundo (SPS), que mede se os usuários conseguem achar e assistir conteúdo. A hipótese é sempre sobre uma métrica na fronteira do sistema, não sobre um detalhe interno.

1. Dois pequenos grupos de usuários entram no experimento: controle e experimental. A hipótese é que o estado estável será igual nos dois.

2. O gateway falha apenas as chamadas ao serviço de bookmark feitas em nome do grupo experimental. O restante dos usuários nunca vê a falha, o que limita o raio de impacto.

3. O serviço de reprodução usa um fallback: sem o bookmark, o vídeo começa do início em vez de retomar de onde o usuário parou. Degrada, mas não quebra.

4. Compara-se a métrica de estado estável dos dois grupos. Se não houver diferença relevante, a hipótese não foi refutada e a confiança aumenta; se houver, achou-se uma fraqueza.

Os princípios completam o método: variar eventos do mundo real, experimentar em produção e automatizar para rodar continuamente. Em produção porque o sistema se comporta diferente por ambiente e tráfego, e porque no Netflix não dá para reproduzir toda a arquitetura num teste de ponta a ponta. Automatizar porque a confiança em resultados antigos cai à medida que o sistema muda.

Há também um custo de realismo: quem desenha o experimento precisa equilibrar o realismo do evento e o risco de dano, e por isso o Netflix simula a perda da região em vez de desligá-la. Já o monitoramento da métrica de fronteira é o que permite abortar cedo.

06 · O QUE MUDA NA ARQUITETURA

Projetar para a falha como caso normal

O efeito de longo prazo do caos é arquitetural. Como a morte de instâncias passou a ser rotina, serviços são projetados para tolerar perda de máquina. Como falhas entre serviços são injetadas, cada dependência não crítica ganha um fallback e o sistema aprende a degradar com graça. E como a região pode sair, os dados e a capacidade ficam replicados entre regiões.

07 · LIÇÕES E LIMITES

Quando não fazer caos

A fonte do Netflix já embute as condições de segurança. O Chaos Monkey só roda em horário comercial para ter gente de prontidão; o raio de impacto deve ser contido; e experimentos novos começam manuais, só depois são automatizados. Uma falha de integração real que eles citam, uma fila local sem limite que consome toda a memória do cliente, mostra por que testes tradicionais não bastam.

Por fim, a mudança é tão cultural quanto técnica: o ganho do Chaos Monkey foi fazer da tolerância a falhas um requisito de todo engenheiro, não um projeto de um time especialista. Replicar as ferramentas sem a mesma disciplina é copiar a forma sem o efeito.