Dimensionamento de infraestrutura: horizontal versus vertical, balanceamento de carga e escalonamento automático

A Netflix atende 260 milhões de assinantes em 190 países, escalonando dinamicamente milhares de instâncias com base na demanda em tempo real. Embora a maioria das empresas não opere na escala da Netflix, os princípios de escalonamento são os mesmos: combinar a capacidade da infraestrutura com a demanda de tráfego automaticamente, sem intervenção manual e sem pagar por recursos ociosos. As escolhas que você faz entre escalonamento horizontal e vertical, balanceadores de carga L4 e L7 e escalonamento automático reativo e preditivo determinam se sua plataforma cresce normalmente ou atinge um obstáculo.

Principais conclusões

• Inicie na vertical (máquinas maiores) para simplificar e depois mude para a horizontal (mais máquinas) quando precisar de alta disponibilidade ou exceder os limites de uma única máquina
• Os balanceadores de carga L7 fornecem roteamento baseado em conteúdo essencial para aplicativos modernos, enquanto os balanceadores L4 oferecem taxa de transferência bruta para distribuição TCP simples
• As políticas de escalonamento automático devem combinar gatilhos baseados em métricas (CPU, memória) com escalonamento preditivo para padrões de tráfego conhecidos
• O escalonamento de banco de dados segue regras diferentes do escalonamento de aplicativos – réplicas de leitura para cargas pesadas de leitura, particionamento para cargas pesadas de gravação

---

Dimensionamento horizontal versus vertical

A decisão fundamental de dimensionamento é aumentar as máquinas existentes (vertical) ou adicionar mais máquinas (horizontal). Cada abordagem tem compensações distintas.

Quando dimensionar verticalmente

A escala vertical é a primeira escolha certa por vários motivos. Não requer alterações de aplicativos, nenhuma configuração de balanceador de carga e nenhum gerenciamento de estado distribuído. Especialmente para bancos de dados, o escalonamento vertical evita a complexidade de fragmentação, atraso de replicação e transações distribuídas.

Escalar verticalmente quando:

• Seu aplicativo ainda não está sem estado (sessões armazenadas na memória, gravações no sistema de arquivos)
• Você está executando um único banco de dados e não atingiu os limites de conexão ou CPU
• O próximo tamanho da instância é mais barato que o tempo de engenharia para ir para a horizontal
• Você precisa escalar imediatamente, sem alterações arquitetônicas

Parar de escalar verticalmente quando:

• Você precisa de alta disponibilidade (instância única = ponto único de falha)
• A maior instância disponível não é suficiente
• Você está pagando pela capacidade máxima que fica ociosa 90% do tempo
• Você precisa de distribuição geográfica para latência

Quando dimensionar horizontalmente

O escalonamento horizontal exige que seu aplicativo não tenha estado – qualquer solicitação pode ser tratada por qualquer instância. Isso significa:

• Sessões armazenadas em Redis ou banco de dados, não na memória
• Uploads de arquivos armazenados no armazenamento de objetos (S3), não no disco local
• Nenhuma configuração específica da instância ou cache local sem replicação
• Tratamento elegante do encerramento de instâncias (verificações de integridade, drenagem de conexão)

Escalar horizontalmente quando:

• Alta disponibilidade é um requisito (sua empresa não pode tolerar minutos de inatividade)
• O tráfego é variável e o escalonamento automático pode economizar custos ao reduzir durante períodos de silêncio
• Você precisa implantar sem tempo de inatividade (implantações contínuas entre instâncias)
• Os requisitos de desempenho excedem a capacidade de uma única máquina

---

Aprofundamento do balanceamento de carga

Um balanceador de carga distribui o tráfego de entrada em vários servidores back-end. O tipo de balanceador de carga determina quais decisões de roteamento são possíveis.

Balanceamento de carga L4 (camada de transporte)

Os balanceadores de carga L4 operam no nível TCP/UDP. Eles roteiam conexões com base no endereço IP e na porta sem inspecionar o conteúdo dos pacotes. Eles são rápidos, simples e lidam com qualquer protocolo baseado em TCP.

Ideal para: Distribuição TCP bruta, proxy de conexão de banco de dados (PgBouncer), protocolos não HTTP, requisitos de rendimento extremamente altos

Limitações: Não é possível tomar decisões de roteamento com base no caminho do URL, cabeçalhos ou cookies. Não é possível encerrar o SSL (deve ser feito em backends).

