TL;DR: o escalonamento horizontal adiciona instâncias de servidor para distribuir os workloads em vez de fazer upgrade de máquinas individuais. É a base de uma arquitetura de nuvem confiável e econômica para tráfego imprevisível, mas traz complexidade no gerenciamento de estado, no balanceamento de carga e na configuração do autoscaling — pontos que os times precisam planejar antes de esbarrar nos limites de capacidade.
Toda aplicação tem um teto. Por um tempo, dá para empurrar esse teto para cima com upgrades de hardware: mais CPU, mais RAM, storage mais rápido. Mas, em algum momento, um único servidor não dá conta, e o custo do upgrade supera o valor entregue. É aí que a decisão deixa de ser escalar verticalmente e passa a ser escalar horizontalmente.
Escalar horizontalmente — adicionar mais servidores para dividir a carga em vez de tornar um servidor cada vez maior — é a arquitetura por trás da maioria das aplicações modernas em nuvem. É assim que as aplicações absorvem picos de tráfego sem cair, que os times criam redundância sem heroísmos de engenharia e que os custos de infraestrutura se mantêm proporcionais à demanda real, e não a projeções de pior caso.
Este guia mostra como o escalonamento horizontal funciona, onde ele se encaixa e onde não, e como os times de CloudOps podem implementá-lo em AWS, Google Cloud e Kubernetes sem trocar confiabilidade por complexidade.
O que é escalonamento horizontal e como ele funciona?
Escalonamento horizontal significa adicionar mais instâncias de um recurso para distribuir os workloads entre múltiplos nós em vez de aumentar a capacidade de um único nó. Enquanto o escalonamento vertical faz upgrade de um único servidor (mais núcleos de CPU, mais memória), o horizontal multiplica o número de servidores que atendem às requisições. Um load balancer fica na frente da frota, distribuindo o tráfego de entrada entre as instâncias disponíveis para que nenhum nó vire gargalo.
A mecânica varia um pouco de uma plataforma para outra, mas o padrão se mantém. Na AWS, os Auto Scaling Groups monitoram métricas do CloudWatch e iniciam ou encerram instâncias EC2 automaticamente quando a utilização cruza os limites definidos. No Kubernetes, o Horizontal Pod Autoscaler (HPA) observa a utilização de CPU e memória (ou métricas customizadas) e ajusta o número de pods em execução. No Google Cloud, os Managed Instance Groups cumprem essa mesma função para workloads do Compute Engine. Em todos os casos, uma camada de controle cuida da decisão de escalonamento para que o time de engenharia não precise fazer isso na mão.
Quais são as implicações de performance e capacidade?
O escalonamento horizontal muda o modelo de capacidade de um teto fixo para uma faixa dinâmica. Um sistema escalado verticalmente bate em um limite duro quando o maior tipo de instância disponível não dá mais conta da carga. Um sistema escalado horizontalmente, bem configurado, consegue continuar adicionando instâncias até que a arquitetura ou o orçamento limitem o crescimento.
O ganho de performance se multiplica com a distribuição geográfica. Rodar instâncias em múltiplas zonas de disponibilidade significa que a falha de uma zona não derruba a aplicação — o tráfego desvia da zona afetada enquanto instâncias substitutas sobem. O trade-off é a latência entre nós: instâncias distribuídas que precisam se comunicar pagam um custo de round-trip de rede que uma configuração de servidor único evita, o que faz diferença em operações sensíveis à latência.
Como o escalonamento horizontal afeta custo e gestão de recursos?
O escalonamento horizontal alinha o custo da infraestrutura à demanda real com mais precisão do que o vertical. Um servidor escalado verticalmente roda no tamanho provisionado independentemente do tráfego. Uma frota escalada horizontalmente pode encolher fora dos horários de pico e expandir nos picos, pagando preços on-demand pela capacidade transitória e preços de reserva pela base previsível.
Esse alinhamento, porém, só se sustenta se as políticas de autoscaling estiverem bem ajustadas. Limites de scale-out mal configurados, que disparam cedo demais, ou políticas de scale-in que demoram para retirar instâncias transformam a vantagem de custo em desperdício. Preços baseados em commitments na frota de base (AWS Savings Plans, descontos de uso comprometido do GCP) combinados com capacidade de burst on-demand entregam o melhor perfil de custo para a maioria dos times.
Para workloads Kubernetes em específico, o right-sizing dos requests e limits dos pods é tão importante quanto a própria política de escalonamento. Pods com requests inflados travam a eficiência do bin-packing, ou seja, o cluster precisa de mais nós do que o workload de fato exige. O DoiT PerfectScale for Kubernetes revela essas oportunidades de right-sizing automaticamente, identificando onde os requests dos pods não refletem os padrões reais de uso.
Que complexidade operacional o escalonamento horizontal traz?
Mais instâncias significam mais superfície para gerenciar. Desvios de configuração, aplicação de patches em uma frota, agregação de logs e tracing distribuído ficam todos mais difíceis em escala do que em um único servidor. Times que não pensaram nisso descobrem rápido, seja quando um bug aparece em um tipo de instância e em outro não, seja quando logs de 40 pods precisam ser correlacionados para rastrear uma única requisição.
Ferramentas de infrastructure-as-code (Terraform, Pulumi, CloudFormation) são a mitigação básica. Padrões de infraestrutura imutável, em que as instâncias são substituídas a partir de uma imagem confiável em vez de modificadas no lugar, eliminam o desvio de configuração. Logs centralizados e tracing distribuído tornam o debug em múltiplas instâncias viável.
Como o escalonamento horizontal se compara ao vertical para times de CloudOps?
Escalonamento vertical (scaling up) e horizontal (scaling out) não são excludentes. A maioria das arquiteturas de produção usa os dois: instâncias bem dimensionadas para o workload, rodando dentro de uma frota escalada horizontalmente. O ponto de decisão é qual alavanca puxar primeiro quando a capacidade vira uma restrição.
O escalonamento vertical é mais rápido de implementar e não exige mudanças na aplicação. Você adiciona mais CPU e memória a uma instância existente, reinicia se for o caso, e pronto. Funciona bem para workloads difíceis de distribuir: processos single-threaded, aplicações com dependências de estado rígidas ou sistemas legados que não foram feitos para operação multi-instância. O teto é o maior tipo de instância disponível, e o custo não escala proporcionalmente à demanda.
O escalonamento horizontal exige que a aplicação esteja preparada. Serviços stateless, em que cada requisição carrega todo o contexto de que o servidor precisa e nenhum estado local persiste entre requisições, se distribuem bem em qualquer número de instâncias. Serviços stateful, em que a aplicação guarda dados de sessão ou estado em processo localmente, exigem arquitetura adicional para funcionar bem em uma frota.
O que torna as aplicações stateless ideais para o escalonamento horizontal?
Aplicações stateless são o encaixe natural para o escalonamento horizontal porque qualquer instância pode atender qualquer requisição. Um load balancer pode fazer round-robin do tráfego pela frota sem nenhuma lógica de roteamento além de checagens de disponibilidade. Quando o tráfego sobe, novas instâncias entram em operação e assumem carga na hora. Quando o tráfego cai, as instâncias são encerradas sem afetar nenhum estado em andamento.
A maioria das camadas modernas de aplicações web, das camadas de API e dos microsserviços é stateless por design. Uma API REST que lê de um banco de dados compartilhado não se importa com qual servidor processa a requisição. Um microsserviço containerizado que lê de uma fila e escreve resultados em object storage escala horizontalmente sem coordenação adicional, e o autoscaling mantém a capacidade proporcional à demanda sem intervenção manual.
Onde bancos de dados e workloads stateful criam desafios?
Bancos de dados e serviços stateful não escalam horizontalmente por padrão. Um banco relacional rodando em uma única instância primária não pode simplesmente ser replicado em cinco nós na esperança de aguentar cinco vezes o throughput de escrita. Leituras podem escalar horizontalmente via read replicas, mas as escritas ainda passam pelo primário, transformando workloads pesados em escrita em gargalo, independentemente de quantas réplicas existam.
Os times contornam isso particionando o estado em uma camada compartilhada — um banco de dados gerenciado, um cache distribuído como Redis ou um object store — que todas as instâncias acessam. Dados de sessão vão para o Redis ou o DynamoDB. Uploads de arquivos vão para o S3 ou o Cloud Storage. Essa arquitetura de estado compartilhado torna a camada da aplicação genuinamente stateless e ainda preserva os dados de que ela precisa.
No Kubernetes em específico, workloads stateful que precisam de armazenamento persistente usam StatefulSets em vez de Deployments. Os StatefulSets dão a cada pod uma identidade de rede estável e um persistent volume claim, o que importa para bancos de dados, filas e outros serviços stateful e ordenados.
Quando o escalonamento horizontal funciona e quando não funciona?
O escalonamento horizontal entrega seus benefícios em condições específicas: padrões de tráfego imprevisíveis ou com picos, camadas de aplicação stateless, microsserviços distribuídos e workloads em que os requisitos de disponibilidade exigem redundância. Em outros contextos, entrega menos valor — e, às vezes, cria problemas novos.
Workloads containerizados e microsserviços são o melhor encaixe. Cada serviço escala de forma independente com base em sua própria demanda, ou seja, um pico em uma parte do sistema não superprovisiona o resto. Um cluster Kubernetes rodando 20 microsserviços pode aplicar autoscaling em cada serviço de forma independente, mantendo alta utilização de recursos em todo o cluster em vez de dimensionar tudo para o pico de carga. O Kubernetes Horizontal Pod Autoscaler dá aos times controle granular sobre essas políticas de escalonamento, incluindo métricas customizadas além de CPU e memória.
Arquiteturas orientadas a eventos escalam particularmente bem na horizontal. Uma frota de workers consumindo de uma fila pode crescer e encolher conforme a profundidade da fila, processando rajadas sem atraso e liberando instâncias quando a fila esvazia. Ferramentas como o KEDA (Kubernetes Event-Driven Autoscaling) estendem esse padrão nativamente ao Kubernetes, escalando pods com base em fontes externas de eventos como o tamanho de uma fila SQS ou o lag de consumidores Kafka.
Quais decisões de balanceamento de carga e distribuição de tráfego mais importam?
O load balancer é o ponto de entrada de todo o tráfego para uma frota escalada horizontalmente, o que faz da sua configuração um fator direto no comportamento da aplicação. A distribuição round-robin funciona para serviços stateless em que todas as instâncias são equivalentes. O roteamento por least-connection funciona melhor quando o tempo de processamento das requisições varia muito, encaminhando novas conexões para a instância com mais capacidade disponível.
Os health checks são o eixo operacional. Um load balancer que manda tráfego para uma instância não saudável anula o sentido de rodar uma frota. Os health checks devem testar a prontidão real da aplicação (um endpoint HTTP real, que verifica se as dependências estão disponíveis), e não apenas se a instância responde a uma conexão TCP. Health checks mal configurados, que passam fácil demais ou são exigentes demais, causam flapping e eventos de scaling desnecessários.
Como o gerenciamento de sessão e a consistência de dados afetam o escalonamento horizontal?
O gerenciamento de sessão é onde muitas implementações de escalonamento horizontal quebram. Uma aplicação que guarda dados de sessão na memória local funciona bem em um único servidor. Distribuída em uma frota, a segunda requisição do mesmo usuário pode cair em uma instância diferente, sem conhecimento da sessão da primeira, causando falhas de autenticação ou perda do estado do carrinho.
A solução é externalizar o estado da sessão. Redis e Memcached são as escolhas padrão para armazenamento distribuído de sessões. A camada da aplicação se torna verdadeiramente stateless, lendo e escrevendo dados de sessão no cache compartilhado em vez da memória local. Todas as instâncias enxergam o mesmo estado de sessão, independentemente de qual delas processa a requisição. Isso adiciona um round-trip de rede a cada leitura de sessão — um trade-off razoável pela escalabilidade horizontal na maioria das aplicações.
A consistência de dados entre instâncias distribuídas exige atenção explícita de design para workloads pesados em escrita. Locking distribuído, controle de concorrência otimista ou padrões de event sourcing resolvem o problema de coordenação, dependendo dos requisitos de consistência.
Quais decisões de monitoramento e configuração de autoscaling determinam o sucesso?
Políticas de autoscaling valem o que valem as métricas que as guiam. A utilização de CPU é a métrica padrão da maioria dos serviços gerenciados de autoscaling, mas é um indicador atrasado para muitos workloads. Uma aplicação sob pressão de memória ou com backlog em fila pode mostrar utilização normal de CPU até quase o momento em que cai. Métricas customizadas (profundidade da fila de requisições, percentis de latência de resposta, contagem de conexões ativas) dão às políticas de autoscaling sinais mais precoces e precisos.
Políticas de scale-out devem ser agressivas — é melhor superprovisionar por pouco tempo do que deixar um pico de tráfego degradar a experiência do usuário. Políticas de scale-in devem ser conservadoras, com períodos de cooldown e decrementos graduais para evitar encerrar instâncias rápido demais depois de um pico. Uma frota que escala para baixo cedo demais durante um padrão de tráfego que oscila entre alto e normal vai ficar instável, ligando e desligando instâncias o tempo todo, e isso custa caro.
O guia de otimização de custos do Kubernetes detalha como alinhar a configuração de autoscaling à eficiência de custo, incluindo cotas de recursos por namespace e padrões de integração com VPA.
Como implementar padrões de escalonamento horizontal e evitar armadilhas comuns?
A implementação segue uma sequência consistente, independentemente da plataforma: validar que a aplicação é stateless, configurar o grupo de escalonamento, definir políticas e testar antes que o tráfego de produção dependa disso.
Na AWS, o stack é Auto Scaling Groups com instâncias EC2 (ou tasks ECS para workloads containerizados), um Application Load Balancer e alarmes do CloudWatch direcionando as políticas de escalonamento. As decisões críticas de configuração são o número mínimo e máximo de instâncias, a métrica-alvo de utilização e os períodos de cooldown de scale-in/scale-out. Para uma referência detalhada de configuração de EC2, o guia de custos, benefícios e melhores práticas do AWS EC2 cobre seleção de instâncias e otimização de custo a fundo.
No Google Cloud, Managed Instance Groups com políticas de autoscaling e um Global External Application Load Balancer entregam o stack equivalente. Clusters GKE adicionam autoscaling nativo do Kubernetes em cima, com o Cluster Autoscaler gerenciando a contagem de nós e o HPA gerenciando a contagem de pods de forma independente.
No Kubernetes, em qualquer nuvem, a arquitetura adiciona uma camada de abstração. Os Deployments definem o estado desejado dos pods, o HPA ajusta a contagem de réplicas com base em métricas e o Cluster Autoscaler ou o Karpenter ajusta a contagem de nós com base na pressão de scheduling dos pods. Para times montando arquitetura Kubernetes do zero, o guia de arquitetura Kubernetes explicada é uma referência útil de base.
As armadilhas mais comuns não vêm da configuração de escalonamento em si. Vêm de suposições da aplicação que quebram sob distribuição: hostnames hardcoded, escritas no filesystem local, caches em processo que divergem entre instâncias e chamadas síncronas a serviços que não escalam no mesmo ritmo. Identificar essas suposições antes da aplicação ir para produção evita a sessão de debug que, caso contrário, acontece bem no meio de um pico de tráfego.
Os Forward Deployed Engineers da DoiT trabalham diretamente com os times de CloudOps nesses padrões de implementação, validando suposições de arquitetura e configurando políticas de escalonamento que correspondem ao comportamento real do tráfego.
Como o escalonamento horizontal sustenta operações de nuvem resilientes?
O escalonamento horizontal é a infraestrutura para a realidade de tráfego que a maioria das aplicações em nuvem enfrenta de fato: demanda difícil de prever, picos que chegam sem aviso e requisitos de disponibilidade que não admitem pontos únicos de falha. Uma frota que cresce quando o tráfego chega e encolhe quando ele passa lida com essa realidade sem exigir que um engenheiro responda a cada evento de escalonamento.
A maturidade operacional que faz o escalonamento horizontal funcionar não é uma única mudança de configuração. É um conjunto de práticas: design de aplicação stateless, gerenciamento externalizado de estado, autoscaling orientado por métricas, infrastructure-as-code e ferramentas de observabilidade que tornam uma frota distribuída debugável. Times que constroem essas práticas cedo escalam sem drama. Times que pulam essas etapas escalam direto para o incidente.
A DoiT trabalha com times de CloudOps em todas as fases dessa jornada, desde a arquitetura inicial de clusters Kubernetes até o right-sizing e a otimização de autoscaling de frotas já estabelecidas. O DoiT PerfectScale for Kubernetes analisa continuamente os workloads do cluster e gera recomendações de right-sizing e escalonamento, para que os times gastem menos tempo com ajustes manuais e mais tempo no trabalho que move o negócio para frente. Fale com um engenheiro da DoiT para ver como essa abordagem se aplica à sua arquitetura.
Perguntas frequentes sobre escalonamento horizontal
Qual é a diferença entre escalonamento horizontal e vertical?
O escalonamento horizontal adiciona mais instâncias de um recurso (mais servidores, mais pods, mais nós) para distribuir os workloads. O escalonamento vertical aumenta a capacidade de uma instância existente (mais CPU, mais RAM). O horizontal lida com demanda imprevisível e oferece redundância. O vertical é mais simples de implementar, mas tem um teto duro no maior tamanho de instância disponível.
Quando um time de CloudOps deve escolher escalonamento horizontal em vez de vertical?
O escalonamento horizontal funciona melhor para camadas de aplicação stateless, microsserviços e workloads com tráfego variável ou imprevisível. O vertical se encaixa melhor para processos single-threaded, aplicações legadas que não conseguem distribuir estado ou workloads que precisam de um aumento rápido de capacidade sem mudanças na aplicação. A maioria das arquiteturas de produção usa instâncias bem dimensionadas (vertical) rodando dentro de uma frota escalada horizontalmente.
O escalonamento horizontal reduz custos automaticamente?
Não automaticamente. O escalonamento horizontal alinha o custo à demanda melhor do que um servidor grande de tamanho fixo, mas só se as políticas de autoscaling estiverem bem ajustadas e a frota de base usar preços baseados em commitments. Políticas de scale-in mal configuradas que deixam instâncias ligadas depois da queda de tráfego, ou limites de scale-out cautelosos demais que exigem intervenção manual em picos, corroem o benefício de custo.
Como o Kubernetes lida com escalonamento horizontal?
O Kubernetes usa o Horizontal Pod Autoscaler (HPA) para ajustar o número de réplicas de pods em execução com base na utilização de CPU, memória ou métricas customizadas. O Cluster Autoscaler (ou Karpenter, na AWS) ajusta a contagem de nós com base na demanda de scheduling dos pods. Esses dois controladores trabalham juntos: o HPA escala a camada da aplicação e o autoscaler de nós escala a infraestrutura subjacente para acomodá-la.
Qual é o maior erro de implementação que os times de CloudOps cometem com escalonamento horizontal?
Supor que a aplicação é stateless quando não é. Escritas no filesystem local, armazenamento de sessão em memória e caches em processo criam estado oculto que quebra quando requisições do mesmo usuário caem em instâncias diferentes. Auditar a aplicação em busca dessas suposições antes de escalar a frota evita que esse modo de falha apareça em produção.