Aplicativos e APIs de balanceamento de carga: Algoritmos versus Arquitetura

Na maioria dos casos, dimensionar aplicativos e APIs é praticamente a mesma coisa. Ambos exigem algum tipo de balanceador de carga – geralmente um proxy – e são necessários para distribuir solicitações em um pool de recursos.

Mas há uma diferença bastante significativa entre como essas solicitações são distribuídas entre os recursos. No caso de algoritmos, estamos realmente distribuindo carga, enquanto no caso de arquitetura, estamos direcionando carga. Agora, isso pode parecer uma distinção pedante que seria melhor deixar para a academia. A verdade é que a escolha entre algoritmos e arquitetura tem um impacto profundo na escala e no desempenho. Como ambos são o motivo pelo qual você usa o balanceamento de carga, a distinção se torna importante.

Balanceamento de carga simples e antigo

O balanceamento de carga baseado em algoritmos pode ser chamado apenas de balanceamento de carga ou, como eu gosto de chamar, balanceamento de carga simples e antigo . Este é o método de escala que usamos desde antes da virada do século. Sua idade não significa que deva ser abandonado; muito pelo contrário. Em muitas situações, o bom e velho balanceamento de carga é a melhor escolha para equilibrar escala e desempenho.

O bom e velho balanceamento de carga algorítmico usa, como se pode imaginar, algoritmos em seu processo de tomada de decisão. Isso significa que algoritmos de distribuição como round robin, menor número de conexões, resposta mais rápida e seus equivalentes ponderados são usados para selecionar um recurso para responder a qualquer solicitação.

Esta é uma decisão direta. Assim como o texugo-do-mel, os algoritmos não se importam com nada além de executar com base nos dados disponíveis. Se houver cinco recursos disponíveis, um desses cinco será selecionado com base no algoritmo. Período.

O balanceamento de carga baseado em algoritmos é, como você pode imaginar, bastante rápido. Não demora muito para usar o poder de processamento atual para executar o algoritmo apropriado e tomar uma decisão. Com exceção do round robin e de certos algoritmos de distribuição ponderada, os algoritmos são com estado. Isso significa que eles devem monitorar variáveis como "quantas conexões existem agora para os recursos A, B e C?" ou "Qual recurso respondeu mais rápido à sua última solicitação?" O balanceador de carga deve monitorar essas informações. Essas informações podem crescer bastante e exigir mais recursos para serem gerenciadas em ambientes que dimensionam aplicativos tradicionais e monolíticos que exigem múltiplas conexões de longa duração.

Onde o bom e velho balanceamento de carga se destaca é no dimensionamento de microsserviços. Isso porque cada microsserviço tem (ou deveria ter em uma arquitetura ideal) uma função. O dimensionamento desses serviços é facilmente obtido empregando um algoritmo básico (geralmente round robin), porque eles geralmente são equivalentes em capacidade e desempenho. Devido à natureza das arquiteturas de microsserviços, que podem exigir diversas chamadas de serviço para atender a uma única solicitação do usuário, decisões rápidas são essenciais. Isso faz com que o balanceamento de carga baseado em algoritmos básicos seja uma boa escolha para esses ambientes.

A regra básica é esta: se você estiver dimensionando serviços simples com um conjunto limitado de funções, todas elas geralmente equivalentes em termos de desempenho, então o bom e velho balanceamento de carga será suficiente. É isso que você vê dentro de ambientes de contêiner e o motivo pelo qual muitos dos recursos de dimensionamento nativos são baseados em algoritmos simples.  

Para outras aplicações e situações, você precisará recorrer ao balanceamento de carga baseado em arquitetura.

Balanceamento de carga HTTP

O balanceamento de carga baseado em arquitetura é a arte (sim, arte, não ciência) de usar um balanceador de carga para dividir e dividir solicitações de uma forma que corresponda à arquitetura do aplicativo que ele está dimensionando. O balanceamento de carga baseado em arquitetura tem mais a ver com direcionar o tráfego do que com distribuí-lo. Isso ocorre porque ele aproveita a Camada 7 (geralmente HTTP) para decidir para onde uma determinada solicitação precisa ir, e é por isso que tendemos a chamá-lo de balanceamento de carga HTTP (entre outros termos mais esotéricos (e focados em rede)). 

