A Amazon executou uma grande atualização no final de Setembro para cobrir uma vunerabilidade de segurança nos hypervisor Xen, afetando cerca de 10% de todo o parque global de servidores. Durante essa atualização foi necessária a reinicialização desses servidores, causando indisponibilidade aos usuários do AWS, incluindo um de seus maiores clientes, o Netflix.
O gerente de banco de dados na Cloud do Netflix, Christos Kalantzis, demonstrou sua preocupação assim que ficou sabendo da operação de atualização.
Quando recebemos a notícia da reinicialização emergencial no EC2, ficamos de queixo caído. Quando levantamos a lista de quantos servidores Cassandra seriam afetados, eu me senti mal. Então eu lembrei de todos os testes com o Chaos Monkey pelo qual passamos e minha reação foi, "Vamos nessa".
O Netflix tem uma longa história na utilização dessas ferramentas - Chaos Monkey, Gorila e Kong - que força a reinicialização de seus servidores com a finalidade de entender melhor como todo o sistema reage e o que pode ser feito para melhorar sua resiliência. O problema neste caso é que a operação de atualização afetaria alguns de seus servidores de dados, mais exatamente 218 nós Cassandra. Uma coisa é realizar a reinicialização de servidores de streaming de vídeo, porém fazer o mesmo para banco de dados stateful é mais difícil.
Felizmente, o Netflix começou a utiliza o Chaos Monkey para nós Cassandra há um ano atrás, desenvolvendo as ferramentas necessárias para migrar um nó para outra máquina quando fosse necessário. Durante a atualização da AWS, o resultado foi:
Dos mais de 2700 nós Cassandra em produção, 218 fora reinicializados. 22 Nós Cassandras estavam em máquinas físicas que não reinicializaram com sucesso, fazendo com que esses nós não voltassem ao seu estado normal. Nossas ferramentas de automação detectaram esta falha e substituíram todos os nós necessários, com mínimo intervenção humana. O Netflix não teve indisponibilidade durante o final de semana.
O InfoQ.com quis saber mais sobre esse incidente e como o Netflix lidou com isso, então conversamos com Bruce Wong, gerente de engenharia de caos do Netflix:
InfoQ.com: A última grande atualização da AWS envolveu a reinicialização de aproximadamente 10% de suas máquinas. Não foi possível mover ao menos algumas das instâncias do Cassandra para os outros 90% de máquinas que não possuem o Xen e não precisariam ser reinicializadas?
Wong: Consideramos isso junto da AWS e descobrimos que não era possível completar a migração para os outro 90% a tempo. Poderíamos migrar algumas da instâncias, porém não havia garantia de que essas instâncias não seriam afetadas da mesma forma. Não tivemos acesso a informações mais detalhadas sobre a causa raiz do problema que gerou a reinicialização. Tudo que tivemos foi um quadro informativo das instâncias que seriam impactadas com a reinicialização. Tivemos a oportunidade de reinicializar os nós Cassandra a tempo para ajudar a antecipar o impacto.
InfoQ.com: Antes da atualização, houve a tentativa de tirar de produção 10% de suas máquinas com o Chaos Monkey para ver como o sistema lidaria com esse incidente?
Wong: Tiramos 33% de nossas máquinas com o Chaos Gorilla antes da atualização para entender como o sistema lidaria com a indisponibilidade de uma zona. Não tentamos tirar 10%, um por um durante uma certa quantidade de dias, o que simularia diferentes tipos de falha.
InfoQ.com: Como podemos comparar a manutenção da AWS com as falhas geradas pelo Chaos Gorilla e o Chaos Kong?
Wong: Comparar a manutenção da AWS com os eventos causados pelo Chaos Gorilla e o Chaos Kong é o mesmo que comparar laranjas com maçãs. Para o Chaos Gorilla, retiramos todo o tráfego de um zona inteira; já para no caso da manutenção da AWS, nunca paramos o tráfego da zona em manutenção. O mesmo ocorre para o Chaos Kong, retiramos todo o tráfego de um região inteira.
InfoQ.com: Porque o Cassandra foi mais difícil de integrar ao processo de Engenharia do Caos?
Wong: Em partes devido a um problema ferramental. Gerimos nós Cassandra de maneira bem diferente de nossas aplicações Stateless. Então, não era possível aproveitar o trabalho que já havia sido realizado. O grande desafio era psicológico. Uma vez que superamos o obstáculo mental de introduzir o Chaos na camada de dados, foi apenas uma questão de escrever corretamente a automação e ferramentas. Uma vez, completo, o Cassandra se tornou integrante do processo de Engenharia de Caos.
InfoQ.com: Como foi lidar com o estado do banco de dados que ficou indisponível?
Wong: Configuramos o Cassandra para manter 3 cópias de todo os dados. A qualquer momento, podemos perder ⅔ de nosso cluster e ainda manter o funcionamento normal. Quando um nó fica indisponível e precisa ser substituído, o novo nó sabe quais dados ele deve ter. Então ele pergunta para os seus pares por tais dados. Uma vez que todos os dados são recebidos, ele se junto novamente ao cluster, e o Cluster volta ao normal.