Escala e disponibilidade
Quatro perguntas diferentes vivem na mesma tela do console, e vale saber qual é qual.
| A pergunta | O nome |
|---|---|
| Quantas cópias da aplicação existem? | Instâncias |
| Quanto cada uma pode usar? | Tamanho da instância — ver Recursos e limites |
| O número acompanha a carga? | Autoscaling |
| Sobrevive à perda de uma máquina? | Alta disponibilidade |
Instâncias
O número de cópias da sua aplicação rodando ao mesmo tempo. Mais instâncias atendem mais requisições simultâneas e consomem proporcionalmente mais recursos.
O console mostra quantas estão no ar e quantas foram pedidas — "3 de 4 no ar". A diferença importa: mostrar só o número pedido faria a tela concordar com quem pediu e discordar da realidade.
Autoscaling
Em vez de um número fixo, você declara um intervalo e um alvo de uso de CPU. A plataforma acrescenta instâncias quando o uso passa do alvo e remove quando fica abaixo dele por alguns minutos.
| Campo | O que é |
|---|---|
| Mínimo | O piso. Nunca menos que isto, mesmo sem tráfego nenhum |
| Máximo | O teto. A escala nunca passa daqui |
| Uso de CPU para escalar | O alvo, em percentual da CPU reservada de cada instância |
O alvo é medido contra a reserva, não contra o máximo. É por isso que todo serviço precisa ter CPU reservada declarada: sem ela o autoscaling não tem contra o que comparar e simplesmente não acontece.
70% é um ponto de partida razoável: deixa margem para o pico entre duas avaliações. Um alvo de 90% faz a aplicação passar o tempo todo perto do teto, e a escala só reage depois de a latência já ter subido.
Subir é rápido; descer é devagar
A plataforma sobe capacidade sem espera — um pico precisa de instâncias agora. Para descer, ela espera cinco minutos e observa a maior recomendação da janela.
A assimetria é deliberada. Descer rápido produz o serra-serra: a carga cai, as instâncias somem, o tráfego volta para as que ficaram, e elas sobem de novo.
Mínimo de um, nunca de zero
Uma aplicação online com zero instâncias é uma aplicação fora do ar sem ninguém ter dito isso. O mínimo aceito é 1.
Alta disponibilidade
As instâncias de um serviço são distribuídas entre máquinas diferentes, automaticamente. Não é uma opção a ligar: é o comportamento de toda aplicação publicada.
Sem isso, quatro instâncias podem cair na mesma máquina — quatro processos com um destino só. Com a distribuição, perder uma máquina significa capacidade reduzida, não a aplicação fora do ar.
Manutenções também respeitam isso: quando a plataforma precisa esvaziar uma máquina, ela retira uma instância por vez e espera a substituta ficar pronta antes de seguir.
O alcance exato da proteção
A distribuição protege contra a falha de uma máquina. Ela não protege contra a perda da zona de disponibilidade — as máquinas da instalação atual vivem numa única zona. O mesmo aviso aparece na tela do console: o produto não promete o que a infraestrutura não entrega.
Quando a capacidade acaba
Se você pedir mais instâncias do que cabem no pool, as que não couberem ficam esperando lugar. A plataforma avisa quando isso acontece — não há crescimento automático de máquinas nesta instalação, então o aumento de capacidade é uma decisão de quem opera.
Ajustar
- Abra o projeto e vá em Escala e disponibilidade.
- Escolha o serviço e clique em Ajustar.
- Escolha Número fixo de instâncias ou Autoscaling.
- No autoscaling, informe mínimo, máximo e o alvo de CPU.
- Salve.
Como toda mudança de configuração, ela vale depois de aplicada, não depois de salva: a plataforma republica o serviço com a mesma imagem e acompanha até o fim.
Quando a escala não acontece
O console explica em vez de ficar calado:
| O que a tela diz | O que investigar |
|---|---|
| Não está recebendo a medida de uso | O serviço não tem CPU reservada declarada |
| No limite configurado | O intervalo chegou ao máximo — ou ao mínimo |
| Instância sem lugar | A capacidade do pool acabou; fale com quem opera a plataforma |
Esta página ajudou?
Reportar um problema nesta páginaNão envie senhas, chaves, tokens ou dados de clientes.