Como garantir a disponibilidade de um serviço da web na nuvem no caso de uma falha no data center

O artigo descreve a opção de garantir a disponibilidade de um serviço da Web implantado na nuvem em caso de mau funcionamento no datacenter. A solução proposta é baseada em um compromisso que consiste em duplicação parcial : um sistema de backup é implantado em outro data center, que pode operar em um modo de funcionalidade limitada quando o data center principal não estiver disponível. Esse esquema é voltado principalmente para pedidos de falhas de curto prazo, mas também oferece a capacidade de transformar rapidamente o sistema de backup no principal em caso de problemas em grande escala.

Descrição do problema

No ano passado, fomos tocados por um incidente no data center de um famoso provedor de nuvem - um de nossos serviços ficou indisponível para os usuários por meia hora. Em seguida, vimos com nossos próprios olhos que, em caso de problemas no datacenter em nuvem, praticamente não existem alavancas para restaurar o aplicativo para o trabalho e, para a equipe responsável pelo aplicativo, não resta mais que colocar e esperar. Essa experiência nos levou a pensar seriamente no uso de nuvens em nossos produtos.

O que exatamente aconteceu naquele dia nunca foi descoberto. Estamos acostumados a perceber as nuvens como um posto avançado indestrutível, mas não é assim. A verdade é que não há garantia de cem por cento da disponibilidade do serviço na nuvem, como em qualquer outro lugar. As nuvens são uma abstração por trás da qual todos os mesmos racks com ferro nos data centers e o fator humano são ocultados. Qualquer hardware, mais cedo ou mais tarde, falha (embora as falhas de hardware nos datacenters sejam uma situação comum). Além disso, há casos de problemas mais sérios que levam à inacessibilidade dos data centers: incêndios, ataques DDoS, desastres naturais, interrupções na eletricidade e na Internet, etc.

Se falarmos sobre o fator humano, essa não é a causa mais recente de acidentes: "segundo as estatísticas, em 80% das falhas na infraestrutura de rede, as pessoas são as culpadas" . As pessoas, não importa quão bem-intencionadas sejam guiadas, não são confiáveis. Até você e seus colegas - pessoas diretamente interessadas na estabilidade dos produtos suportados - provavelmente cometeram erros, sem mencionar o pessoal da empresa de outra pessoa, para a qual suas instâncias não são diferentes de milhares de outras. Qualquer que seja a equipe profissional por trás da infraestrutura, uma nova falha é uma questão de tempo.

Tudo tem um preço. Quando você muda para a nuvem, obtém uma abstração simples, conveniente para trabalhar, uma fraca dependência do departamento de operações em troca de controle total sobre a situação. Nesse caso, se você não se cuidar com antecedência, tendo previsto a possibilidade de erros de outras pessoas, ninguém fará isso.

Opções de solução

Para nós, a indisponibilidade do serviço, mesmo por vários minutos, já é crítica. Portanto, decidimos encontrar uma maneira de nos proteger contra problemas semelhantes no futuro, sem abandonar as nuvens.

Ao começar a resolver o problema de disponibilidade de serviços na nuvem, deve-se ter em mente que a acessibilidade é um conceito bastante amplo e, dependendo do significado, são considerados vários cenários de sua provisão. Embora este artigo discuta apenas o problema da acessibilidade como resultado de uma falha no data center, seria apropriado dizer algumas palavras sobre soluções para outros problemas de acessibilidade.

Disponibilidade como uma oportunidade técnica para fornecer acesso a um recurso por um tempo específico em uma determinada carga. O problema ocorre quando o serviço está em execução, mas devido aos recursos limitados e à estrutura arquitetônica do sistema, nem todos os usuários podem acessá-lo em um determinado tempo de resposta. A tarefa geralmente é resolvida implementando instâncias adicionais com o aplicativo. Com essa escala, as nuvens fazem um ótimo trabalho.

