Consequências não intencionais: proxies sob carga

Ecossistema F5 | 18 de janeiro de 2016

Hoje em dia, a necessidade de escalabilidade nem sequer está em discussão. A resposta é sempre sim: você precisa dela. O crescimento dos negócios depende do crescimento operacional das aplicações que, afinal, são parte integrante dos modelos de negócios atuais, independentemente do setor. Por isso, os sistemas geralmente são implantados com os recursos necessários para alcançar essa escala quando — e não se — ela for necessária. Isso normalmente significa usar um proxy. Portanto, os proxies responsáveis pela escalabilidade (geralmente um balanceador de carga) são componentes essenciais em qualquer arquitetura moderna.

Não é apenas que esses proxies funcionam como mecanismo de escalabilidade; cada vez mais, espera-se que façam isso de forma automática, graças às maravilhas do auto-scaling. Essa simples palavra hifenizada implica muita coisa, como a capacidade de instruir programaticamente um sistema não só a disponibilizar capacidade adicional, mas também a garantir que o proxy responsável pela escalabilidade saiba da existência dessa nova capacidade e consiga direcionar solicitações a ela.

Presume-se que qualquer proxy que se preze tenha as interfaces programáticas necessárias. Afinal, a economia de APIs não se resume ao compartilhamento entre aplicativos e pessoas; ela também envolve o compartilhamento entre sistemas — locais e externos, na nuvem. Mas o que muitas vezes não percebemos é que a tarefa de adicionar um novo recurso a um proxy de balanceamento de carga ocorre no plano de gerenciamento ou de controle, e não no plano de dados.

gerenciamento fora de banda versus gerenciamento em banda

Faz sentido. Não queremos interferir no funcionamento do sistema enquanto coletamos estatísticas ou alteramos sua configuração. Isso é algo que deve ser evitado, especialmente quando estamos tentando aumentar a capacidade porque o sistema está operando a todo vapor, entregando aplicativos a usuários ansiosos.

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

Seu escalonamento automático (ou manual, nesse caso) vai falhar. Isso significa que a capacidade do aplicativo não aumentará, e a empresa sofrerá as consequências.

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

Isso acontece porque muitos proxies (que não foram desenvolvidos levando esse paradoxo em consideração) compartilham recursos do sistema entre os planos de controle e de dados. Não há isolamento entre eles. A mesma rede que disponibiliza os aplicativos é usada para gerenciar o proxy. A mesma memória RAM e a mesma capacidade computacional alocadas para disponibilizar os aplicativos também são usadas para gerenciar o proxy. Sob carga, apenas um desses dois recebe os recursos. Se você estiver tentando adicionar recursos de aplicativos ao proxy para aumentar a capacidade e não conseguir acessar o sistema para fazer isso, estará em sérios apuros.

Por isso, é importante avaliar a escolha dos proxies levando em conta a capacidade de gerenciamento. Não apenas a facilidade de gerenciamento. Não apenas a API e os recursos de criação de scripts, mas a capacidade de gerenciamento sob carga. Os proxies projetados especificamente para operar em grande escala devem ter um conjunto separado de recursos designados como recursos de “gerenciamento”, garantindo que, por mais sobrecarregado que esteja o plano de dados com a entrega de aplicativos, ainda seja possível gerenciá-lo e monitorá-lo.

No mundo das redes, chamamos isso de gerenciamento fora de banda, pois ele ocorre fora do caminho de dados — o caminho principal, o caminho crítico.

A capacidade de gerenciar um proxy sob carga, fora de banda, é importante para a capacidade geral de escalar — de forma automática ou manual — os aplicativos e, por meio deles, os negócios.

Compartilhar
Tags: 2016

Sobre o autor

Lori Mac Vittie
Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

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 Vittie

Publicaçõ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
Ecossistema F5 | 21/10/2026

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
Ecossistema F5 | 10/12/2020

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
Ecossistema F5 | 08/10/2018

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
Ecossistema F5 | 17/04/2017

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
Ecossistema F5 | 11/06/2015

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
Ecossistema F5 | 08/06/2015

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...