No final do ano passado, o Netflix Tech Blog escreveu sobre cinco lições que aprenderam ao migrar para a Amazon Web Services. A AWS é, obviamente, o principal fornecedor da chamada “computação em nuvem”, portanto, isso pode ser lido essencialmente como conselho fundamental para qualquer site que esteja pensando em migrar para a nuvem. E é um ótimo conselho também. Aqui está a parte que me pareceu mais essencial:
Algumas vezes nos referimos à arquitetura de software da Netflix na AWS como nossa Arquitetura Rambo. Cada sistema deve ser capaz de ter sucesso, não importa o que aconteça, mesmo sozinho. Estamos projetando cada sistema distribuído para esperar e tolerar falhas de outros sistemas dos quais ele depende.
Se nosso sistema de recomendações estiver fora do ar, prejudicamos a qualidade de nossas respostas aos clientes, mas ainda assim respondemos. Mostraremos títulos populares em vez de escolhas personalizadas. Se o nosso sistema de busca estiver intoleravelmente lento, o streaming ainda deverá funcionar perfeitamente bem.
Um dos primeiros sistemas que nossos engenheiros criaram no AWS é chamado de Chaos Monkey. O trabalho do Chaos Monkey é eliminar aleatoriamente instâncias e serviços em nossa arquitetura. Se não estivermos testando constantemente nossa capacidade de ter sucesso apesar das falhas, é provável que não funcione quando for mais importante: no caso de uma interrupção inesperada.
O que, convenhamos, parece um conselho insano à primeira vista. Não sei se muitas empresas sequer entendem por que isso seria uma boa ideia, muito menos têm coragem de tentar. Levante a mão se o senhor trabalha, alguém implantou um daemon ou serviço que mata aleatoriamente servidores e processos em seu farm de servidores.
Agora levante a outra mão se essa pessoa ainda estiver empregada em sua empresa.
Quem em sã consciência escolheria de bom grado trabalhar com um Chaos Monkey?
Às vezes, o senhor não tem escolha; o Chaos Monkey o escolhe. Em Stack ExchangeEm uma reunião com o senhor, lutamos durante meses com um problema bizarro. A cada poucos dias, um dos servidores do Web Farm do Oregon simplesmente pararia de responder a todas as solicitações de rede externa. Sem motivo, sem lógica e sem recuperação, exceto por uma sequência de desligamento lenta e excruciante que exigia que o servidor ficasse em tela azul antes de ser reiniciado.
Passamos meses – literalmente meses — perseguindo isto problema para baixo. Fizemos uma lista de tudo o que pudemos pensar para resolvê-lo, e mais um pouco:
- troca de portas de rede
- substituição de cabos de rede
- um switch diferente
- várias versões do driver de rede
- Ajuste das configurações de rede no nível do sistema operacional e do driver
- simplificando nossa configuração de rede e removendo TProxy para uma versão mais tradicional
X-FORWARDED-FOR - troca de provedores de virtualização
- mudando nosso Modelo de host TCP/IP
- Obtendo hotfixes do kernel e aplicando-os
- envolvendo equipes de suporte de alto nível dos fornecedores
- algumas outras coisas que agora esqueci porque desmaiei de dor
Em um determinado momento dessa saga, nossa equipe quase entrou em conflito porque estávamos muito frustrados. (Bem, o mais próximo de “brigas” que um equipe remota pode usar o Skype, mas o senhor sabe o que quero dizer). O senhor pode nos culpar? A cada poucos dias, um de nossos servidores – não se sabe qual – ficava fora da rede aleatoriamente. O Chaos Monkey ataca novamente!
Mesmo em nosso momento de maior frustração, percebi que havia um lado positivo em tudo isso:
- Quando tínhamos um servidor desempenhando uma função essencial, passamos a ter dois.
- Se não tínhamos uma alternativa sensata para algo, criávamos uma.
- Removemos dependências em todos os lugares, reduzindo-as ao mínimo absoluto necessário para a execução.
- Implementamos soluções alternativas para permanecer em execução o tempo todo, mesmo quando os serviços que antes considerávamos essenciais de repente não estavam mais disponíveis.
A cada semana que passava, tornávamos nosso sistema um pouco mais redundante, porque era necessário. Apesar da dor contínua, ficou claro que o Chaos Monkey estava nos fazendo um grande favor ao nos forçar a nos tornarmos extremamente resilientes. Não amanhã, nem algum dia, nem em algum ponto indeterminado “eventualmente chegaremos lá” no futuro, mas agora mesmo, onde dói.
Agora, nada disso é novidade; nosso problema já foi resolvido há muito tempo, e o artigo do Netflix Tech Blog a que me refiro foi publicado no ano passado. Eu queria escrever sobre isso, mas o Tenho estado um pouco ocupado. Talvez o momento seja profético; A AWS teve uma enorme interrupção de vários dias na semana passada, que tirou do ar vários sites importantes, além de uma constelação de sites menores.
Notavelmente ausente dessa lista de sites da AWS afetados? Netflix.
Quando o senhor trabalha com o Chaos Monkey, aprende rapidamente que tudo acontece por uma razão. Com exceção das coisas que acontecem de forma completamente aleatória. E é por isso, mesmo que pareça loucura, a melhor maneira de evitar o fracasso é fracassar constantemente.
(update: Netflix lançou sua versão do Chaos Monkey no GitHub. Experimente!)