Acessibilidade como a disponibilidade de um serviço da web para usuários de uma região específica. A solução óbvia aqui é fragmentação. Em outras palavras, dividir o sistema em vários aplicativos independentes em diferentes datacenters com seus próprios dados e atribuir cada usuário à instância do sistema, por exemplo, com base em sua localização geográfica. Ao compartilhar, a falha de um datacenter, na pior das hipóteses, resultará na indisponibilidade do serviço para apenas uma parte dos usuários vinculados a esse datacenter. Não é o último argumento a favor do sharding - este é um tempo de ping diferente para o datacenter em diferentes regiões.

No entanto, muitas vezes as restrições ao trabalho com a nuvem e a necessidade de descentralização são requisitos legislativos que geralmente são levados em consideração mesmo no estágio de design do sistema. Esses requisitos incluem: Lei de Yarovaya - armazenamento de dados pessoais (PD) de usuários na Rússia; Regulamento Geral de Proteção de Dados (RGPD) - restrições à transferência transfronteiriça de DP de usuários da UE para alguns países; e censura chinesa à Internet, onde TODAS as comunicações e TODAS as partes do aplicativo devem estar localizadas na China e, de preferência, em seus servidores.

O problema de inacessibilidade técnica do datacenter é resolvido duplicando o serviço em outro datacenter. Esta não é uma tarefa técnica fácil. O principal obstáculo para a implantação paralela de serviços em diferentes datacenters é o banco de dados. Normalmente, pequenos sistemas usam uma arquitetura de assistente único. Nesse caso, a falha do datacenter com o mestre torna todo o sistema inoperante. Um esquema de replicação principal de replicação é possível, mas impõe fortes limitações que nem todo mundo entende. De fato, ele não dimensiona o registro para o banco de dados, mas oferece uma pequena penalidade de tempo, pois é necessário confirmar todos os nós que a transação foi aceita. O tempo de operação de gravação aumenta ainda mais quando os nós devem ser espaçados em diferentes datacenters.

Justificação da decisão

A análise da carga em nosso serviço mostrou que, em média, cerca de 70% das chamadas para a API são feitas pelos métodos GET. Esses métodos usam um banco de dados somente leitura.


Distribuição de chamada do método HTTP de serviço da Web

Penso que estes resultados refletem toda a imagem dos serviços web geralmente disponíveis. Portanto, podemos dizer que na API média de serviço da web, os métodos de leitura são chamados com muito mais frequência do que os métodos de gravação .

A segunda declaração que eu gostaria de apresentar é que, se falarmos sobre acessibilidade absoluta, os clientes do serviço realmente precisam dessa acessibilidade não apenas da riqueza de métodos de API disponíveis, mas apenas daqueles necessários para continuar o trabalho "usual" com o sistema e executando consultas "normais" . Ninguém ficará chateado se um método acessado duas vezes por mês estiver indisponível por vários minutos. Freqüentemente, o fluxo "normal" é coberto pelos métodos de leitura.

Portanto, garantir a disponibilidade absoluta de apenas métodos de leitura já pode ser considerado como uma opção possível para uma solução de curto prazo para o problema de disponibilidade do sistema em caso de falha do data center.

O que queremos implementar

Em caso de falhas no datacenter, gostaríamos de mudar o tráfego para um sistema de backup em outro datacenter. No sistema de backup, todos os métodos de leitura devem estar disponíveis e, ao chamar os métodos restantes, se for impossível fazê-lo sem gravar no banco de dados, o erro correto deve ser exibido.

Em operação normal, a solicitação do usuário é enviada ao balanceador, que por sua vez o redireciona para a API principal. Se o serviço principal estiver indisponível, o balanceador determinará esse fato e redirecionará as solicitações para o sistema de backup que opera no modo de funcionalidade limitada. No momento, a equipe analisa o problema e decide aguardar a restauração do datacenter ou alternar o sistema de backup para o modo principal.

Algoritmo de implementação

Alterações necessárias na infraestrutura