Balanceamento de carga L7 (camada de aplicação)

Os balanceadores de carga L7 operam no nível HTTP. Eles inspecionam cabeçalhos de solicitação, URLs, cookies e até solicitam órgãos para tomar decisões de roteamento. Eles lidam com terminação e compactação SSL e podem modificar solicitações e respostas.

Ideal para: aplicativos Web, gateways de API, roteamento baseado em conteúdo, terminação SSL, testes A/B, implantações canário

Algoritmos de balanceamento de carga

Verificações de integridade e degradação graciosa

As verificações de integridade determinam se um servidor back-end deve receber tráfego. Configure-os com cuidado:

• Verificação de integridade superficial – uma simples verificação de conexão TCP ou HTTP 200 em um endpoint dedicado. Captura falhas no servidor, mas não falhas no nível do aplicativo.
• Verificação profunda de integridade – verifica a conectividade do banco de dados, a disponibilidade do Redis e a acessibilidade do serviço externo. Captura mais problemas, mas corre o risco de falsos negativos se uma dependência não crítica estiver inativa.
• Período de carência – novas instâncias precisam de tempo para aquecer (compilação JIT, preenchimento de cache). Defina um período de carência de inicialização antes que o balanceador de carga envie o tráfego completo.
• Drenando – ao remover uma instância, pare de enviar novas solicitações, mas permita que as solicitações existentes sejam concluídas (descarregamento da conexão). Normalmente 30-60 segundos.

---

Políticas de escalonamento automático

O escalonamento automático ajusta o número de instâncias com base na demanda, combinando a capacidade com o tráfego sem intervenção manual.

Dimensionamento baseado em métricas

A abordagem mais comum aciona ações de escalonamento quando uma métrica ultrapassa um limite.

Dimensionamento Preditivo

Se o seu tráfego seguir padrões previsíveis (picos diários, ciclos semanais, eventos sazonais), o escalonamento preditivo provisionará capacidade antes que o tráfego chegue. O AWS Auto Scaling oferece suporte ao dimensionamento preditivo que aprende com padrões históricos e é dimensionado de forma proativa.

Combine preditivo e reativo: use o escalonamento preditivo para padrões conhecidos (rampa de tráfego matinal, pré-provisionamento da Black Friday) e o escalonamento reativo para picos inesperados.

Práticas recomendadas de dimensionamento

1. Aumentar rapidamente, aumentar lentamente - adicione instâncias agressivamente (tempo de espera de 1 a 2 minutos), mas remova-as gradualmente (tempo de espera de 10 a 15 minutos) para evitar oscilações
2. Use várias métricas - dimensione a CPU OU a memória OU a contagem de solicitações, usando a primeira métrica que aciona
3. Defina limites mínimos e máximos – evite o escalonamento para zero (sem disponibilidade) ou o escalonamento indefinidamente (explosão de custos)
4. Teste o escalonamento durante os testes de carga – verifique se o escalonamento automático é acionado corretamente e se novas instâncias atendem o tráfego dentro do prazo esperado
5. Monitore eventos de escalabilidade – alerta sobre escalabilidade frequente para detectar problemas de configuração ou problemas subjacentes de desempenho

---

Estratégias de escalonamento de banco de dados

Os bancos de dados não são dimensionados horizontalmente da mesma forma que os servidores de aplicativos. As operações de gravação exigem consenso e uma forte consistência limita as opções de distribuição.

Ler réplicas

As réplicas de leitura copiam dados do banco de dados primário e atendem consultas de leitura. Eles dimensionam o rendimento de leitura linearmente, mas não ajudam no rendimento de gravação.

Considerações de implementação:

• Atraso na replicação – as réplicas são eventualmente consistentes. As consultas imediatamente após uma gravação podem não ver a alteração. Use o primário para leituras após gravações.
• Roteamento de conexão – seu aplicativo precisa de lógica para rotear leituras para réplicas e gravações para o primário. ORMs e proxies de conexão (ProxySQL, PgBouncer) podem automatizar isso.
• Failover – se o primário falhar, uma réplica poderá ser promovida. O failover automatizado (AWS RDS Multi-AZ, AWS Aurora) reduz o tempo de inatividade para segundos.

Particionamento de Tabela

Para cargas de trabalho com uso intenso de gravação em tabelas grandes, o particionamento divide uma tabela em partes físicas menores, mantendo uma única interface lógica. Para estratégias detalhadas de particionamento, consulte nosso guia de otimização de banco de dados.