A capacidade de direcionar solicitações é cada vez mais importante em um mundo exposto por APIs e construído em microsserviços. Isso ocorre porque você precisa ser capaz de direcionar solicitações de API com base na versão, usar nomes de host ou caminhos de URI para despachar solicitações para microsserviços específicos ou para decompor a funcionalidade de um aplicativo.

A maioria das organizações deseja expor uma API consistente e fácil de usar. Seja para incentivar desenvolvedores cidadãos a criar novos aplicativos que usam a API ou para permitir que parceiros se conectem e integrem facilmente, uma API consistente e simples é essencial para garantir a adoção.

Mas as APIs costumam ser confusas na realidade. Eles são apoiados por vários serviços (geralmente microsserviços) e podem ser distribuídos entre locais. Eles raramente se limitam a um único serviço. As coisas são complicadas, pois eles são atualizados com mais frequência do que as gerações anteriores de aplicativos e não são compatíveis com versões anteriores de forma confiável. Além disso, os aplicativos móveis podem usar recursos antigos e novos – compartilhando imagens com aplicativos da web e usando as mesmas APIs que todos os outros.

Para dimensionar esses “aplicativos” e APIs, é necessária uma abordagem arquitetônica para balanceamento de carga. Você precisa direcionar o tráfego antes de distribuí-lo, o que significa usar um balanceador de carga compatível com a camada 7 (HTTP) para implementar padrões de arquitetura como despacho de URL, particionamento de dados e decomposição funcional. Cada um desses padrões é arquitetônico por natureza e requer uma afinidade maior com o design do aplicativo ou da API do que os aplicativos tradicionais.

O balanceamento de carga HTTP é cada vez mais importante na busca por dimensionar aplicativos, equilibrando eficiência com agilidade e também dando suporte a APIs. 

A escalabilidade requer ambos

Raramente você verá apenas um tipo de balança no mundo real. Isso ocorre porque as organizações cada vez mais oferecem um conjunto robusto de aplicativos que abrangem décadas de desenvolvimento, arquiteturas de aplicativos, plataformas e tecnologias. Muito poucas organizações podem se gabar de oferecer suporte apenas para aplicativos “modernos” (a menos que moderno inclua qualquer coisa que não seja executada em um mainframe).

Portanto, é provável que você veja – e use – balanceamento de carga algorítmico e arquitetônico para dimensionar uma variedade de aplicativos. É por isso que entender a diferença é importante, porque usar um quando o outro é mais apropriado pode resultar em desempenho ruim e/ou interrupções, nenhuma das quais é boa para os usuários, para os negócios ou para você. 

Você verá cada vez mais as duas abordagens combinadas para dimensionar aplicativos modernos. Às vezes, os dois realmente existirão como um único serviço projetado para dimensionar o lógico (a API) e o físico (o serviço real por trás da API). Os controladores de entrega de aplicativos (ADC) geralmente são a plataforma na qual uma abordagem combinada é implementada porque eles conseguem executar ambas com a mesma presteza.

Às vezes, elas são realizadas por dois sistemas diferentes. Por exemplo, em ambientes em contêineres, um controlador de entrada é responsável pelo balanceamento de carga arquitetônico, enquanto serviços internos nativos são geralmente responsáveis pela escala usando balanceamento de carga algorítmico.

Independentemente dos detalhes de implementação e implantação, a realidade é que tanto as abordagens algorítmicas quanto as baseadas em arquitetura para balanceamento de carga têm um papel a desempenhar no dimensionamento de aplicativos e APIs. A chave para maximizar seus pontos fortes a seu favor é adequar o balanceamento de carga à arquitetura do aplicativo.

Aumentar a escala.