Balanceamento de carga. É amplamente aceito que precisamos dele, dependemos dele e o utilizamos todos os dias para aumentar (e, espera-se, reduzir) a escala das aplicações. Ele se tornou uma infraestrutura crítica, responsável não apenas por ajustar a escala para atender à demanda, mas também por garantir a disponibilidade contínua das aplicações e dos serviços dos quais as empresas dependem tanto para a produtividade quanto para a lucratividade.
É por isso que precisamos rever essa questão. O balanceamento de carga não deveria ser tratado de forma tão tática como vem sendo cada vez mais pela equipe de operações, que agora, na maioria das vezes, precisa provisionar, configurar e implantar esses serviços quase mágicos. Quando considerado de forma estratégica, o balanceamento de carga pode melhorar o desempenho, reduzir riscos e ajudar a usar com mais eficiência os recursos necessários para disponibilizar aplicações. Essas soluções são mais inteligentes do que sugere o rótulo de “encanamento” que muitas vezes lhes é imposto, e compreender alguns pontos-chave ajudará a equipe de operações a refletir melhor sobre como está usando o balanceamento de carga para dar suporte às aplicações.
Então, sem mais delongas, aqui estão três coisas que a equipe de operações realmente precisa saber sobre balanceamento de carga.
1. Os algoritmos são relativos
Eu começaria dizendo que round robin é o último algoritmo que você deveria mencionar, mas você já sabia disso, certo? Então vamos deixá-lo de lado e abordar algoritmos mais inteligentes, como o de menor número de conexões e o de menor tempo de resposta. Essas são, obviamente, opções muito melhores ao definir uma estratégia para equilibrar o desempenho com o uso eficiente dos recursos. Cada uma leva em consideração características da aplicação (ou, pelo menos, das plataformas que disponibilizam as aplicações) que são essenciais para decidir qual instância da aplicação (ou contêiner, se preferir) deve receber a próxima solicitação. O algoritmo de menor número de conexões pressupõe que, se uma instância tiver menos conexões, ela terá mais capacidade e, portanto, estará mais apta a atender à solicitação naquele momento. Ele prioriza a eficiência da capacidade em detrimento do desempenho.
Menor tempo de resposta, no outro extremo do espectro, significa optar por direcionar as solicitações com base no desempenho. Quanto mais rápida for a instância, maior será a frequência com que ela será selecionada. Considerando os axiomas operacionais (à medida que a carga aumenta, o desempenho diminui), isso significa que, em algum momento, um servidor menos sobrecarregado responderá mais rapidamente e, portanto, será escolhido. Embora isso leve em conta, até certo ponto, a eficiência da capacidade, esse algoritmo sempre prioriza o desempenho em detrimento da capacidade.
Mas agora observe os nomes dos algoritmos: menor número de conexões e menor tempo de resposta. Agora considere que, se duas tartarugas estiverem disputando uma corrida pela calçada, uma delas será mais rápida, mesmo que ambas estejam se deslocando a uma velocidade que todos chamaríamos de “lenta”. O mesmo vale para o menor número de conexões. Diante de uma escolha entre 99 e 100, 99 é definitivamente o menor dos dois.
Por que isso é importante
A forma como o balanceamento de carga gerencia as solicitações tem um impacto direto e imediato no desempenho e na disponibilidade. Ambas são características essenciais que, em última análise, afetam o engajamento dos clientes e a produtividade dos funcionários. A otimização de arquiteturas que incluem balanceamento de carga ajudará a garantir o sucesso dos negócios no alcance das metas de aumento da produtividade e dos lucros.
Aprofunde-se:
- De volta ao básico: a teoria da relatividade (de desempenho)
- De volta ao básico: o menor número de conexões não significa a menor carga
2. Falhar instantaneamente é (muitas vezes) um mito
Desde a ascensão da nuvem e dos data centers definidos por software, a elasticidade tornou-se a principal forma de escalar aplicações. A elasticidade exige aumentar — e reduzir — a capacidade sob demanda para otimizar o uso de recursos (e orçamentos). Por que superdimensionar a infraestrutura quando é possível simplesmente aumentar a capacidade sob demanda? Da mesma forma, as arquiteturas de alta disponibilidade (HA) baseadas nos princípios da redundância tornaram-se quase ultrapassadas. Por que manter recursos ociosos em espera para o caso (improvável) de a instância principal da aplicação falhar? Isso é um desperdício de orçamento de capital e operacional! Fora, fora, maldito standby!
Embora a recuperação de falhas e o escalonamento sob demanda sejam uma teoria atraente, na prática não é tão simples assim. A realidade é que até mesmo servidores virtuais (ou servidores em nuvem, ou qualquer outro termo que você prefira usar) levam tempo para serem iniciados. Se você (ou seu sistema automatizado) esperar até que o servidor principal falhe ou atinja sua capacidade máxima para iniciar outro, já será tarde demais. O planejamento de capacidade em ambientes de nuvem não pode se basear nos mesmos cálculos usados em ambientes tradicionais. Agora, os limites de capacidade precisam considerar tanto a taxa de consumo quanto o tempo necessário para iniciar outro servidor, a fim de acompanhar o aumento da demanda de forma transparente.
O mesmo vale para o failover. Se o servidor primário falhar, levará algum tempo para iniciar um substituto. Nesse intervalo, as pessoas perderão a conexão, enfrentarão tempos limite e provavelmente trocarão você por um concorrente ou pelo vídeo de gatos mais recente. Embora manter um servidor reserva ocioso possa parecer um desperdício (como um seguro), quando você precisar dele, ficará feliz por tê-lo à disposição. Em especial, se esse aplicativo for responsável pelo engajamento dos clientes ou pela geração de receita, o risco de até mesmo alguns minutos de indisponibilidade (e o custo decorrente) pode mais do que compensar o custo de manter um servidor reserva pronto para uso.
Curiosamente, os contêineres parecem ter o potencial de resolver esses problemas com tempos de inicialização extremamente rápidos. Se disponibilidade, desempenho e custo forem igualmente importantes, talvez seja hora de começar a explorar o valor que os contêineres podem oferecer para equilibrar esses três aspectos.
Por que isso é importante
O tempo de inatividade é dispendioso. A causa do tempo de inatividade não é tão importante quanto evitá-lo desde o início. Garantir que a arquitetura adequada e os planos de failover estejam implementados para lidar com falhas é essencial para manter a disponibilidade contínua, fundamental para o sucesso dos negócios.
Aprofunde-se:
3. O IP do cliente não é o IP real do cliente.
De todos os problemas que ocorrem quando um aplicativo passa do ambiente de desenvolvimento para o de produção, este é provavelmente o mais comum e o mais fácil de evitar. Acontece que a maioria dos serviços de balanceamento de carga (pelo menos todos os bons) funciona como proxy. Isso significa que o cliente se conecta ao proxy, e o proxy se conecta ao seu aplicativo. Ambos usam TCP para transportar esse HTTP, o que significa que precisam obedecer às regras de rede. O IP de origem (o que você considera ser o IP do cliente) é, na verdade, o endereço IP do proxy. Se você usa o endereço IP para fins de segurança, autenticação ou medição, isso representa um problema sério. O valor obtido do cabeçalho HTTP não é o que você procura.
O setor praticamente padronizou a forma de lidar com isso usando cabeçalhos HTTP personalizados. O cabeçalho X-Forwarded-For provavelmente é o que você realmente procura — é nele que um proxy insere o endereço IP real do cliente ao encaminhar as solicitações. Infelizmente, não se trata de um padrão oficial, mas sim de um padrão de fato, do tipo “todo mundo meio que concordou”, então você precisará confirmar.
A questão é que o endereço IP do cliente que você está procurando não é o que você pensa, portanto os desenvolvedores precisam levar isso em consideração antes que os aplicativos que precisam dessa informação sejam implantados em um ambiente de produção e, de repente, parem de funcionar.
Por que isso é importante para a empresa
A solução de problemas em produção é muito mais dispendiosa do que em ambientes de desenvolvimento ou teste. Tanto o tempo necessário para identificar quanto para corrigir o problema afeta negativamente os cronogramas dos projetos e atrasa o lançamento no mercado, que é essencial para a vantagem competitiva e o sucesso dos negócios em um mundo movido por aplicações. Reconhecer esse problema comum e resolvê-lo na fase de desenvolvimento ou teste pode garantir uma implantação em produção e um lançamento no mercado mais rápidos e sem contratempos.
Saiba mais:
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...