Os cinco principais padrões de escalabilidade

Disponibilidade é um negócio sério em uma economia onde aplicativos são moeda. Aplicativos que não respondem são sumariamente excluídos e difamados na Internet com a velocidade e o sarcasmo de uma avaliação negativa no Yelp.

Desde os primórdios da Internet, as organizações buscam garantir que os aplicativos (antigos sites) estejam disponíveis 24 horas por dia, 7 dias por semana, 365 dias por ano. Porque a Internet nunca dorme, nunca tira férias e nunca falta dizendo que está doente.

Para atender a essa necessidade (exigência, na verdade), a escalabilidade surgiu como um dos primeiros serviços de aplicativos a fornecer disponibilidade. O serviço de aplicação mais visível – e bem compreendido – que atende às necessidades de disponibilidade é o balanceamento de carga.

No entanto, há muitas formas de balanceamento de carga e padrões de escalabilidade que você pode implementar usando essa tecnologia central. Hoje, vou destacar os cinco principais padrões de escalabilidade em uso que mantêm os aplicativos e a Internet online e disponíveis 24 horas por dia, 7 dias por semana, 365 dias por ano.

Global Server Load Balancing (GSLB)

GSLB tem um nome terrivelmente equivocado. Na verdade, nunca se tratou de balanceamento de carga do servidor , mas sim de disponibilidade do site . Hoje, isso está se estendendo para significar também a disponibilidade de aplicativos.

GSLB é o meio pelo qual você garante que, se um data center (na nuvem ou tradicional) não estiver respondendo, você poderá encontrar outro. O GSLB pode ser aplicado no nível de domínio ou host. Assim, você pode usá-lo para alternar example.com entre locais, bem como api.example.com.

Em sua forma mais básica, o GSLB usa balanceamento de carga rudimentar baseado em DNS. Isso significa que ele tem uma lista de endereços IP associados a um domínio ou host e, se o primeiro não estiver disponível, as solicitações são direcionadas ao segundo na lista – ou terceiro, ou quarto, e assim por diante.

Este processo tem duas etapas:

1. Peça ao balanceador de carga global o endereço IP apropriado. Esse é o aspecto negativo sempre associado ao GSLB: se você perguntou nos últimos 15 minutos ou qualquer que seja o TTL atual para o endereço IP do cheese.com, você receberá a última resposta que recebeu. Então, se o site cair nesse período, você não conseguirá se conectar.
2. Faça a solicitação ao endereço IP do site retornado pela consulta GSLB. Isso geralmente acaba sendo um balanceador de carga local que usa seus próprios algoritmos e processo de tomada de decisão para levar a solicitação ao recurso apropriado.

Geralmente não há inteligência na decisão tomada na etapa 1; ela é estritamente baseada em se um determinado site está respondendo ou não. Ainda assim, é assim que você pode usar vários locais – nuvem, provedor de hospedagem, local – para garantir a disponibilidade. Ao escolher estrategicamente locais em diversas áreas geográficas, você pode evitar o impacto de desastres naturais ou interrupções na Internet.

Mas isso é mais um cenário de DR (recuperação de desastres) ou BC (continuidade de negócios). Há outros que aproveitam serviços de aplicativos GSLB mais inteligentes, como geolocalização e desempenho de aplicativos. Então, se o aplicativo no Site A estiver com desempenho ruim, talvez você queira enviar visitantes para o Site B até que o problema seja resolvido. Ou talvez você queira direcionar os usuários para o local geograficamente mais próximo para ajudar a melhorar o desempenho (porque a velocidade da luz ainda é uma regra e a distância é importante para o desempenho do aplicativo).

Independentemente de como a decisão é tomada, o padrão básico permanece o mesmo: O GLSB distribui solicitações entre vários sites fisicamente separados, retornando o endereço IP de um dos sites disponíveis. Sejam APIs ou aplicativos, o GSLB é um padrão de garantia de disponibilidade de alto nível.  

Balanceamento de carga simples e antigo (POLB)

Disponibilidade baseada em conexão

