Em aplicações modernas, os problemas de capacidade não são medidos apenas por contagem de requisições. Downloads grandes de arquivos, streaming de vídeo, exportações de API, tráfego de backup ou extração em massa de dados por bots podem consumir alta largura de banda mesmo em taxas baixas de requisições. Nesses casos, um limite de taxa de requisições por si só não é suficiente.
Em ambientes multi-tenant o problema fica mais visível. Quando um tenant executa uma transferência pesada de dados, a latência para outros tenants pode aumentar. Sem um limite de capacidade entre clientes que compartilham o mesmo vService, uma política de uso justo não pode ser tecnicamente aplicada.
O traffic shaping convencional tipicamente requer estruturas complexas de fila e classe no nível de rede. Esse modelo é poderoso, mas trabalhar diretamente com sinais L7 como path, tenant, usuário, claims JWT ou IP de origem na camada de entrega de aplicação é difícil. O debug e o gerenciamento de mudanças para equipes de operações também ficam mais pesados.
A abordagem correta é aplicar um teto de largura de banda baseado em conexão e chave no nível do ADC. Limites diferentes devem ser definíveis para um vService, usuário, tenant ou grupo de tráfego suspeito, e as direções de upload e download devem ser gerenciáveis independentemente.
O Traffic Shaping e QoS por vService do TR7 controla o consumo de largura de banda na camada de entrega de aplicação com os modos stream, por chave e compartilhado.
O TR7 aplica controle de largura de banda como uma política de três modos em vService, chave de tráfego e compartilhamento em alta disponibilidade.
O tráfego de upload de clientes para o backend e o tráfego de download do backend para clientes podem ser limitados separadamente para cada vService. Isso coloca a capacidade da aplicação sob controle no nível de serviço.
No modo stream, cada conexão opera sob seu próprio teto de largura de banda. O consumo de recursos de uma única conexão pode ser limitado em downloads, uploads ou streams de longa duração no estilo WebSocket.
No modo por chave, o limite é aplicado de acordo com uma chave produzida por uma expressão FX. IP de origem, usuário, ID de tenant ou um valor de claim JWT podem todos servir como chave de largura de banda.
No modo compartilhado, o orçamento de largura de banda em uma configuração de dois nós não está confinado a um único dispositivo. Um limite total para o mesmo tenant ou serviço pode ser aplicado de forma mais consistente no nível do cluster.
O traffic shaping transforma limites de largura de banda por conexão, por chave e compartilhados em uma política no nível de vService.
O modo stream aplica um teto separado a cada conexão. O modo por chave aplica um limite compartilhado em um IP, usuário, tenant ou qualquer outra chave FX. O modo compartilhado ajuda o mesmo limite a ser distribuído entre nós em uma configuração de alta disponibilidade. Um único recurso cobre, portanto, limitação simples de conexão, gerenciamento de cota de tenant e controle de capacidade compartilhada em todo o cluster.
Em alguns serviços o tráfego de download é dominante; em outros, o upload consome capacidade crítica. O TR7 pode limitar a direção de upload de clientes para o backend e a direção de download do backend para clientes separadamente. Por exemplo, o upload pode ser mais controlado em um serviço de upload de arquivos enquanto o download é mais restrito em um serviço de vídeo. Essa separação alinha a política de largura de banda com o comportamento real do tráfego.
No modo por chave, a chave de largura de banda é construída usando o mecanismo de expressões FX. IP de origem, informações de usuário JWT, ID de tenant, um valor de header ou qualquer combinação desses pode servir como chave. Por exemplo, todos os usuários pertencentes ao mesmo tenant podem compartilhar um teto de capacidade comum. Esse é um mecanismo poderoso para aplicação de uso justo em modelos SaaS multi-tenant.
No modo por chave, cada chave é rastreada como um estado de uso separado. Chaves que ficaram silenciosas por um período definido são removidas; chaves ativas permanecem sujeitas à política de limite. Esse modelo fornece controle de capacidade centralizado para milhares de usuários ou tenants. O operador aplica limites contra um proprietário lógico de tráfego em vez de conexões individuais.
Em configurações ativo-ativo ou ativo-passivo, o tráfego pode ser distribuído entre dois nós. O modo compartilhado ajuda o orçamento de largura de banda a ser aplicado como um comportamento de serviço compartilhado em vez de estar confinado a um único nó. Quando um tenant se move de um nó para o outro, a lógica de limite não é perturbada. Isso é particularmente importante para SLA empresarial e cenários de cota.
As regras de traffic shaping podem operar condicionalmente. Um tenant premium pode ser ilimitado, um tenant gratuito limitado a 100 Kbps e um IP suspeito restrito a 1 Mbps. As condições podem ser construídas a partir de path, usuário, header, claim JWT, IP de origem ou qualquer expressão FX. A política de largura de banda não é mais uma única configuração global.
Diferentes fatias de tráfego dentro do mesmo vService podem ter diferentes regras de limite. Por exemplo, o path `/download` pode ter seu próprio limite, `/api/export` outro e chamadas de API padrão ainda outro. Isso divide o controle de capacidade em segmentos alinhados ao comportamento da aplicação. O operador aplica shaping sensível ao contexto em vez de um único teto abrangente.
Conexões WebSocket, download de arquivo grande ou de streaming de longa duração podem contornar os limites clássicos baseados em requisições. O modo stream aplica um teto de largura de banda a cada um desses fluxos. Uma única conexão longa é impedida de esgotar a capacidade do serviço. Esse modelo é importante para cenários de mídia, transferência de arquivos e streaming em tempo real.
Os limites de largura de banda podem ser atualizados por meio de uma mudança de configuração. Novos limites são aplicados ao tráfego de produção de forma controlada. Isso permite resposta rápida durante campanhas, eventos suspeitos de DDoS, mudanças de cota de tenant ou restrições temporárias de capacidade. As equipes de operações não precisam aguardar uma mudança em um dispositivo de rede separado.
No modo por chave, o estado de uso de cada usuário, IP ou tenant pode ser observado. O operador pode ver qual chave está se aproximando de seu teto de cota. Essa informação é valiosa para suporte ao cliente, análise de segurança e planejamento de capacidade. Eventos de violação de limite podem ser conectados a logs e pipelines de SIEM.
Nem todo fluxo suspeito precisa ser bloqueado imediatamente. O TR7 pode aplicar um limite baixo de largura de banda a IPs, ASNs, paths ou grupos de comportamento suspeitos. Isso reduz o impacto de um ataque enquanto evita um corte completo de usuários legítimos em situações de falso positivo. A abordagem se encaixa em um modelo de defesa gradual.
Esse recurso não é um sistema complexo de fila no nível de rede ou um mecanismo de hardware QoS. O TR7 aplica um teto de largura de banda no nível de conexão e fluxo. Esse limite é simples de gerenciar no nível de vService, chave e condição. O operador define claramente quanta capacidade cada serviço ou usuário recebe.
O traffic shaping deve ser planejado junto com modo de limite, design de chave, direção de upload e download, fluxos de longa duração, compartilhamento em cluster e visibilidade de auditoria.
O modo stream é adequado para limites por conexão, o modo por chave é adequado para limites por usuário ou por tenant, e o modo compartilhado é adequado para um limite comum em todo o cluster. Escolher o modo errado pode quebrar o comportamento esperado de capacidade. O objetivo da política deve ser esclarecido primeiro.
A chave usada no modo por chave determina a quem o limite realmente pertence. O IP de origem é suficiente em alguns ambientes; informações de tenant ou usuário podem fornecer um modelo de cota mais preciso. Para múltiplos usuários atrás de NAT, o IP sozinho pode não ser justo.
As direções de upload e download têm impactos diferentes nos recursos. Grandes uploads de arquivo consomem capacidade de ingresso do backend; downloads consomem capacidade de egresso. Essas duas direções devem ser limitadas separadamente.
Conexões WebSocket, stream e de transferência de arquivo grande podem permanecer abertas por um período prolongado. Os limites por conexão tornam o consumo de recursos mais previsível nesses fluxos. As configurações de timeout e limite de largura de banda devem ser avaliadas juntas.
O modo compartilhado pode ser usado para comportamento de orçamento comum em configurações de dois nós. O objetivo é que a política de limite permaneça consistente à medida que a distribuição de tráfego muda entre os nós. Esse comportamento é importante para SLAs críticos de tenant.
Chaves que atingem um limite de threshold podem ser registradas. Alertas no SIEM podem ser configurados para violações de cota por tenant, por usuário ou por IP. Essa informação é útil tanto para operações de segurança quanto para suporte ao cliente.
Em um ambiente SaaS multi-tenant, um teto de capacidade separado pode ser definido para cada tenant. O ID do tenant é usado como chave, e todos os usuários pertencentes ao mesmo tenant compartilham o limite comum.
Um limite de largura de banda maior pode ser dado a clientes premium e um menor a usuários gratuitos. A diferença de tier é gerenciada na política do ADC sem incorporar lógica no código da aplicação.
Diferentes níveis de qualidade em serviços de vídeo ou mídia requerem larguras de banda diferentes. O TR7 pode aplicar um teto de download com base no path ou no tier de assinatura do usuário.
Durante um evento suspeito de DDoS ou bot, o tráfego pode ser colocado sob um limite baixo de taxa em vez de ser cortado completamente. Isso reduz o impacto do ataque enquanto evita uma desconexão completa para usuários reais em casos de falso positivo.
Chamadas de API internas podem ser deixadas sem limite enquanto o tráfego da internet é limitado. A separação é feita centralmente usando condições de IP de origem, path ou header.
Certos endpoints podem receber picos repentinos de tráfego durante campanhas de e-commerce. O TR7 aplica um teto temporário de largura de banda a APIs de checkout ou campanha para manter a estabilidade do serviço.
Mova o gerenciamento de largura de banda para o ADC. Estabeleça políticas de capacidade com os modos stream, por chave e compartilhado — sem appliance de rede separado ou arquitetura de fila complexa.