Na maioria dos casos, escalar aplicativos e APIs é praticamente a mesma coisa. Ambos exigem algum tipo de balanceador de carga — geralmente um proxy — para distribuir as solicitações entre um conjunto de recursos.
Mas há uma diferença bastante significativa entre como essas solicitações são distribuídas entre os recursos. No caso dos algoritmos, estamos de fato distribuindo a carga, enquanto, no caso da arquitetura, estamos direcionando a carga. Isso pode parecer uma distinção preciosista, mais adequada ao meio acadêmico. A verdade é que a escolha entre algoritmos e arquitetura tem um impacto profundo na escalabilidade e no desempenho. Como ambos são, de certa forma, a razão pela qual se usa o balanceamento de carga, essa distinção se torna importante.
O bom e velho balanceamento de carga
O balanceamento de carga baseado em algoritmos pode ser chamado simplesmente de balanceamento de carga ou, como gosto de chamá-lo, Bom e Velho Balanceamento de Carga. Esse é o método de escalabilidade que usamos desde antes da virada do século. O fato de ser antigo não significa que deva ser abandonado; muito pelo contrário. Em muitas situações, o bom e velho balanceamento de carga é a melhor opção para equilibrar escalabilidade e desempenho.
Como se pode imaginar, o bom e velho balanceamento de carga algorítmico usa 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 que responderá a cada solicitação recebida.
Essa é uma decisão simples e direta. Assim como o ratel, 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 deles será selecionado com base no algoritmo. Ponto final.
O balanceamento de carga baseado em algoritmos é, como você pode imaginar, bastante rápido. Com o poder de processamento atual, não demora muito para executar o algoritmo adequado e tomar uma decisão. Com exceção do round robin e de determinados algoritmos de distribuição ponderada, os algoritmos mantêm estado. Isso significa que eles precisam acompanhar variáveis como “quantas conexões existem neste momento com os recursos A, B e C?” ou “Qual recurso respondeu mais rapidamente à última solicitação recebida?”. O balanceador de carga precisa acompanhar essas informações. Elas podem atingir um volume considerável e exigir mais recursos para serem gerenciadas em ambientes que escalam aplicações monolíticas tradicionais, que exigem várias conexões de longa duração.
O balanceamento de carga tradicional se destaca no dimensionamento de microsserviços. Isso ocorre porque cada microsserviço tem (ou deveria ter, em uma arquitetura ideal) uma única função. O dimensionamento desses serviços é facilmente realizado com o uso de um algoritmo básico (geralmente round robin), pois eles costumam ser equivalentes em capacidade e desempenho. Devido à natureza das arquiteturas de microsserviços, que podem exigir várias chamadas de serviço para atender a uma única solicitação do usuário, é essencial tomar decisões rápidas. Isso torna o balanceamento de carga básico baseado em algoritmos uma boa opção para esses ambientes.
A regra geral básica é a seguinte: se você estiver escalando serviços simples com um conjunto limitado de funções, todos geralmente equivalentes em termos de desempenho, o balanceamento de carga tradicional será suficiente. É isso que se vê dentro de ambientes de contêineres e é por isso que grande parte dos recursos nativos de escalabilidade se baseia em algoritmos simples.
Para outras aplicações e situações, será necessário recorrer ao balanceamento de carga baseado na 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 segmentar e distribuir solicitações de modo compatível com a arquitetura da aplicação que está sendo escalada. O balanceamento de carga baseado em arquitetura está mais relacionado ao direcionamento do tráfego do que à sua distribuição. Isso porque ele utiliza a Camada 7 (geralmente HTTP) para decidir para onde uma determinada solicitação deve ser encaminhada, razão pela qual costumamos chamá-lo de balanceamento de carga HTTP (entre outros termos mais esotéricos e voltados a redes).
A capacidade de direcionar solicitações é cada vez mais importante em um mundo exposto por APIs e baseado em microsserviços. Isso porque é necessário direcionar solicitações de API com base na versão, usar nomes de host ou caminhos de URI para encaminhar solicitações a microsserviços específicos ou decompor funcionalmente uma aplicação.
A maioria das organizações deseja disponibilizar uma API consistente e fácil de usar. Seja para incentivar desenvolvedores cidadãos a criar novos aplicativos que utilizem a API, seja para permitir que parceiros se conectem e façam integrações com facilidade, uma API simples e consistente é essencial para garantir sua adoção.
Mas, na prática, as APIs costumam ser complexas. Elas são sustentadas por vários serviços (muitas vezes, microsserviços) e podem estar distribuídas em diferentes locais. Raramente ficam restritas a um único serviço. Para complicar ainda mais, elas são atualizadas com mais frequência do que as gerações anteriores de aplicativos e nem sempre mantêm compatibilidade com versões anteriores. Além disso, os aplicativos móveis podem usar recursos antigos e novos, compartilhando imagens com aplicativos web e usando as mesmas APIs que todos os demais.
Para escalar esses “aplicativos” e APIs, é necessária uma abordagem arquitetural para o balanceamento de carga. É preciso 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 arquiteturais como roteamento de URLs, particionamento de dados e decomposição funcional. Cada um desses padrões é de natureza arquitetural e exige maior alinhamento com o design do aplicativo ou da API do que ocorre com aplicativos tradicionais.
O balanceamento de carga HTTP é cada vez mais importante para escalar aplicativos, equilibrando eficiência e agilidade, além de oferecer suporte a APIs.
A escalabilidade exige ambos
No mundo real, é raro encontrar apenas um tipo de escalabilidade. Isso ocorre porque as organizações oferecem cada vez mais um conjunto robusto de aplicações que abrange décadas de desenvolvimento, arquiteturas de aplicações, plataformas e tecnologias. Pouquíssimas organizações podem afirmar que oferecem suporte apenas a aplicações “modernas” (a menos que “moderno” inclua tudo o que não seja executado em um mainframe).
Assim, é provável que você veja — e use — tanto o balanceamento de carga algorítmico quanto o arquitetural para dimensionar diversos tipos de aplicações. Por isso, é importante entender a diferença, pois usar um quando o outro seria mais adequado pode resultar em baixo desempenho e/ou indisponibilidade, o que não é bom para os usuários, para os negócios nem para você.
Cada vez mais, você verá as duas abordagens combinadas para dimensionar aplicações modernas. Às vezes, ambas existirão como um único serviço projetado para dimensionar tanto a parte lógica (a API) quanto a física (o serviço propriamente dito por trás da API). Os Application Delivery Controllers (ADCs) geralmente são a plataforma na qual essa abordagem combinada é implementada, pois conseguem executar ambas as funções com a mesma agilidade.
Às vezes, essas funções são executadas por dois sistemas diferentes. Por exemplo, em ambientes conteinerizados, um controlador de ingresso é responsável pelo balanceamento de carga arquitetural, enquanto os serviços internos e nativos geralmente são responsáveis pelo dimensionamento por meio do 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 o balanceamento de carga desempenham um papel no dimensionamento de aplicativos e APIs. O segredo para aproveitar ao máximo os pontos fortes dessas abordagens é adequar o balanceamento de carga à arquitetura da aplicação.
Continue escalando.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...