O que é alta disponibilidade (HA)? Por que sua empresa precisa se planejar para isso
Obviamente, ninguém planeja o tempo de inatividade. Mas os problemas são inevitáveis e, se você não tiver um plano para lidar com eles imediata e automaticamente, perderá receita quando seus serviços caírem. A alta disponibilidade ajudará você a planejar os piores cenários.
O que é alta disponibilidade?
Alta disponibilidade (HA) é a prática de minimizar todo o tempo de inatividade do servidor, idealmente até zero. Ele incorpora muitas técnicas, como dimensionamento automático, monitoramento em tempo real e implantações automatizadas de atualização azul/verde.
O conceito principal é bastante simples - um servidor não é nenhum servidor. Dois servidores são um servidor. Quanto mais redundância você planejar, mais altamente disponível estará seu serviço. Seu serviço não deve sofrer interrupções, mesmo no caso de um de seus componentes pegar fogo.
Isso pode ser alcançado com algo tão simples quanto um grupo de dimensionamento automático, ao qual os serviços em nuvem, como o AWS, oferecem suporte muito bom. Se um servidor tiver um problema, como uma falha repentina, o balanceador de carga detectará que ele não está respondendo. Ele pode então desviar o tráfego do servidor com falha para os outros servidores no cluster, até mesmo ativando uma nova instância se precisar da capacidade.
Essa filosofia redundante se aplica a todos os níveis de sua hierarquia de componentes. Se você tiver um microsserviço para lidar com o processamento de imagem de mídia carregada pelo usuário, por exemplo, não seria uma boa ideia apenas executá-lo em segundo plano em uma de suas máquinas. Se essa máquina tiver problemas, os usuários podem não conseguir fazer o upload, o que conta como tempo de inatividade parcial do seu serviço e pode ser frustrante para o usuário final.
Às vezes, você precisa garantir a disponibilidade para os clientes. Se você garantir uma disponibilidade de 99,999% em um contrato de nível de serviço (SLA), isso significa que seu serviço não pode ficar inativo por mais de cinco minutos por ano. Isso torna o HA necessário desde o início para muitas grandes empresas.
Por exemplo, serviços como AWS S3 vêm com SLAs garantindo 99,9999999% (nove 9s) de redundância de dados. Isso basicamente significa que todos os seus dados são replicados entre as regiões, tornando-os seguros de tudo, exceto do cenário de impacto de um meteoro gigante em seu data warehouse. Mesmo assim, com a separação física, pode estar a salvo de pequenos meteoros ou, pelo menos, a salvo de incêndios em armazéns ou situações de falta de energia muito mais realistas.
Componentes de bons sistemas HA
O que leva ao tempo de inatividade? Exceto atos de Deus, o tempo de inatividade geralmente é causado por erro humano ou falha aleatória.
Falhas aleatórias não podem realmente ser planejadas, mas podem ser planejadas com sistemas redundantes. Eles também podem ser detectados enquanto ocorrem com bons sistemas de monitoramento que podem alertá-lo sobre problemas em sua rede.
O erro humano pode ser planejado. Em primeiro lugar, minimizando a quantidade de erros com ambientes de teste cuidadosos. Mas todo mundo comete erros, até mesmo grandes empresas, então você deve ter um plano para quando os erros acontecerem.
Escalonamento automático e redundância
O dimensionamento automático é o processo de dimensionar automaticamente o número de servidores que você possui, geralmente durante o dia, para atender picos de carga, mas também em situações de alto estresse.
Uma das principais maneiras pelas quais os serviços caem é o “abraço da morte”, quando milhares de usuários se reúnem em massa no site ou picos de tráfego de alguma outra forma. Sem dimensionamento automático, você está ferrado, pois não pode ativar mais nenhum servidor e deve esperar até que a carga diminua ou crie manualmente uma nova instância para atender à demanda.
O dimensionamento automático significa que você nunca terá que lidar com esse problema (embora precise pagar pelo tempo extra de servidor necessário). Isso é parte do motivo pelo qual serviços como bancos de dados sem servidor e AWS Lambda Functions são tão bons: eles escalam extremamente bem fora da caixa.
No entanto, vai além do dimensionamento automático de seus servidores principais — se você tiver outros componentes ou serviços em sua rede, eles também devem ser dimensionados. Por exemplo, você pode precisar ativar servidores Web adicionais para atender às necessidades de tráfego, mas se o servidor de banco de dados estiver sobrecarregado, você também terá problemas.
Se você quiser saber mais, pode ler nosso artigo sobre como começar com o dimensionamento automático da AWS.
Monitoramento 24/7
O monitoramento envolve o rastreamento de logs e métricas em seus serviços em tempo real. Fazer isso automaticamente com alarmes automáticos pode alertá-lo sobre problemas em sua rede enquanto eles estão acontecendo, e não depois que afetam os usuários.
Por exemplo, você pode definir um alarme para disparar quando o servidor atingir 90% de uso de memória, o que pode indicar um vazamento de memória ou um problema com um aplicativo sendo sobrecarregado.
Em seguida, você pode configurar esse alarme para instruir seu grupo de dimensionamento automático a adicionar outra instância ou substituir a instância atual por uma nova.
Atualizações automáticas de azul/verde
O cenário mais comum de erros é uma atualização malfeita, quando seu código muda e quebra uma parte imprevista de seu aplicativo. Isso pode ser planejado com implantações azul/verde.
Uma implantação azul/verde é um processo lento e gradual que implanta suas alterações de código em estágios, e não de uma só vez. Por exemplo, imagine que você tenha 10 servidores executando o mesmo software por trás de um balanceador de carga.
Uma implantação regular pode simplesmente atualizar todos eles imediatamente quando novas alterações são enviadas ou, pelo menos, atualizá-los um de cada vez para evitar o tempo de inatividade.
Uma implantação azul/verde acionaria um 11º servidor em seu grupo de dimensionamento automático e instalaria as novas alterações de código. Então, uma vez que estivesse “verde” ou aceitando solicitações e pronto para funcionar, ele substituiria imediatamente um dos servidores “azuis” existentes em seu grupo. Em seguida, você enxaguaria e repetiria para cada servidor no cluster. Mesmo se você tivesse apenas um servidor, esse método de atualização resultaria em nenhum tempo de inatividade.
Melhor ainda, você pode reverter imediatamente as alterações para os servidores azuis se forem detectados problemas com seus sistemas de monitoramento e alarmes. Isso significa que mesmo uma atualização completamente malfeita não desativará seu serviço por mais de alguns minutos, de preferência se você tiver vários servidores e puder implantar a atualização lentamente. As implantações azul/verde podem ser configuradas para atualizar apenas 10% de seus servidores a cada cinco minutos, por exemplo, implementando lentamente a atualização ao longo de uma hora.