Conserte o worker antes de escalar a frota
Um rollout de autoscaling baseado em fila expôs browser workers travados; escalar só passou a ser útil depois que o vazamento de recursos foi contido.
O KEDA ficou ativo em quatro ambientes. O teto de 50 réplicas em produção é configuração, não capacidade de throughput demonstrada.
Contribuição em resumo
- Minha responsabilidade
- Análise do sinal de demanda, configuração do KEDA e diagnóstico e reparo do ciclo de vida do worker.
- Escopo
- Um worker orientado por Pub/Sub implantado em quatro ambientes.
- Colaboração & limites
- Atuei entre o comportamento de processo da aplicação e o escalonamento de infraestrutura; o rollout expôs um defeito no worker que precisava ser reparado primeiro.
- Resultado
- O KEDA ficou ativo em quatro ambientes depois de conter os processos filhos travados. Um limite de 50 réplicas é configuração, não capacidade demonstrada.
O sinal enganoso
O serviço capturava livestreams usando processos filhos de browser. Um pod podia ocupar todos os seus slots de concorrência usando pouca CPU. Uma vez cheio, ele parava de pegar mensagens, de modo que a demanda adicional se acumulava no Pub/Sub em vez de fazer o autoscaler baseado em CPU reagir.
Minha contribuição
Avaliei o sinal de demanda real do workload, implementei um gatilho Pub/Sub do KEDA e investiguei as falhas descobertas durante o rollout. Essa investigação mudou a tarefa: um incidente ativo em produção exigia uma correção no ciclo de vida do worker antes que escalar pudesse ajudar.
O defeito na aplicação por trás do backlog
Streams sem nenhum participante deixavam processos filhos esperando indefinidamente por um elemento de vídeo. Cada filho mantinha um browser e um slot de concorrência até os pods ficarem sem memória. Mais réplicas apenas distribuiriam esses processos travados por mais máquinas.
Verifiquei o comportamento dentro do próprio browser do pod e corrigi o ciclo de vida do health-check no lado do processo pai. Uma hipótese inicial de timeout no lado do browser foi rejeitada pela evidência de produção: o caminho do lado do pai era o que realmente disparava.
Escolha um sinal que o workload realmente produz
Usei o backlog na subscription consumida por esta aplicação. A contagem de streams ativos de um serviço irmão representava um fluxo de captura diferente, e sua métrica de escalonamento não podia ser reaproveitada com segurança. Um gatilho do Prometheus também era inadequado porque a infraestrutura de scrape necessária não existia nos clusters de desenvolvimento e staging.
O HPA anterior foi removido quando o KEDA assumiu o controle. Desenvolvimento, staging e sandbox usavam workload identity para o scaler; produção usava um caminho de credenciais verificado separadamente.
Resultados e medição
O encerramento registrou KEDA Ready em quatro ambientes e as aplicações GitOps relacionadas como Synced/Healthy. O snapshot pós-rollout relatou zero restarts, em comparação com repetidos OOM kills durante o incidente. Esta é uma observação do rollout, não uma afirmação de disponibilidade de longo prazo.
O máximo de produção foi configurado em 50 réplicas. Isso é um limite de proteção a monitorar, não prova de capacidade sustentada nesse tamanho.
Limites e escolhas operacionais
A promoção para produção foi uma exceção explícita de incidente, antes da validação de QA habitual. O acompanhamento seguiu pendente em torno dos streams sem participantes, da origem do seu pico de tráfego e da pressão de capacidade em contagens de réplicas mais altas. A mudança conteve a falha no ciclo de vida de recursos; ela não estabeleceu uma taxa de sucesso de captura de ponta a ponta.
A lição
O autoscaling controla quantos workers existem. Ele não consegue fazer cada worker liberar recursos corretamente. Diagnostique o mecanismo de saturação antes de aumentar a frota.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e seus limites. A próxima melhoria é uma proposta, não um resultado entregue.
Alternativa e justificativa
Gatilhos de CPU e memória não enxergam um worker cujos slots estão ocupados por processos de browser travados. O backlog representa melhor o trabalho pendente.
Trade-off
Escalar um worker que vaza recursos multiplica o defeito. O escalonamento baseado em demanda ainda precisa de ciclos de vida e concorrência limitados nos processos filhos.
O que eu melhoraria em seguida
Próxima melhoria: fazer load-test de throughput e recuperação com falhas de stream realistas antes de tratar os limites de réplicas como garantias de capacidade.