Consequências não intencionais: Proxies sob carga

A necessidade de escalabilidade nem é uma questão hoje em dia. A resposta é sempre sim, você precisa. O crescimento dos negócios depende do crescimento operacional dos aplicativos que são, afinal, parte integrante dos modelos de negócios atuais – não importa qual seja o setor. Portanto, os sistemas geralmente são implantados com as coisas necessárias para atingir essa escala quando – e não se – for necessário. Isso geralmente significa um proxy. E os proxies responsáveis pela escala (geralmente um balanceador de carga) são, portanto, componentes bastante críticos em qualquer arquitetura moderna.

Não é apenas que esses proxies servem como mecanismo de dimensionamento; é que eles são cada vez mais obrigados a fazer isso de forma automática e mágica por meio das maravilhas do dimensionamento automático. Essa palavra simples e hifenizada implica muita coisa; como a capacidade de instruir, programaticamente, um sistema a não apenas lançar capacidade adicional, mas também garantir que o proxy responsável pela escalabilidade saiba de sua existência e seja capaz de direcionar solicitações a ele.

Supõe-se que qualquer proxy que se preze tenha as interfaces programáticas necessárias. A economia de API não se trata apenas de compartilhamento entre aplicativos e pessoas, afinal, também se trata de compartilhamento entre sistemas – no local e fora dele, na nuvem. Mas o que muitas vezes deixamos de reconhecer é que a tarefa de adicionar um novo recurso a um proxy de balanceamento de carga ocorre no plano de gerenciamento ou controle, não no plano de dados.

Isso faz sentido. Não queremos interferir no funcionamento do sistema enquanto coletamos estatísticas ou manipulamos sua configuração. Isso é um não-não, especialmente em uma situação em que estamos tentando adicionar capacidade porque o sistema está funcionando a todo vapor, entregando aplicativos para usuários ansiosos.

Mas o que acontece quando ocorre o inverso? Quando a execução do sistema interfere na capacidade de gerenciá-lo?

Seu dimensionamento automático (ou dimensionamento manual, nesse caso) irá falhar. O que significa que a capacidade do aplicativo não vai aumentar e o negócio vai sofrer.

Isso é ruim, como se você precisasse que eu lhe dissesse isso.

O motivo pelo qual isso acontece é porque muitos proxies (que não foram criados com esse paradoxo em mente) compartilham recursos do sistema para os planos de controle e de dados. Não há isolamento entre eles. A mesma rede que entrega os aplicativos é usada para gerenciar o proxy. A mesma RAM e computação atribuídas para entregar aplicativos são atribuídas para gerenciar o proxy. Sob carga, apenas um desses dois obtém os recursos. Se você estiver tentando adicionar recursos de aplicativo ao proxy para dimensionar e não conseguir acessar o sistema para fazer isso, você estará em apuros.

É por isso que é importante avaliar sua escolha de proxies tendo em vista a gerenciabilidade. Não apenas pela facilidade de gerenciamento. Não apenas seus recursos de API e script, mas sua capacidade de gerenciamento sob carga . Proxies que foram projetados especificamente para escala massiva devem ter um conjunto separado de recursos designados como recursos de “gerenciamento” para garantir que, não importa o quão carregado o plano de dados esteja com aplicativos de entrega, ele ainda possa ser gerenciado e monitorado.

No mundo da rede, chamamos isso de gerenciamento fora de banda, porque ocorre fora do caminho de dados – o caminho primário; o caminho crítico.

A capacidade de gerenciar um proxy sob carga, fora de banda, é importante na capacidade geral de dimensionar – automática ou manualmente – os aplicativos e, por meio deles, os negócios.