Escalar Aplicativos de Contêiner do Azure com KEDA, computação dimensionada e revisões
Projete cargas de IA responsivas e econômicas com gatilhos HTTP, TCP, recursos, filas, eventos, agenda e métricas personalizadas e controle como revisões independentes recebem tráfego.
Tempo de estudo sugerido: 90 minutos • Nível intermediário • Reescrita autoral completa com versão resumida de cada tópico, avaliação comentada e laboratório KEDA guiado
Por João Ricardo Dutra••Conteúdo autoral completo
1. Escalar uma carga de IA sem comprar ociosidade
Uma plataforma de pedidos enfrenta picos programados e explosões inesperadas de campanhas. Capacidade fixa desperdiça dinheiro à noite e ainda produz checkout lento no pico. Um desenho melhor separa a síncrona do worker de atendimento assíncrono e dá a cada componente um sinal que represente o trabalho real.
O objetivo não é apenas criar réplicas: é equilibrar resposta , drenagem da fila, redução a zero quando o cold start for aceitável, teto de custo e implantações que não enviem todos os usuários a uma revisão não comprovada.
Configurar gatilhos ,, CPU e memória.
Escalar por filas, fluxos, agenda e métricas com KEDA.
Escolher CPU, memória e perfil de carga de trabalho com dados.
Usar modos, rótulos e pesos lembrando que cada revisão escala separadamente.
Resumo do tópico
Escolha um sinal por carga, defina limites de desempenho e custo e trate escala e implantação como um único desenho operacional.
2. Definição de escala: limites, regras, comportamento e cobrança
Os declaram a escala horizontal. Limites restringem réplicas por revisão, regras descrevem a demanda e comportamento controla a decisão no tempo. O KEDA converte sinais compatíveis em uma contagem desejada; cada réplica executa uma revisão imutável.
Partes da definição de escala.
Parte
Pergunta
Consequência
Mínimo
O que fica aquecido?
Zero economiza; um ou mais reduz cold start.
Máximo
Qual é o teto de capacidade e custo?
Baixo limita vazão; alto pode pressionar dependências.
Regras
Qual sinal representa trabalho?
,, recursos ou eventos.
Comportamento
Com que rapidez muda?
Sondagem, estabilização, resfriamento e passos evitam oscilação.
Com entrada e sem regra personalizada, o padrão é de zero a dez réplicas por . Sem entrada, mínimo ou gatilho, a aplicação pode chegar a zero e não acordar. Em zero não há cobrança de computação; uma réplica ociosa em memória pode ter tarifa reduzida.
A decisão de escala reúne limites, regras e comportamento temporal.
Resumo do tópico
Limites contêm capacidade, regras detectam trabalho, comportamento estabiliza a resposta e o mínimo define a base entre disponibilidade e custo.
3. Regras de concorrência e
usa a média de requisições concorrentes em 15 segundos; o alvo padrão é dez por réplica. Alvo menor escala cedo e aumenta folga; alvo maior utiliza mais cada réplica e pode elevar latência. A regra chega a zero e serve e Web, mas não trabalhos dos Aplicativos de Contêiner.
usa conexões concorrentes na mesma janela. É melhor para ,, pools de banco e conexões longas. Ao fechar todas as conexões, a revisão pode voltar a zero após o resfriamento.
Use para requisições e para conexões persistentes; ajuste o alvo pela capacidade e latência medidas por réplica.
4. Regras de CPU, memória e combinação
CPU e memória são escaladores personalizados do KEDA que comparam utilização média a um percentual. CPU representa inferência, imagem, transcodificação e serialização; memória representa , agregação e grandes cargas.
Essas regras não acordam uma aplicação em zero porque precisam de réplica para medir. Mantenha uma réplica ou combine com ou evento. Com várias regras, qualquer uma pode iniciar a expansão e prevalece a maior contagem solicitada.
Recursos protegem cargas intensivas, mas exigem gatilho externo para zero; combine demanda e pressão para adicionar capacidade.
5. Sondagem, resfriamento, estabilização e fórmula
Escaladores personalizados e de eventos são consultados a cada 30 segundos; e usam 15 segundos. Resfriamento e estabilização de redução são 300 segundos por padrão; estabilização de aumento é zero. A expansão segue passos como 1, 4, 8, 16 e 32; a redução remove de uma vez o total excedente.
O KEDA parte de réplicasDesejadas = teto(métricaAtual / métricaAlvo) e aplica mínimo, máximo e passo. Cinquenta mensagens com alvo cinco pedem dez. A espera antes de reduzir evita desligar e reacender em uma pausa curta.
Mantenha aquecimento se latência valer mais que ociosidade.
Permita zero em workers intermitentes com fonte capaz de acordá-los.
Inclua os cinco minutos padrão na estimativa de economia.
Correlacione métrica e réplicas no antes de ajustar o limiar.
Resumo do tópico
Um limiar correto ainda precisa de tempo adequado: expansão rápida, redução estável e resfriamento compatível com o ritmo da carga.
6. Integração KEDA e fontes nativas do
O KEDA reage a profundidade de fila, atraso do consumidor, agenda e métricas que não descreve. A regra informa tipo, de conexão e limiar e autenticação, sem exigir que a equipe opere um ScaledObject do Kubernetes.
A Microsoft oferece suporte primário a ,,,, Analytics e . Escaladores comunitários ampliam o catálogo, com maturidade variável.
Escala por eventos converte backlog durável ou sinal mensurável em réplicas e retorna a zero quando o trabalho termina.
Resumo do tópico
O KEDA transforma trabalho externo em demanda de réplicas; prefira fontes com suporte primário e avalie cuidadosamente as comunitárias.
7. Escaladores de e
O monitora mensagens ativas de fila ou assinatura. queueName ou topicName e subscriptionName selecionam o backlog; identifica o serviço e messageCount é o alvo por réplica. Cinquenta mensagens com alvo cinco pedem dez réplicas.
usa accountName, queueName e queueLength sobre a contagem aproximada. É econômico para filas simples. Prefira quando precisar de sessões, mensagens mortas, agendamento, recursos avançados ou maior vazão.
Escolha para mensageria avançada e para o caso simples, calculando o alvo pelo tempo de processamento.
8. Partições dos e autenticação segura
O escalador dos mede eventos não processados entre o fim de cada partição e o ponto de verificação do grupo consumidor. consumerGroup, unprocessedEventThreshold e checkpointStrategy definem o cálculo; blobMetadata é recomendado quando o guarda checkpoints. O paralelismo útil não excede as partições.
Segredo funciona para conexão ou chave, mas exige rotação. Quando houver suporte, use com a função mínima, como Data Receiver. Ela elimina credenciais armazenadas e é a resposta recomendada em produção.
Resumo do tópico
Não escale além do paralelismo útil de partições e prefira de privilégio mínimo.
9. Escaladores personalizados e conversão do KEDA
Fontes baseadas em ScaledObject incluem Apache Kafka, Redis Lists e , Prometheus, Cron, PostgreSQL, MySQL, e de métricas. Verifique significado, autenticação, , mantenedor e suporte. Escaladores externos podem exigir componentes separados.
Mapeie triggers[].type para --scale-rule-type ou custom.type.
Converta triggers[]. em da CLI do ou .
Substitua TriggerAuthentication por segredos e auth, ou .
Mapeie minReplicaCount e maxReplicaCount para os limites.
Teste recursos sem equivalente exato nos .
Resumo do tópico
A conversão preserva tipo, , autenticação e limites e valida explicitamente diferenças da plataforma.
10. Sinais do Apache Kafka e Redis
Kafka mede o atraso do grupo consumidor entre offsets finais e confirmados. bootstrapServers, consumerGroup, topic e lagThreshold definem a regra; SASL/PLAIN, SASL/SCRAM ou protegem a conexão. Réplicas além das partições não ampliam consumo paralelo.
Redis Lists compara LLEN a listLength com address e listName. Redis acompanha entradas pendentes e entregues mas não confirmadas, representando melhor a recuperação. Selecione a variante padrão, ou Sentinel e sua autenticação.
Resumo do tópico
Kafka escala por atraso; Redis, por itens enfileirados ou pendentes. Topologia, confirmação e autenticação limitam o paralelismo.
11. Linha de base Cron e métricas Prometheus
Cron solicita desiredReplicas entre start e end no timezone indicado. Fora da janela não influencia. Combine com ou eventos: pré-aqueça um pico previsto e permita que a demanda real solicite mais; prevalece a maior solicitação.
Prometheus executa uma consulta PromQL em serverAddress e divide o resultado pelo threshold; metricName identifica o sinal. Serve para sessões ativas, transações pendentes, ou métrica de negócio que represente trabalho melhor que concorrência.
Resumo do tópico
Cron antecipa capacidade; Prometheus reage a uma métrica significativa. Use sinais preditivos e reativos juntos.
12. CPU, memória, falhas e capacidade total
Recursos são por contêiner em cada réplica. Memória em GiB deve ser no mínimo duas vezes a CPU em núcleos. O ponto inicial comum é 0,25 CPU e 0,5 GiB; Consumption de propósito geral chega a 4 CPU e 8 GiB por contêiner. têm alocação própria.
Estourar memória encerra e reinicia; exceder CPU limita e aumenta latência. Capacidade máxima é recurso por réplica vezes máximo de réplicas. Vinte réplicas de 0,5 CPU somam dez núcleos. Réplicas maiores têm passos grosseiros; menores escalam com precisão e mais sobrecarga.
Dimensione cada contêiner pelos gargalos medidos e multiplique pelo máximo para comprovar capacidade e teto de custo.
13. Consumption, Dedicated, Flex, custo e desempenho
Consumption é sem servidor, cobra por réplica em execução e favorece demanda variável e zero. Dedicated reserva VMs para consistência, alocações maiores, isolamento ou hardware especializado. A documentação atual também lista Flex em prévia: computação de locatário único, características de cobrança por consumo, réplicas maiores e sem redução a zero. Confirme região e limites antes de adotar.
Comece com padrões, teste modelo e representativos e aumente apenas diante de limitação de CPU, falta de memória, latência ou . Mantenha mínimo para estrito e observe no . Mil réplicas por revisão é limite de serviço, não plano: dependências e paralelismo útil chegam antes.
A computação define desempenho e cobrança; o modo de revisão define como versões compartilham tráfego e escala.
Resumo do tópico
Use Consumption para elasticidade, Dedicated para consistência ou recursos maiores e avalie Flex em prévia, sempre com evidência de carga e custo.
14. Revisões imutáveis e modo único ou múltiplo
Revisão é instantâneo imutável. Imagem, regras de escala, variáveis e recursos do template criam outra; segredos, entrada, tráfego, rótulos, credenciais de registro e modo são do aplicativo e não reescrevem uma revisão.
Único é padrão: a anterior atende até a nova provisionar, atingir a contagem e passar sondas; depois o tráfego muda e a antiga desativa. Múltiplo mantém várias para canary, azul-verde e A/B, exigindo gestão explícita.
az containerapp update \
--name order-api --resource-group rg-ai200-scale \
--revision-mode multiple
az containerapp ingress traffic set \
--name order-api --resource-group rg-ai200-scale \
--revision-weight order-api--stable=90 order-api--candidate=10
Resumo do tópico
Modo único automatiza substituição protegida; múltiplo adiciona convivência controlada e exige tráfego, monitoramento e limpeza.
15. Pesos, rótulos e escala independente
Pesos de revisões ativas somam 100% e o roteamento é probabilístico. Comece canary com 5% ou 10%, observe erro, latência, recursos e réplicas, avance brevemente e conclua ou reverta.
Rótulo cria direta estável para uma revisão e independe da divisão principal. Começa com letra, usa minúsculas, números e hifens simples e tem até 64 caracteres. Pode ser movido atomicamente.
Cada revisão ativa escala por seu tráfego, regras e mínimo. Duas em 50/50 podem custar mais que uma em 100%. Desative a antiga após transição; inativas não consomem réplicas e ficam para até o limite de 100 revisões.
Resumo do tópico
Pesos governam a principal, rótulos dão acesso dirigido e revisões ativas escalam separadamente; monitore e retire capacidade de rollout.
16. Laboratório, avaliação e referências Microsoft
O exercício de 30 minutos implanta de agente simulada, cria e Aplicativos de Contêiner, configura concorrência pelo KEDA, gera carga, acompanha réplicas e reaplica . Exige assinatura com permissão, plano pago porque ACR Tasks pode não aceitar créditos gratuitos, , CLI do atual e Python 3.12 ou superior.
Registre FQDN, revisão, mínimo, máximo e réplicas saudáveis.
Aplique alvo e gere requisições paralelas.
Correlacione carga, réplicas, latência e revisão.
Altere , confirme nova revisão e valide de novo.
Remova recursos descartáveis e não use dados ou segredos reais.
Decisões da avaliação.
Cenário
Resposta
Motivo
Worker do ocioso
Mínimo zero e regra -servicebus.
O backlog durável acorda; e CPU não o representam.
