Aplicações nativas da nuvem estão sendo desenvolvidas em ritmo acelerado. Embora ainda não dominem os portfólios de aplicações, elas estão se tornando cada vez mais numerosas. O interesse em contêineres está intimamente associado às arquiteturas nativas da nuvem (baseadas em microsserviços), devido à dependência inerente da infraestrutura para comunicação e escalabilidade.
Normalmente, o escalonamento de microsserviços é feito por meio de clonagem horizontal. Ou seja, se precisarmos de mais instâncias de um determinado serviço, basta cloná-lo e adicioná-lo ao pool disponível, do qual um balanceador de carga seleciona uma instância para responder às solicitações. Simples assim. Quando esses microsserviços representam fielmente elementos funcionais, esse modelo funciona ainda melhor.
O balanceador de carga em questão geralmente é um componente do orquestrador de contêineres e, por padrão, utiliza o algoritmo baseado em TCP de round robin, que é o padrão do setor. Isso significa que, quando uma solicitação chega, o balanceador de carga escolhe o próximo recurso da fila para responder.
Esse método é frequentemente comparado à fila de um banco ou do Detran. Mas essa comparação não é totalmente precisa. Em um verdadeiro cenário de round robin, você não é direcionado ao recurso "disponível mais próximo". Você é direcionado ao "próximo da fila" — mesmo que esse recurso esteja ocupado. Ironicamente, os métodos de distribuição do Detran e do seu banco local são mais eficientes do que um verdadeiro algoritmo round robin.
Pois é, né?
Isso também se aplica às aplicações. Um mesmo serviço — até mesmo no nível funcional — pode ser clonado porque as instâncias atendem ao mesmo conjunto de solicitações. No entanto, essas solicitações nem sempre são equivalentes em termos de execução por causa dos dados. Isso mesmo: os dados. Uma mesma solicitação funcional — ou chamada de API — pode levar mais ou menos tempo para ser executada, dependendo dos dados enviados ou solicitados. Afinal, recuperar e serializar o registro de um único cliente leva menos tempo do que recuperar e serializar dez ou cem registros de clientes.
E é aí que o round robin deixa um pouco a desejar e introduz uma variabilidade que pode afetar o desempenho. O axioma operacional nº 2 ainda se aplica a arquiteturas nativas da nuvem e baseadas em microsserviços: à medida que a carga aumenta, o desempenho diminui.
O round robin é como o ratel: não está nem aí se um recurso está ficando sobrecarregado por solicitações cujas respostas contêm grandes conjuntos de dados. O round robin diz "você é o próximo", esteja você pronto ou não. Isso pode resultar em um desempenho irregular para os usuários cujas solicitações acabam em uma fila em um recurso cada vez mais sobrecarregado.
Se você está preocupado com o desempenho — e deveria estar —, uma alternativa melhor é praticamente qualquer um dos outros algoritmos padrão, como o de menor número de conexões ou o de menor tempo de resposta. Basicamente, o ideal é que seu algoritmo leve em consideração a carga e/ou a velocidade, em vez de simplesmente encaminhar solicitações às cegas para recursos que talvez não sejam a melhor opção.
O futuro do balanceamento de carga
Alguns podem pensar que, à medida que avançamos na pilha de TCP para HTTP e HTTP+, esse problema se resolverá por conta própria. Mas não é nada disso. O método de distribuição — o algoritmo de balanceamento de carga — continua sendo relevante, independentemente da camada em que se baseia. O round-robin não se importa com a arquitetura, mas sim com os recursos, e toma decisões com base em um pool disponível. Para o algoritmo, não faz diferença se esse pool se destina a escalar uma única chamada de API ou um monólito inteiro.
Portanto, seria bom se o balanceador de carga fosse inteligente o suficiente para reconhecer quando uma consulta resultaria em uma quantidade de dados "acima da média" antes de ser executada. Firewalls de aplicações web como o F5 WAF conseguem reconhecer quando um resultado está fora do comum — mas isso ocorre na resposta e serve principalmente para reforçar a segurança da aplicação. O que precisamos é que o balanceador de carga seja inteligente o suficiente para prever uma resposta legítima "extragrande".
Se o balanceador de carga fosse capaz desse tipo de discernimento, poderia levar isso em consideração na tomada de decisões e distribuir as solicitações de maneira mais uniforme entre os recursos disponíveis. O que realmente queremos é não ter que especificar um algoritmo rígido para a tomada de decisões. Seria melhor se o balanceador de carga pudesse tomar a decisão com base em limites de negócios e características técnicas, como tempos de resposta, tempo de execução previsto, volume de dados retornados e a carga de cada recurso neste exato momento.
Em última análise, esse é o tipo de inteligência que só pode ser alcançado por meio de maior visibilidade e aprendizado de máquina. Se o balanceador de carga puder aprender com a experiência a reconhecer quais consultas levam mais tempo do que outras, ele poderá aplicar esse conhecimento para distribuir melhor as solicitações, de modo a alcançar um tempo de resposta consistente e previsível.
O balanceamento de carga não vai desaparecer. Ele é a nossa melhor resposta técnica para escalar tudo, desde a rede até as aplicações. Mas precisa evoluir junto com o restante da infraestrutura para se tornar mais dinâmico, autônomo e inteligente.
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...