Plain Old Load Balancing (POLB) é um termo que gosto de usar para descrever o balanceamento de carga padrão baseado em TCP. A disponibilidade é alcançada usando esse padrão simplesmente clonando aplicativos e garantindo que uma conexão entre o cliente (usuário, dispositivo) e o aplicativo possa ser feita.

O balanceador de carga (ou proxy, se preferir) recebe uma solicitação de conexão, seleciona uma instância de aplicativo disponível e encaminha a conexão. Essa é a última vez que o balanceador de carga se envolve ativamente. É como o "e-mail de introdução" em que você facilita a reunião de dois colegas. Você é um participante ativo na troca inicial, mas posteriormente é movido para a linha cc e geralmente não se envolve mais.

Eu uso o termo POLB porque não há nada mais do que algoritmos envolvidos na escolha de como direcionar as solicitações. Infelizmente, há muitas coisas que podem dar errado dependendo do algoritmo usado para distribuir as solicitações. Por exemplo, o round robin não se importa com capacidade ou desempenho. Ele apenas seleciona “o próximo aplicativo” e a solicitação é executada. Escolher “menos conexões” pode impactar rapidamente o desempenho ao carregar um recurso, enquanto outras podem ser mais rápidas. A escolha de algoritmos se torna um componente crítico para manter a disponibilidade.

POLB é o método padrão de balanceamento de carga dentro de ambientes de contêiner e para muitos serviços de balanceamento de carga nativos da nuvem.

Persistência

Sessões Fixas e SSL

Uma das realidades dos aplicativos de três camadas é que eles são, como regra geral, com estado. Isso significa que eles armazenam informações entre solicitações e respostas que são essenciais para a operação do aplicativo. Seu carrinho de compras, credenciais, status, última página que você visitou e em qual etapa do processo você está são todos detalhes que geralmente são armazenados como parte da “sessão”. O problema é que muitos aplicativos desenvolvidos usando estruturas de três camadas acabam armazenando essa sessão no aplicativo ou servidor web, e não em um banco de dados. Isso significava que, uma vez conectado a um servidor, você tinha que voltar a ele várias vezes para ter certeza de que todas as suas informações estavam disponíveis.

Os balanceadores de carga implementam persistência de várias maneiras, sendo a mais popular baseada em cookies. Os IDs de sessão eram armazenados em um cookie que era então usado pelo balanceador de carga para garantir que as solicitações chegassem ao servidor correto, ignorando efetivamente um processo de seleção algorítmica.

Quando o uso de SSL/TLS se tornou um requisito crítico para que os compradores se sentissem seguros, os mesmos problemas surgiram. SSL/TLS permite uma sessão segura entre um cliente e um servidor de aplicativo específico. Para garantir que ambos os lados da conversa pudessem descriptografar e usar os dados trocados por essa conexão, o balanceador de carga precisava ser capaz de enviar solicitações do cliente para o mesmo servidor em que começou. Usando as mesmas técnicas que permitem a persistência baseada em sessão, os balanceadores de carga conseguiram oferecer suporte à persistência baseada em SSL/TLS.

Independentemente do tipo específico de persistência usado, o padrão é o mesmo. Se houver um indicador de que uma sessão já foi estabelecida, o balanceador de carga honrará a conexão existente e garantirá que ela permaneça durante toda a sessão do usuário. Caso contrário, o balanceador de carga seleciona um recurso com base em sua configuração e algoritmos e faz a conexão.

Isso tem consequências no planejamento de capacidade ao selecionar um algoritmo de balanceamento de carga. Menos conexões é uma boa escolha para esse cenário, pois garante que nenhum recurso ficará sobrecarregado com sessões em andamento enquanto outros permanecerem ociosos. Com outros algoritmos, há uma probabilidade de que um único recurso acabe mantendo muitas sessões de usuário ao mesmo tempo, o que tem um impacto negativo no desempenho de todos os usuários direcionados a esse servidor.

Balanceamento de carga baseado em host

Servidores Virtuais