1. Criando uma replicação escrava do banco de dados em outro datacenter.
2. Configurando uma implantação de serviço web, coletando logs, métricas no segundo data center.
3. A configuração do balanceador para alternar o tráfego para um data center sobressalente, caso o primeiro esteja indisponível.

Alterações de código:

1. Adicionando uma conexão separada à réplica no serviço da web.
2. Migrar todas as rotas de API somente leitura para uma réplica.
3. Para os métodos restantes, a introdução do modo somente leitura por meio de uma variável de ambiente ou outro gatilho, na qual eles, em vez de gravar no banco de dados, funcionará parcialmente ou, se sua funcionalidade for interrompida sem gravar no banco de dados, cometerá um erro correto.
4. Melhorias no frontend para exibir o erro correto ao chamar métodos de gravação.

Prós e contras da solução descrita

Os benefícios

• A principal vantagem do esquema proposto é que sempre existe um serviço duplicado, a qualquer momento, pronto para atender os usuários. Em caso de problemas com o data center principal, você não precisará escrever scripts de implantação em outra infraestrutura e executar tudo com pressa.
• A solução é barata de implementar e manter. Se você tiver uma arquitetura de microsserviço e o produto não precisar de um, mas de muitos serviços, nesse caso, não haverá problemas especiais com a transferência de todos os microsserviços para esse esquema.
• Não há ameaça de perda de dados, pois sempre há uma cópia completa do banco de dados na réplica em outro datacenter.
• A solução destina-se principalmente à troca temporária de tráfego, até meia hora. Esta meia hora não é suficiente para navegar em caso de problemas com a infraestrutura. Se durante esse período o primeiro datacenter não for restaurado, a réplica escrava do banco de dados se tornará um mestre e o serviço duplicado se tornará o principal.
• No esquema proposto, o aplicativo e o banco de dados estão no mesmo data center. Se você possui uma API e um banco de dados em diferentes datacenters, é melhor transferi-los para um: isso reduzirá significativamente o tempo de execução da consulta. Por exemplo, nossas medições mostraram que, para o Google Cloud, a solicitação da API para o banco de dados em um datacenter é em média de 6 ms e, ao ir para dados em outro datacenter, o tempo aumenta em dezenas de milissegundos.

Desvantagens

• A principal desvantagem de todo o esquema é que, para a troca instantânea de tráfego, é necessário um balanceador que não esteja localizado no mesmo datacenter que o serviço principal. O balanceador é o ponto de falha: se o data center com o balanceador falhar, seu serviço ficará indisponível em qualquer caso.
• A necessidade de implantar o código em outro servidor, monitora recursos adicionais - por exemplo, monitore a réplica para que não haja atraso.

Conclusão

Você não pode criar um sistema resistente a todos os tipos de falhas. No entanto, proteger-se de certos tipos é uma tarefa viável. A solução descrita no artigo, que permite garantir a disponibilidade do aplicativo em caso de mau funcionamento no data center, pode ser interessante e útil em aplicações práticas em muitos casos.

Converter um serviço da Web regular em um sistema totalmente distribuído para proteger contra falhas hipotéticas no datacenter é provavelmente impraticável. À primeira vista, até o esquema proposto parece redundante e "pesado", mas essas desvantagens são mais do que sobrepostas por suas vantagens e facilidade de implementação. Você pode fazer uma analogia com o seguro contra acidentes: existe uma alta probabilidade de você nunca precisar desse seguro, mas se ocorrer um acidente, será muito bem-vindo. Com o esquema proposto, você sempre terá um sistema de backup pronto, o que, para problemas de curto prazo, garantirá a disponibilidade da maioria dos métodos de serviço e, em caso de longas falhas, ele poderá se transformar completamente no principal em questão de minutos. Muitos concordarão em pagar esse preço por essa confiança.

Cada sistema possui seus próprios parâmetros de carga exclusivos e requisitos de acessibilidade. É por isso que não há resposta certa ou errada para a pergunta: "Você pode confiar totalmente no Google Cloud ou na AWS?" - em cada situação específica, ele será seu.