Pool de conexões

As conexões de banco de dados são caras para criar e limitadas em número. Poolers de conexões, como conexões de pool PgBouncer de muitas instâncias de aplicativos em um número menor de conexões de banco de dados.

Sem pool: 20 instâncias de aplicativo x 20 conexões cada = 400 conexões de banco de dados (provavelmente excedendo os limites do PostgreSQL)

Com o PgBouncer: 20 instâncias de aplicativos se conectam ao PgBouncer, que mantém de 50 a 100 conexões com o PostgreSQL, multiplexando solicitações com eficiência.

---

Decomposição de microsserviços

Quando um monólito se torna grande demais para ser desenvolvido e implantado com eficiência por uma única equipe, a decomposição de microsserviços permite o dimensionamento independente de diferentes componentes.

Quando decompor

Não comece com microsserviços. Comece com um monólito bem estruturado e decomponha-se quando:

• Componentes diferentes têm requisitos de escala muito diferentes (a pesquisa precisa de 20 instâncias, a finalização da compra precisa de 5)
• Diferentes equipes precisam ser implantadas de forma independente, sem coordenação de cronogramas de lançamento
• Um componente específico precisa de uma pilha de tecnologia diferente (aprendizado de máquina em Python, API em Node.js)
• O tempo de implantação do monólito excede 30 minutos devido ao tamanho da base de código

O que extrair primeiro

---

Perguntas frequentes

Como posso saber quando preciso escalar?

Monitore quatro métricas principais: utilização da CPU (consistentemente acima de 70%), uso de memória (acima de 80%), tempo de resposta P95 (acima do seu SLO) e taxa de erros (acima de 0,1%). Quando qualquer métrica ultrapassa consistentemente seu limite, você precisa escalar. O monitoramento proativo com alertas detecta essas tendências antes que os usuários percebam. Consulte nosso guia de monitoramento.

O escalonamento automático ou o pré-provisionamento são mais econômicos?

O escalonamento automático é mais econômico para tráfego imprevisível porque você só paga pela capacidade quando precisa dela. O pré-provisionamento é melhor para picos previsíveis (Black Friday, picos diários) porque o escalonamento automático leva de 3 a 10 minutos para adicionar capacidade. A abordagem mais econômica combina ambos: pré-provisionamento para picos esperados, escalonamento automático para picos inesperados e uso de instâncias reservadas para sua capacidade de linha de base. Consulte nosso guia de otimização de custos de nuvem.

Devo usar contêineres (Docker/Kubernetes) ou VMs tradicionais?

Os contêineres iniciam mais rápido (segundos versus minutos), usam recursos com mais eficiência (maior densidade por host) e fornecem ambientes consistentes em desenvolvimento e produção. O Kubernetes adiciona orquestração (escalonamento automático, autocorreção, implantações contínuas), mas complexidade operacional significativa. Comece com serviços de contêiner gerenciados (AWS ECS, Google Cloud Run) antes de considerar o Kubernetes.

Como lidar com failover de banco de dados sem perda de dados?

Use replicação síncrona para failover com perda zero de dados – o primário não reconhece uma gravação até que a réplica a confirme. Isso adiciona latência de gravação (normalmente de 1 a 5 ms na mesma região), mas garante nenhuma perda de dados durante o failover. AWS RDS Multi-AZ e Aurora fornecem replicação síncrona gerenciada com failover automático.

---

O que vem a seguir

Avalie sua infraestrutura atual em relação às suas projeções de crescimento. Se você estiver executando um único servidor, certifique-se de que seu aplicativo esteja sem estado e pronto para escalabilidade horizontal. Se você já executa várias instâncias, otimize a configuração do balanceador de carga e implemente políticas de escalonamento automático.

Para obter a perspectiva completa da engenharia de desempenho, consulte nosso guia de pilares sobre escalonamento de sua plataforma de negócios. Para otimizar custos à medida que você escala, leia nosso guia sobre otimização de custos de nuvem.

A ECOSIRE projeta e implementa infraestrutura escalável para plataformas de negócios em AWS e ambientes multinuvem. Entre em contato com nossa equipe de DevOps para uma avaliação de dimensionamento de infraestrutura.

---

Publicado por ECOSIRE — ajudando empresas a escalar com soluções baseadas em IA em Odoo ERP, Shopify eCommerce e OpenClaw AI.