3 coisas que as operações precisam saber sobre balanceamento de carga
Balanceamento de carga. É comumente aceito que precisamos dele, confiamos nele e o usamos todos os dias para aumentar (e, com sorte, diminuir) as aplicações. Tornou-se uma infraestrutura crítica responsável não apenas por escalar para atender à demanda, mas também por garantir a disponibilidade contínua de aplicativos e serviços dos quais os negócios dependem para produtividade e lucro.
É por isso que é algo que precisamos revisitar. Porque o balanceamento de carga não deve ser tão tático quanto é cada vez mais tratado pelo pessoal de operações, que agora, com mais frequência, precisa provisionar, configurar e implantar esses serviços mágicos. O balanceamento de carga, quando visto estrategicamente, é capaz de melhorar o desempenho, reduzir riscos e ajudar a fazer uso mais eficiente dos recursos necessários para entregar aplicativos. Eles são mais inteligentes do que o apelido de "encanamento" que muitas vezes são forçados a suportar e entender alguns pontos-chave ajudará as operações a pensar mais sobre como estão usando o balanceamento de carga para dar suporte aos aplicativos.
Então, sem mais delongas, aqui estão três coisas que as operações realmente precisam saber sobre balanceamento de carga.
1. Algoritmos são relativos
Eu começaria mencionando que round robin é o último algoritmo que você deveria mencionar, mas você já sabia disso, certo? Então, vamos pular isso e abordar os algoritmos mais inteligentes, como menos conexões e tempo de resposta mais rápido . Essas são, é claro, escolhas muito melhores quando você cria estratégias para equilibrar o desempenho com o uso eficiente dos recursos. Cada um leva em consideração as características do aplicativo (ou pelo menos as características das plataformas que entregam os aplicativos) que são essenciais para tomar decisões sobre qual instância do aplicativo (ou contêiner, se preferir) deve receber a próxima solicitação. Menos conexões infere que se uma instância tiver menos conexões, ela terá mais capacidade e, portanto, estará mais apta a atender a essa solicitação agora. É escolher a eficácia da capacidade em vez do desempenho.
O tempo de resposta mais rápido , por outro lado, é escolher direcionar solicitações com base no desempenho. Quanto mais rápida a instância, mais frequentemente ela será selecionada. Sendo os axiomas operacionais o que são (conforme a carga aumenta, o desempenho diminui), isso significa que, eventualmente, um servidor menos sobrecarregado responderá mais rápido e, portanto, será escolhido. Embora isso signifique um aceno de cabeça em direção à eficácia da capacidade, esse algoritmo sempre escolhe o desempenho em vez da capacidade.
Mas agora observe os nomes do algoritmo: Menor e mais rápido . Agora considere que se duas tartarugas estão correndo pela calçada, uma delas é mais rápida, mesmo que ambas estejam viajando no que todos nós chamaríamos de velocidade "lenta". O mesmo vale para o menor número de conexões. Quando se tem a opção de escolher entre 99 e 100, 99 é definitivamente o menor dos dois.
Por que isso importa
A maneira como o balanceamento de carga gerencia solicitações tem um impacto direto e imediato no desempenho e na disponibilidade. Ambas são características críticas que afetam o envolvimento do cliente e a produtividade dos funcionários. Otimizar arquiteturas que incluam balanceamento de carga ajudará a garantir o sucesso empresarial na concretização de metas de maior produtividade e lucro.
Mergulho mais profundo:
- De volta ao básico: A Teoria da Relatividade (do Desempenho)
- De volta ao básico: Menos Conexões Não É Menos Carregado
2. Falhar instantaneamente é (frequentemente) um mito
Desde a ascensão da nuvem e dos data centers definidos por software, a elasticidade se tornou a maneira de dimensionar aplicativos. A elasticidade requer aumento e redução de escala sob demanda como um meio de otimizar o uso de recursos (e orçamentos). Por que provisionar em excesso quando você pode simplesmente aumentar a escala, conforme a demanda? Da mesma forma, as arquiteturas de alta disponibilidade (HA) dependentes dos princípios de redundância tornaram-se quase ultrapassadas. Por que exigir recursos ociosos em espera no (improvável) caso de falha da instância do aplicativo principal? Isso é um desperdício de capital e orçamentos operacionais! Fora, fora, malditos reserva!
Embora a falha e a escala sob demanda sejam uma bela teoria, na prática não é tão simples. A realidade é que até mesmo servidores virtuais (ou servidores em nuvem, ou qualquer termo que você preferir usar) levam tempo para serem iniciados. Se você (ou seu sistema automatizado) esperar até que o servidor primário falhe ou esteja no limite da capacidade antes de iniciar outro, já será tarde demais. O planejamento de capacidade em ambientes nublados não pode ser baseado na mesma matemática que funcionava em um ambiente tradicional. Os limites de capacidade agora precisam levar em consideração a taxa de consumo e o tempo necessário para iniciar outro servidor para dimensionar perfeitamente conforme a demanda.
E o mesmo vale para failover. Se o primário falhar, levará tempo para lançar um substituto. Época em que as pessoas estão perdendo conexões, perdendo tempo e provavelmente abandonando você por um concorrente ou pelo último vídeo de gato. Embora um pneu sobressalente ocioso possa parecer um desperdício (como um seguro) quando você realmente precisa dele, você ficará feliz por ele estar lá. Em particular, se esse aplicativo for responsável pelo engajamento do cliente ou pela receita, o risco de até mesmo alguns minutos de inatividade (e seu custo subsequente) pode mais do que compensar o custo de manter um sobressalente à mão.
Curiosamente, os contêineres parecem potencialmente resolver esses problemas com tempos de inicialização extremamente rápidos. Se disponibilidade, desempenho e custo são igualmente importantes, talvez seja hora de começar a explorar o valor que os contêineres podem trazer em termos de equilíbrio entre os três.
Por que isso importa
O tempo de inatividade é caro. A causa do tempo de inatividade não é tão importante quanto evitá-lo em primeiro lugar. Garantir que a arquitetura correta e os planos de failover estejam em vigor em caso de falha é fundamental para manter a disponibilidade contínua, essencial para o sucesso do negócio.
Mergulho mais profundo:
3. O IP do cliente não é o IP do cliente real .
De todos os problemas que ocorrem quando um aplicativo passa do desenvolvimento para a produção, este é provavelmente o mais comum e facilmente evitável. Veja, a maioria dos serviços de balanceamento de carga (pelo menos todos os bons) são proxies . Isso significa que o cliente se conecta ao proxy, e o proxy se conecta ao seu aplicativo. Ambos estão usando TCP para transportar esse HTTP, o que significa que ele tem que obedecer às leis de rede. O IP de origem (o que você acha que é o IP do cliente) é, na verdade, o endereço IP do proxy. Se você estiver fazendo segurança, autenticação ou medição com base no endereço IP, isso representa um problema sério. O valor que você extrai do cabeçalho HTTP não é o que você deseja.
O setor praticamente padronizou a forma de lidar com isso aproveitando os cabeçalhos HTTP personalizados. O cabeçalho X-Forwarded-For é provavelmente o que você realmente está procurando – é onde um proxy coloca o endereço IP real do cliente quando encaminha solicitações. Infelizmente, não é um padrão, é mais um padrão de fato do tipo "todos nós meio que concordamos", então você precisará verificar.
A questão é que o endereço IP do cliente que você está procurando não é o que você pensa que é e, portanto, os desenvolvedores precisam levar isso em consideração antes que os aplicativos que precisam dessas informações passem para um ambiente de produção e parem de funcionar de repente.
Por que isso é importante para o negócio
Solucionar problemas em produção é muito mais custoso do que em ambientes de desenvolvimento ou teste. Tanto o tempo para encontrar quanto para corrigir o problema impactam negativamente os cronogramas do projeto e impedem o tempo de colocação no mercado, tão crítico para a vantagem competitiva e o sucesso empresarial em um mundo de aplicativos. Reconhecer esse problema comum e resolvê-lo na fase de desenvolvimento ou teste pode garantir uma implantação mais rápida e perfeita na produção e no mercado.
Mergulho mais profundo: