A pergunta chega quase sempre no mesmo formato: quanto de servidor precisamos para aguentar a Black Friday? Na maior parte das vezes, a pergunta está mal colocada.
A escalabilidade Magento na AWS não é uma questão de quanto, é de onde. Operações que aumentam a capacidade sem saber qual camada satura primeiro gastam mais e continuam caindo, porque colocaram capacidade justamente onde não havia gargalo. Este guia mostra como descobrir esse ponto com dados, e como usar os serviços da AWS na camada certa.
Principais pontos
- O gargalo de uma loja Magento em pico raramente está na camada de aplicação: costuma estar no banco de dados, no cache, na indexação ou nas filas.
- A escala automática resolve uma parte do problema e pode agravar outra, e por isso funciona melhor como margem de segurança.
- O melhor dimensionamento é o que impede que a maior parte do pico chegue ao PHP.
- Banco, cache, indexação e filas saturam por razões diferentes e pedem tratamentos diferentes.
- Um teste de carga com perfil realista vale mais do que qualquer estimativa feita em planilha.
Por que Magento e AWS combinam
O Magento é uma plataforma de médio e grande porte e exige capacidade de servidor proporcional ao tráfego e ao catálogo. A AWS oferece, como serviços gerenciados, as peças que uma loja desse porte costuma precisar:
- Amazon EC2 e Auto Scaling: servidores virtuais para a aplicação, em um grupo que muda de tamanho conforme regras que você define.
- Elastic Load Balancing: distribui as requisições entre as instâncias e retira do rodízio as que falham nos health checks.
- Amazon RDS: banco de dados gerenciado, com réplicas de leitura.
- Amazon ElastiCache: cache em memória, com os motores Valkey, Redis OSS e Memcached.
- Amazon CloudFront: rede de distribuição de conteúdo (CDN) para imagens, CSS e JavaScript, entregues a partir de locais próximos do visitante.
Ter esses serviços à disposição não dimensiona a loja sozinho. O que decide o resultado é a configuração de cada camada e a ordem em que cada uma satura.
Onde a plataforma satura de verdade
A intuição aponta para o servidor de aplicação, porque é ali que o PHP roda e é ali que a métrica de processamento aparece primeiro. Na prática, a camada de aplicação é a mais fácil de escalar e a que menos costuma ser o limite real.
- Banco de dados: é o gargalo mais comum em pico. A aplicação escala na horizontal com facilidade, mas cada nova instância abre mais conexões contra o mesmo banco. Em determinado ponto, adicionar servidor piora o desempenho, porque o banco passa a gastar mais tempo com concorrência do que respondendo consultas.
- Cache e sessão: a camada que guarda cache e sessão vira ponto único de pressão sob concorrência alta. Se estiver subdimensionada em memória ou em conexões, cada requisição fica mais lenta sem que nenhuma métrica da aplicação indique problema.
- Indexação: reindexar durante o pico é uma causa frequente de degradação, e quase sempre é autoinfligida. Uma alteração de preço em massa, uma carga de catálogo vinda do ERP ou uma regra promocional aplicada no meio da campanha fazem a reindexação competir por recursos justamente no momento de maior tráfego.
- Filas e consumidores: a integração assíncrona que funciona no dia normal precisa de consumidores dimensionados para o volume do pico. Quando não estão, o pedido entra na loja, o cliente recebe a confirmação e nada chega ao ERP. O sintoma aparece horas depois, na expedição.
- Imagens e arquivos estáticos: um catálogo com imagens não pré-processadas transforma cada primeira visualização em trabalho de processamento. Em pico, com cache frio, isso vira consumo significativo e evitável.
Por que escala automática não é a resposta completa
O EC2 Auto Scaling é um recurso valioso e deve estar configurado. Ele também tem três limitações que precisam estar no plano.
- Tempo de entrada em operação. Uma instância nova leva um tempo entre o disparo da regra e o momento em que atende com o cache aquecido. A própria documentação da AWS trata esse intervalo como o warmup da instância, que deve ser configurado, e sugere começar com 300 segundos quando não se sabe o valor ideal. Picos de varejo não são rampas suaves: um disparo de e-mail ou uma entrada em rede social produz crescimento em segundos.
- Escala a camada errada, se o gargalo for outro. Se o limite está no banco, adicionar servidor de aplicação aumenta a pressão sobre ele. Nesse caso, a automação piora o quadro.
- Cache frio. Uma instância nova começa sem cache local, e as primeiras requisições que ela atende são mais lentas.
Por isso, para uma data conhecida, combine as duas abordagens. O Auto Scaling permite criar ações agendadas, que mudam a capacidade mínima, máxima e desejada do grupo em horários definidos. Eleve a capacidade base de forma programada antes do evento e deixe as regras dinâmicas atuarem como margem acima disso. A documentação da AWS descreve exatamente esse uso: ações agendadas e políticas de escala podem trabalhar juntas.
Escala automática é rede de proteção, não plano de capacidade.
A camada que mais retorna: impedir que o pico chegue ao PHP
O dimensionamento mais eficiente não é o que aumenta capacidade, é o que reduz a demanda que chega até ela. Cada requisição respondida na borda é uma requisição que não consome aplicação, não consome banco e não gera escala.
Isso pede três frentes:
- Cache de página completa com taxa de acerto medida. A Adobe recomenda o Varnish em produção e informa que o cache de página nativo do Magento é bem mais lento que ele. A taxa de acerto é a métrica que mostra quanto do pico chegará ao PHP, e ela precisa ser medida em produção, não presumida a partir do ambiente de desenvolvimento.
- Conteúdo estático pela borda. Com o CloudFront, imagens, CSS e JavaScript saem de locais próximos do visitante, e não do servidor da loja. Esses arquivos costumam ser a maior parte das requisições de uma página.
- Revisão do que invalida o cache. Regra promocional mal desenhada, bloco dinâmico onde não era necessário e parâmetro de campanha na URL são causas comuns de invalidação em massa no pior momento possível. Uma taxa de acerto que cai de forma progressiva é o sinal de que algo está invalidando o cache.
Uma loja com o cache bem configurado atravessa o pico com uma fração da infraestrutura que uma loja mal configurada exige. Essa diferença é de arquitetura, não de orçamento.
Dimensionar cada camada com critério
Banco de dados
- Separe leitura e escrita. As réplicas de leitura do Amazon RDS são cópias somente leitura do banco principal, atualizadas de forma assíncrona. Direcione para elas a consulta de catálogo e a navegação, e deixe o servidor principal para pedidos e checkout.
- Lembre que a replicação é assíncrona: a réplica pode ficar atrás do servidor principal por alguns instantes, e a loja precisa tolerar isso nas telas em que o dado recém-gravado importa.
- O Magento aceita configurar uma conexão somente leitura para réplicas na configuração do banco (bloco
slave_connection), mas a documentação da Adobe avisa que a replicação em si precisa ser montada à parte. - Revise o limite de conexões do banco contra o número de instâncias de aplicação previstas no pico. Essa conta costuma estourar antes da capacidade de processamento. O RDS Proxy mantém um conjunto de conexões reutilizáveis e ajuda a absorver picos de conexões, mas ele só pode ser associado ao banco principal, não a uma réplica de leitura.
- Analise o log de consultas lentas e crie os índices que faltam.
Cache e sessão
- Dimensione por memória e por conexões simultâneas, e não só por memória.
- Mantenha a sessão fora do disco da instância de aplicação. Esse é o pré-requisito para a escala horizontal funcionar sem perder o carrinho.
- No ElastiCache, escolha o motor conforme a versão do Magento. No Adobe Commerce 2.4.9 e nos patches mais recentes das versões anteriores, a Adobe exige Valkey na configuração de cache, e o ElastiCache oferece Valkey.
- Use bancos numerados diferentes para cada tipo de cache, como a Adobe recomenda: 0 para o cache padrão, 1 para o cache de página e 2 para a sessão.
Indexação
- Mantenha os indexadores em “Atualizar por agendamento” no período de pico. A Adobe recomenda esse modo para lojas grandes, com atualizações frequentes ou muito tráfego, e alerta que o modo “Atualizar ao salvar” pode causar deadlocks.
- Bloqueie operações de carga em massa na janela crítica. Escreva isso como regra combinada com as áreas comercial e de catálogo antes do evento, porque a alteração de preço em massa em plena campanha é sempre bem-intencionada.
Filas
- No Magento, os consumidores de filas rodam por padrão pela tarefa de cron
consumers_runner, e cada execução processa um número de mensagens e termina. Revise essa configuração para o volume do pico. - Monitore pela idade da mensagem mais antiga, e não pela quantidade acumulada. Volume alto com idade estável é normal em pico, e idade crescente é incidente.
Balanceador de carga
- Configure health checks no balanceador para que as instâncias com falha saiam do rodízio automaticamente. Defina o caminho de verificação, o intervalo e o número de falhas consecutivas com valores testados, e não os padrões sem revisão.
Teste de carga com perfil, não só com volume
O erro mais comum em teste de carga é simular volume sem simular comportamento. Milhares de acessos à página inicial não estressam o que quebra em um pico real.
O perfil precisa refletir o que de fato acontece: proporção significativa de busca interna, navegação por categoria com filtro, consulta de disponibilidade, adição ao carrinho, cálculo de frete e checkout concorrente. A busca e o filtro consomem recursos de forma muito diferente da navegação simples, e o checkout concorrente é o que revela contenção de estoque e limite de conexões.
O objetivo do teste não é confirmar que a loja aguenta. É descobrir onde ela para de aguentar e o que quebra primeiro. Um teste que passa sem encontrar o ponto de saturação não produziu informação. Com esse ponto em mãos, o dimensionamento vira uma decisão com número: quanta folga você quer acima do pico esperado, sabendo o custo dessa folga.
Rode o teste com tempo para agir. Descobrir o gargalo com antecedência permite corrigir a arquitetura. Descobrir perto do evento permite apenas comprar capacidade, que é a forma mais cara e menos eficaz de resolver o problema. O checklist de Black Friday para Magento traz o cronograma completo dessa preparação.
Plano em cinco passos
- Meça a taxa de acerto do cache de página e corrija o que invalida o cache.
- Rode um teste de carga com a jornada completa e registre o primeiro componente que satura.
- Corrija a camada que saturou primeiro (banco, cache, indexação ou filas) antes de pensar em mais servidores.
- Agende o aumento de capacidade base para a janela do evento e configure o warmup e o teto da escala automática.
- Repita o teste depois das correções e ensaie, com o time, quem decide o quê quando um alerta disparar.
Como a Trezo pode ajudar
A Trezo trabalha só com Magento e Adobe Commerce desde 2009. Somos AWS Partner e Adobe Solution Partner, com certificação ISO 27001, e monitoramos as lojas dos nossos clientes 24 horas por dia, 7 dias por semana. Conheça nossa infraestrutura AWS para Magento e o trabalho de sustentação.
Se quiser revisar o dimensionamento da sua loja, fale com nossos especialistas.
Perguntas frequentes
O número sai do seu teste de carga, não de uma regra geral. Identifique o ponto de saturação, compare com o pico esperado, projetado a partir do seu próprio histórico, e defina a folga desejada acima disso. Provisionar por múltiplo arbitrário do tráfego normal gera sobra em uma camada e falta em outra, porque as camadas não saturam na mesma proporção.
Sozinha, não. Ela reage ao tráfego, e uma instância nova leva tempo até atender com o cache aquecido. Para uma data conhecida, aumente a capacidade base com uma ação agendada e use a escala automática como margem acima disso.
O banco de dados, em geral. Cada instância de aplicação nova abre mais conexões contra o mesmo banco, e em certo ponto adicionar servidor piora o tempo de resposta. Por isso o teste de carga precisa medir conexões e consultas, e não só a CPU da aplicação.
Resolve a parte de leitura, como navegação e consulta de catálogo, porque tira essa carga do servidor principal. A replicação é assíncrona, então a loja precisa tolerar um pequeno atraso, e as gravações de pedido e checkout continuam no servidor principal.
Depende da versão. No Adobe Commerce 2.4.9 e nos patches mais recentes das versões anteriores, a Adobe exige Valkey na configuração de cache. Confira a documentação da Adobe para a sua versão e patch antes de decidir.
Significa custo variável, que é diferente de imprevisível. Com o ponto de saturação conhecido e um teto de escala definido, o custo máximo do período pode ser calculado antes. A surpresa na fatura vem de uma escala sem teto combinada com um gargalo que a escala não resolve.
Desempenho isolado raramente justifica essa mudança. Boa parte do ganho atribuído ao headless vem de cache bem configurado e distribuição pela borda, que podem ser obtidos sem trocar a camada de apresentação. Headless faz sentido por outras razões, como múltiplos canais e autonomia do time de frontend.