O balanceamento de carga baseado em host é um dos padrões de escalabilidade mais comuns e amplamente suportados. Você pode pensar que não precisa de um balanceador de carga para implementar isso, já que todos os servidores web suportam a capacidade de se mascarar como múltiplos hosts ao mesmo tempo. Mas você faz. Embora um servidor web/aplicativo possa hospedar vários servidores virtuais, ele não necessariamente faz balanceamento de carga entre eles. Então você ainda precisa de um balanceador de carga para escalar. A questão é: o balanceador de carga dividirá os hosts ou você deixará isso para o servidor web/de aplicativo?

Seja usando diretivas de servidor web/aplicativo ou um balanceador de carga externo, o fluxo permanece o mesmo. Uma solicitação é feita e recebida pelo destino (balanceador de carga ou servidor web/aplicativo). O servidor de destino então inspeciona os cabeçalhos HTTP e encontra o valor do host antes de direcionar a solicitação ao servidor virtual apropriado. 

O benefício de usar um balanceador de carga para dividir hosts está na capacidade de permitir o isolamento de domínios com base no host e dimensioná-los individualmente. Isso é mais eficiente e pode reduzir o número de servidores (hardware e software) necessários para dimensionar um aplicativo. Isso também facilita o planejamento de capacidade, pois você pode prever melhor qual carga cada servidor host pode suportar em um determinado momento.

Isso ocorre porque invocar a lógica de negócios não é o mesmo em termos de computação necessária do que solicitar uma imagem. Misturar e combinar hosts no mesmo domínio de escalabilidade resulta em carga volátil e capacidade imprevisível. Se você optar por usar um balanceador de carga para fornecer balanceamento de carga simples, o servidor web/de aplicativo será responsável por dividir os hosts e direcionar as solicitações para o servidor virtual apropriado. Outras desvantagens dessa abordagem são a natureza da infraestrutura compartilhada, com conflitos de versão e patches, bem como atualizações de aplicativos, que podem causar atrito entre servidores virtuais.

A crescente adoção de contêineres e microsserviços está impulsionando o uso de balanceamento de carga baseado em host na forma de controladores de entrada .

Rota e Retorno 

Balanceamento de carga da camada 7 (HTTP)

O balanceamento de carga da Camada 7 (HTTP) é meu favorito devido à versatilidade (agilidade?) que oferece. Você pode balancear a carga de solicitações com base em qualquer coisa HTTP – incluindo a carga útil. A maioria das pessoas (inteligentemente, na minha opinião) restringe suas regras de balanceamento de carga ao que pode ser encontrado no cabeçalho HTTP. Isso inclui o host, o método HTTP, o tipo de conteúdo, os cookies, os cabeçalhos personalizados e o agente do usuário, entre outros.

O balanceamento de carga HTTP é primeiramente sobre roteamento e depois sobre balanceamento de carga. Um padrão típico de balanceamento de carga HTTP assume a forma de rota –> distribuir. Isso significa que primeiro é tomada uma decisão sobre qual servidor virtual uma solicitação deve ser direcionada e, então, um algoritmo seleciona um recurso do pool que dá suporte a esse servidor virtual.

O balanceamento de carga HTTP permite padrões como o controle de versão da API, em que a versão da API é incorporada no URI (ou em um cabeçalho HTTP personalizado). O balanceador de carga é capaz de separar versões e garantir que os clientes sejam enviados ao serviço de back-end correto para execução. Essa migração sempre elegante de clientes em situações em que você não pode forçar a atualização.

Esse tipo de padrão de escalabilidade também oferece suporte a outros padrões de escalabilidade, como decomposição funcional e particionamento de dados. É o padrão de escalabilidade mais robusto e ágil do mix e permite uma vasta gama de opções ao dimensionar aplicativos e, cada vez mais, microsserviços.

Então, para resumir, temos cinco padrões principais de escalabilidade, a maioria dos quais pode ser (e geralmente é) combinada para permitir o uso mais eficiente dos recursos e o melhor desempenho possível. Provavelmente, se você não estiver usando um deles agora, você estará, então entender sua composição básica é uma boa base para construir uma arquitetura escalável, não importa que tipo de aplicativo você esteja usando - ou onde você os tenha implantado.

Aumente a escala!