As duas perguntas que você precisa responder para obter alta disponibilidade

Talvez o maior impacto nas operações devido à migração abrupta de consumidores e funcionários para experiências digitais seja a disponibilidade. Certamente, uma porcentagem significativa de organizações teve dificuldades com o acesso remoto à medida que os funcionários se mudavam do escritório para casa. Mas apenas alguns trabalhadores acabaram trabalhando em casa, enquanto populações inteiras passaram a depender de equivalentes digitais para a vida cotidiana. 

Considere as descobertas da Nokia , que relata que "o tráfego upstream (redes selecionadas nos EUA) no mês de março de 2020" viu um "aumento de 30% no tráfego upstream em relação aos níveis pré-pandemia". Ou estes dados mostrando um aumento de 72% nas transações (e 29% nas visualizações de página) na segunda semana de abril.  

A demanda por experiências digitais está aumentando. E não há nada mais frustrante para um usuário do que um aplicativo ou site que não carrega. Para ser honesto, não há nada mais frustrante para um operador do que um aplicativo ou site que não carrega.

Alcançar alta disponibilidade não é apenas uma questão de inserir um balanceador de carga no caminho de dados. Isso faz parte da equação, mas é apenas uma das etapas necessárias para garantir que um aplicativo ou site permaneça disponível.

A primeira coisa que você precisa fazer é responder a duas perguntas não tão simples:

• Como você distribui o tráfego entre servidores para alta disponibilidade?
• Qual nível de verificação de integridade é necessário para validar corretamente a disponibilidade de um servidor?

À primeira vista, elas parecem mais simples do que realmente são. Isso porque para respondê-las você precisa saber muito sobre o aplicativo e sua infraestrutura.

Vamos começar, tudo bem?

Como você distribui o tráfego entre servidores para alta disponibilidade?

Esta questão realmente busca o algoritmo de balanceamento de carga correto a ser usado, já que os algoritmos são o que determinam como o tráfego (solicitações) é distribuído entre os recursos (servidores). A resposta para isso depende de muitas coisas, mas começa com a arquitetura do aplicativo e os padrões de uso. 

Veja bem, se você está tentando tornar um aplicativo tradicional (monólito, cliente-servidor, web de três camadas) altamente disponível, você tem que entender os padrões de uso de uma perspectiva totalmente diferente.

Isso ocorre porque um "servidor" de back-end é responsável por executar toda a lógica de negócios. Tentando fazer login? Encomendando um produto? Navegando pelo catálogo? Tudo o mesmo "servidor". Você pode pensar que pode simplesmente usar um algoritmo simples como round-robin para distribuir o tráfego. Pelo contrário, meu amigo. Cada função empresarial tem diferentes requisitos de computação, memória, rede e dados. Isso significa que cada função empresarial coloca uma carga diferente no "servidor". Uma única instância de "servidor" pode ficar rapidamente sobrecarregada simplesmente direcionando muitas solicitações que consomem muitos recursos a ela.

A melhor maneira de otimizar a distribuição de solicitações para garantir a disponibilidade de aplicativos tradicionais é usar um algoritmo baseado em menos conexões. Isso manterá a carga distribuída entre instâncias de "servidores" com base no número de conexões abertas no momento. O motivo pelo qual isso funciona é porque solicitações com muitos recursos levarão mais tempo para serem processadas, mantendo assim as conexões ativas. Ao direcionar solicitações para "servidores" com menos conexões, você tem mais chances de manter todos eles disponíveis.  

Para aplicativos modernos (baseados em microsserviços), essa pergunta é mais facilmente respondida. Isso ocorre porque um aplicativo moderno já é decomposto em funções de negócios que podem ser dimensionadas individualmente. Ainda é uma boa ideia usar um algoritmo baseado em menos conexões porque algumas solicitações para a mesma função podem consumir mais recursos do que outras, mas o tráfego é naturalmente equilibrado em uma arquitetura de aplicativo moderna, então praticamente qualquer algoritmo servirá para manter todos os "servidores" disponíveis.

O interessante (para mim, pelo menos) sobre disponibilidade é que saber como distribuir solicitações é apenas metade da batalha. O outro, infelizmente, não são os lasers vermelho e azul, mas depende da visibilidade do estado de saúde do aplicativo.

Qual nível de verificação de integridade é necessário para validar corretamente a disponibilidade de um servidor?

É aqui que minha dissertação sobre observabilidade* deve ser inserida, mas, por uma questão de brevidade e sua sanidade, vou resumir assim: 

Se você estiver usando algo diferente de "disponibilidade do aplicativo" para determinar o status de um aplicativo, estará colocando a alta disponibilidade em risco. Isso porque nenhuma das outras medidas observáveis lhe diz nada sobre o aplicativo. Embora você precise de rede, transporte e disponibilidade de plataforma, até ter certeza da prontidão do aplicativo para receber solicitações, você está pedindo problemas se enviar tráfego a ele.

Todos os quatro componentes da observabilidade são importantes. Se você perder a conectividade de rede, o resto realmente não importa. Portanto, você precisa ficar de olho em todas as quatro medidas, o que significa verificar todas elas. Não importa qual seja a arquitetura do aplicativo. Todos os aplicativos dependem das camadas de rede, transporte e plataforma. Onde a arquitetura faz a diferença é na camada do aplicativo, porque ela pode restringir a maneira como você determina se o aplicativo está funcionando ou não.

Você deve sempre solicitar uma maneira de "verificar a integridade" do aplicativo durante o desenvolvimento. Seja por meio de uma solicitação de API ou HTTP, a existência de uma "verificação de integridade" dedicada oferece aos desenvolvedores e operações uma maneira fácil de verificar se o aplicativo está funcionando corretamente. Isso pode incluir funcionalidades que verificam a conectividade com recursos externos, como dados ou APIs de parceiros. Como a falha de qualquer um desses componentes pode fazer com que o aplicativo pareça indisponível ou não responda ao consumidor, é importante verificar a disponibilidade de todos os componentes necessários.

Alta disponibilidade é mais difícil do que parece

Muitas vezes, a literatura de marketing leva você a acreditar que alta disponibilidade é tão simples quanto clonar um servidor e colocar um balanceador de carga na frente dele. Mas a realidade é que há considerações, medições e preparações sérias necessárias para garantir que um aplicativo seja altamente disponível. Não é apenas uma questão de garantir que as instâncias estejam disponíveis; é uma questão de garantir que todos os seus aplicativos dependentes estejam disponíveis e distribuir solicitações de uma forma que não sobrecarregue nenhuma instância específica.

A vantagem de todo o trabalho extra que você faz para garantir que os aplicativos estejam altamente disponíveis é uma experiência positiva para o cliente e menos chamadas frenéticas tarde da noite sobre aplicativos que estão inativos.

_{* Na verdade, não tenho uma dissertação sobre observabilidade. Mas se eu tivesse feito isso, seria aqui que ele teria sido inserido.}