O que é alta disponibilidade (HA)? Por que sua empresa precisa se planejar para isso

Obviamente, ninguém planeja 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 forem interrompidos. A alta disponibilidade o ajudará 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 para zero. Ele incorpora muitas técnicas, como escalonamento automático, monitoramento em tempo real e implantações automatizadas de atualização azul / verde.
O conceito central é bastante simples — um servidor não é um servidor. Dois servidores são um servidor. Quanto mais redundância você planejar, maior será a disponibilidade de 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 como um grupo de escalonamento automático, que serviços de nuvem como AWS suportam muito bem. Se um servidor tiver um problema, como uma queda repentina, o balanceador de carga o detectará como não respondendo. Ele pode então desviar o tráfego do servidor travado 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ê tem um microsserviço para lidar com o processamento de imagens 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 disponibilidade aos 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 regiões, tornando-os protegidos de tudo, exceto do cenário de meteoros gigantes que impactam seu data warehouse. Mesmo assim, com a separação física, pode estar a salvo de pequenos meteoros ou, pelo menos, a salvo de um incêndio em armazém muito mais realista ou situação de queda de energia.
Componentes de bons sistemas HA
O que leva ao tempo de inatividade? Exceto por atos divinos, o tempo de inatividade geralmente é causado por erro humano ou falha aleatória.
As falhas aleatórias não podem realmente ser planejadas, mas podem ser planejadas com sistemas redundantes. Eles também podem ser detectados enquanto acontecem 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 todos cometem erros, mesmo as grandes empresas, então você deve ter um plano para quando os erros acontecerem.
Escala automática & Redundância
O escalonamento automático é o processo de escalonar automaticamente o número de servidores que você possui, geralmente durante o dia, para atender ao pico de carga, mas também em situações de alto estresse.
Uma das principais maneiras pelas quais os serviços são interrompidos é o “ abraço da morte, ” quando milhares de usuários acessam o site em massa ou o tráfego aumenta de alguma outra forma. Sem o escalonamento automático, você está ferrado, já que não pode ativar mais nenhum servidor e deve esperar até que a carga diminua ou ativar manualmente uma nova instância para atender à demanda.
O escalonamento automático significa que você realmente nunca terá que lidar com esse problema (embora precise pagar pelo tempo extra de servidor de que precisa). Isso é parte do motivo pelo qual serviços como bancos de dados sem servidor e funções do AWS Lambda são tão bons: eles escalam extremamente bem fora da caixa.
No entanto, vai além de apenas escalonar automaticamente seus servidores primários — se você tiver outros componentes ou serviços em sua rede, eles também devem ser escaláveis. Por exemplo, você pode precisar ativar servidores da web adicionais para atender às necessidades de tráfego, mas se o servidor de banco de dados estiver sobrecarregado, você também terá um problema.
Se você quiser saber mais, pode ler nosso artigo sobre os primeiros passos com o escalonamento automático da AWS.
RELACIONADO: Primeiros passos com escalonamento automático da AWS
Monitoramento 24 horas por dia, 7 dias por semana
O monitoramento envolve o rastreamento de registros 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 a sobrecarga de um aplicativo.
Então você pode configurar este alarme para dizer ao seu grupo de escalonamento automático para adicionar outra instância ou substituir a instância atual por uma nova.
Atualizações automatizadas de azul / verde
O cenário mais comum para 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 em azul / verde.
Uma implantação azul / verde é um processo lento e gradual que implanta as alterações de código em estágios, em vez de todas de uma 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 escalonamento automático, e instalaria as novas alterações de código. Então, quando ficou “ verde, ” ou aceitando solicitações e pronto para uso, ele substituiria imediatamente um dos existentes “ azul ” servidores em seu grupo. Em seguida, você enxágue e repita para cada servidor no cluster. Mesmo se você tivesse apenas um servidor, esse método de atualização não resultaria em tempo de inatividade.
Melhor ainda, você pode reverter imediatamente as alterações de volta 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 interromperá o serviço por mais de alguns minutos, idealmente não interromperá o funcionamento 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% dos seus servidores a cada cinco minutos, por exemplo, implementando lentamente a atualização ao longo da hora.
Nenhum comentário