Sobre o escalonamento automático de instâncias nos serviços do Cloud Run

O escalonamento automático do Cloud Run ajusta o número de instâncias de contêiner para cada revisão de serviço para corresponder às solicitações, aos eventos e à utilização da CPU recebidos. O escalonamento de instâncias sob demanda ajuda o serviço a lidar com picos de tráfego e a reduzir a escala a zero quando ocioso para reduzir custos.

É possível ajustar os limites de escalonamento automático configurando metas personalizadas de CPU e simultaneidade e definindo limites de instâncias mínimos e máximos. Se o serviço usar a CPU fora do processamento de solicitações, defina o mínimo de instâncias como pelo menos 1. Para executar uma contagem de instâncias fixa, consulte Escalonamento manual.

Comportamento de escalonamento automático horizontal de serviços

O Cloud Run tem dois mecanismos de escalonamento automático: o escalonamento com base em métricas e o escalonamento sob demanda para determinar o número de instâncias necessárias para atender ao tráfego.

Escalonamento com base em métricas

O escalonamento com base em métricas ajusta automaticamente o número de instâncias com base na utilização média da CPU e nos drivers de escalonamento de simultaneidade de solicitações médias para fornecer capacidade de veiculação estável para o serviço do Cloud Run.

O escalonador automático determina um número recomendado de instâncias com base no número máximo de instâncias que ele calcula para cada um dos seguintes drivers de escalonamento de maneira independente:

  • Uso da CPU: calcula o número de instâncias fazendo a média do uso da CPU por segundo em um período de 1 minuto e divide esse valor pelo número de CPUs por instância. Esse resultado é dividido pela meta de CPU. A equação a seguir define esse cálculo:

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\text{Average CPU usage per second over the past minute}}{\text{Number of CPUs per instance}} \right)}{\text{CPU target}} \right\rceil \]

  • Simultaneidade de solicitações: calcula o número de instâncias fazendo a média da simultaneidade de solicitações por segundo em um período de 1 e 10 minutos e dividindo esse valor pela simultaneidade máxima. Esse resultado é dividido pela meta de simultaneidade de solicitações. A equação a seguir define esse cálculo:

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\max(\text{average concurrent requests over 1 minute, 10 minutes})}{\text{Maximum concurrency}} \right)}{\text{Concurrency target}} \right\rceil \]

  • Ajuste de simultaneidade adaptável (ACT, na sigla em inglês): calcula o número recomendado de instâncias para a simultaneidade média de solicitações de 1 minuto. Esse método usa o valor de ACT de cada instância como a capacidade de simultaneidade de solicitações da instância, em vez do máximo de solicitações simultâneas configurado. O ACT reduz dinamicamente a simultaneidade em 1 em intervalos de 1 segundo quando o uso da CPU excede 90%. Para mais informações, consulte Ajuste de simultaneidade adaptável (ACT).

Para cada revisão de serviço, é possível configurar o número de CPUs por instância e a simultaneidade máxima.

O Cloud Run não é compatível com o escalonamento com base no uso da memória.

Por padrão, o escalonamento baseado em métricas define um limite de 60% para a utilização da CPU e as metas de simultaneidade de solicitações. É possível usar controles de escalonamento para especificar metas personalizadas de CPU ou simultaneidade.

Quando o Cloud Run é escalonado com base na utilização da CPU, ele considera a utilização média da CPU em todas as CPUs alocadas para uma instância. Se o aplicativo for de thread único, mas implantado em uma instância com várias CPUs, isso pode levar a uma leitura de utilização média baixa, o que pode afetar as decisões de escalonamento com base na CPU. Para mais detalhes sobre como otimizar a configuração da CPU para a arquitetura do aplicativo, consulte Configurar limites de CPU e Definir o máximo de solicitações simultâneas por instância.

Escalonar verticalmente

O Cloud Run aumenta o número de instâncias com base no driver de escalonamento que requer mais instâncias. Em contagens de instâncias baixas, o escalonamento com base em métricas responde de perto às suas metas de utilização.

O escalonamento com base em métricas mantém a contagem de instâncias atual enquanto a utilização permanece dentro de uma tolerância de 10% da meta, em relação à meta. Por exemplo, com a meta padrão de 60%, a contagem de instâncias não muda enquanto a utilização permanece entre 54% e 66%.

Quando a utilização sai desse intervalo, o escalonamento baseado em métricas recalcula a contagem de instâncias com base no uso medido e na meta, não no número de instâncias em execução, e arredonda o resultado para a próxima instância inteira. Devido a esse arredondamento, o serviço pode escalonar verticalmente enquanto a utilização ainda está abaixo da meta. Por exemplo, um serviço que precisa de 4,1 instâncias para atingir a meta executa 5 instâncias.

Reduzir escala verticalmente

O escalonamento automático do Cloud Run reduz o número de instâncias em execução quando elas não são mais necessárias para atender ao tráfego de entrada. O escalonamento com base em métricas ajusta continuamente o número de instâncias recomendadas com base na utilização. O Cloud Run reduz a contagem de instâncias recomendada somente quando a utilização cai mais de 10% abaixo da meta e, em seguida, usa o mesmo cálculo arredondado para determinar a nova contagem.

Quando o uso médio da CPU ou as solicitações ativas médias diminuem, o algoritmo de escalonamento reduz o número recomendado de instâncias. O balanceador de carga de solicitações do Cloud Run considera essas recomendações ao encaminhar preferencialmente as solicitações recebidas para as instâncias recomendadas primeiro. Isso mantém as instâncias recomendadas mais ocupadas e permite que outras instâncias fiquem ociosas. O Cloud Run reduz a contagem dessas instâncias não recomendadas, diminuindo a prioridade delas para que elas só recebam tráfego se todas as instâncias recomendadas estiverem ocupadas. Para manter a estabilidade, o Cloud Run encerra as instâncias despriorizadas na seguinte ordem:

  1. O Cloud Run encerra um grupo de instâncias quando a utilização delas em uma janela de um minuto é inferior a 10%.
  2. Um segundo grupo de instâncias permanece em execução até que ocorra um tempo limite de inatividade de 15 minutos, garantindo que a capacidade esteja disponível em caso de um pico repentino de tráfego.

Se o serviço realizar outras tarefas mesmo quando não estiver processando solicitações, como executar linhas de execução em segundo plano ou processar tarefas assíncronas, defina o mínimo de instâncias como pelo menos 1 para garantir que a CPU permaneça alocada para o processamento em segundo plano.

Escalonamento sob demanda

O Cloud Run usa o escalonamento sob demanda quando não encontra uma instância disponível para atender à solicitação recebida. O escalonamento sob demanda responde em tempo real a mudanças no tráfego de entrada em uma revisão do Cloud Run ou a mudanças na latência da revisão. Esse escalonamento tenta garantir que todas as solicitações recebidas sejam roteadas para uma instância em um curto período. O escalonamento sob demanda é o único fator que permite o escalonamento a partir do zero. No entanto, ao escalonar a partir de N instâncias, o escalonamento baseado em métricas ou sob demanda processa o tráfego, dependendo de qual é acionado primeiro.

Como o escalonamento sob demanda responde em tempo real a mudanças repentinas de tráfego, o Cloud Run gerencia o equilíbrio entre a latência de inicialização a frio (o tempo para iniciar uma nova instância) e a latência da fila pendente (o tempo que uma solicitação espera para que um slot seja aberto em uma instância atual). Para cada solicitação, o sistema determina se a fila para uma instância futura ou uma instância atual é mais rápida (nessa ordem) antes de tentar iniciar uma nova instância por demanda. Uma solicitação permanece na fila pendente por no máximo 10 segundos ou 3,5 vezes o horário de início a frio previsto (o que for maior) antes que o sistema acione uma nova instância por demanda.

Ajuste de simultaneidade adaptável (ACT, na sigla em inglês)

O Cloud Run usa o ajuste de simultaneidade adaptável (ACT, na sigla em inglês) para evitar que a limitação de CPU cause alta latência de solicitação. Essa abordagem mede a utilização da CPU para cada instância em um determinado número de solicitações e ajusta dinamicamente o valor máximo de solicitações simultâneas da instância para manter a utilização da CPU abaixo de 90%. O ACT ajusta a simultaneidade com base nos seguintes cenários:

  • Sempre que a utilização da CPU no último segundo exceder 90%, o ACT vai reduzir em 1 o número máximo de solicitações simultâneas da instância.

  • Se a instância atingir o limite máximo de solicitações simultâneas e o uso da CPU permanecer abaixo de 70% por 1 segundo, o ACT vai aumentar em 1 o máximo de solicitações simultâneas para a instância.

  • Se as métricas de escalonamento mostrarem que a simultaneidade nunca atinge o máximo configurado, pode ser porque o ACT reduziu dinamicamente o máximo real para proteger o desempenho da instância.

O Cloud Run calcula os valores de ACT para cada implantação. Essas métricas não persistem entre as implantações. Se o ACT reduzir a simultaneidade abaixo do nível preferencial, aumente a CPU alocada por solicitação simultânea máxima. As tarefas em segundo plano que causam picos periódicos de CPU também podem interferir nessa abordagem de escalonamento.

Para monitorar quando o ACT está impulsionando ativamente o escalonamento automático, confira o campo scaling_driver no console do Google Cloud . Para saber como visualizar essa métrica, consulte Configurar controles de escalonamento personalizados para serviços.

Faturamento e escalonamento automático baseados em instâncias

Se você configurar o faturamento com base em instâncias para o serviço do Cloud Run, esteja ciente do comportamento de escalonamento para e de zero.

Escalonamento a partir do zero. O escalonamento a partir do zero só pode ser acionado por uma solicitação. Portanto, um serviço que não está processando solicitações não pode ser escalonado do zero. Para essas cargas de trabalho, é possível definir o mínimo de instâncias como > 0 ou incluir uma "solicitação de ativação" no design para reiniciar o processamento após a redução da escala a zero.

Redução da escala a zero. Como nenhuma instância está com 0% de CPU, analisar todo o uso da CPU resultaria na não redução da escala a zero. Isso significa que a decisão de escalonar de um a zero só pode ser tomada ao verificar se a instância está processando uma solicitação.

Sobre o número máximo de instâncias para serviços

Em alguns casos, convém limitar o número total de instâncias que podem ser iniciadas, por motivos de controle de custos ou para melhor compatibilidade com outros recursos usados pelo serviço. Por exemplo, seu serviço do Cloud Run pode interagir com um banco de dados que só pode lidar com um determinado número de conexões abertas simultâneas.

Todos os serviços recebem um limite máximo de instâncias por padrão, mesmo que você não especifique o seu. Defina e monitore esse limite para determinar o comportamento de escalonamento e os custos associados ao serviço. Para mais informações, consulte Limites máximos de instâncias.

É possível usar a configuração máxima para limitar o número total de instâncias que podem ser iniciadas em paralelo, conforme documentado em Como configurar um número máximo de instâncias.

Como exceder o máximo de instâncias

Em circunstâncias normais, a revisão é escalonada horizontalmente com a criação de novas instâncias para lidar com a carga de tráfego recebida. No entanto, quando você define um limite máximo de instâncias, em alguns cenários, não há instâncias suficientes para atender a essa carga de tráfego. Nesse caso, as solicitações recebidas são enfileiradas (pendentes) da seguinte maneira:

As solicitações ficarão pendentes por até 3,5 vezes o tempo médio de inicialização das instâncias de contêiner desse serviço ou 10 segundos, o que for maior.

Durante esse período, se uma instância concluir o processamento de solicitações, ela ficará disponível para processar as solicitações pendentes na fila. Se nenhuma instância ficar disponível durante o período, a solicitação falhará com um código de erro 429.

Garantias de escalonamento

O limite máximo de instâncias é um limite por revisão e significa que o número de instâncias dessa revisão não pode exceder o máximo.

Em circunstâncias normais, o Cloud Run pode ser escalonado horizontalmente para o limite máximo de instâncias muito rapidamente a fim de lidar com todas as solicitações ou eventos recebidos. No entanto, definir um limite alto não significa que a revisão poderá ser escalonada horizontalmente para o número especificado de instâncias em um determinado momento. Em circunstâncias excepcionais, o Cloud Run pode limitar o escalonamento para garantir um bom serviço a todos os clientes.

Máximo de instâncias excedido devido a picos de tráfego

Em alguns casos, como aumentos rápidos de tráfego ou manutenção do sistema, o Cloud Run pode, por um curto período, criar mais instâncias do que é especificado na configuração de máximo de instâncias. As novas instâncias podem ser iniciadas além do limite máximo da configuração de instâncias para substituir as atuais e fornecer um período de carência para que as solicitações em andamento terminem de ser processadas.

O limite máximo de instâncias pode ser excedido na operação normal algumas vezes por semana. O período de carência geralmente dura 15 minutos ou até o valor especificado na configuração de tempo limite de solicitação. Essas instâncias extras são destruídas após ficarem ociosas por 15 minutos.

Se muitas substituições forem necessárias, as atualizações geralmente serão distribuídas por vários minutos ou horas, mas cada uma terá uma instância em excesso apenas para o período de carência. As instâncias acima do valor máximo são normalmente menores do que o dobro do limite máximo de instâncias configuradas, mas podem ser muito maiores no caso de picos de tráfego repentinos e grandes.

Nos testes de carga, há mais instâncias que excedem a configuração máxima porque o sistema pode mudar onde os picos de tráfego forem atendidos para preservar a capacidade das cargas de trabalho existentes, que têm padrões de carga sustentados.

Se o serviço não puder tolerar esse comportamento temporário, considere uma margem de segurança e defina um valor máximo de instâncias mais baixo.

Divisão de tráfego

Como o limite máximo de instâncias é um limite para cada revisão, se o serviço dividir o tráfego em várias revisões, o número total de instâncias para o serviço poderá exceder o máximo de instâncias por revisão. Isso pode ser observado nas métricas Contagem de instâncias.

Implantações

Quando você implanta uma nova revisão para exibir 100% do tráfego, o Cloud Run inicia instâncias suficientes da nova revisão antes de direcionar o tráfego para ela. Isso reduz o impacto de novas implantações de revisão nas latências de solicitação, especialmente ao exibir altos níveis de tráfego. Como o limite máximo de instâncias é um limite para cada revisão, durante uma implantação, o número total de instâncias para o serviço pode exceder o máximo de instâncias por revisão. Isso pode ser observado nas métricas Contagem de instâncias.

Instâncias ociosas e como minimizar inicializações a frio

Para minimizar as inicializações a frio, o Cloud Run pode manter as instâncias inativas por um período após o processamento das solicitações (até 15 minutos ou 10 minutos para GPUs).

Uma instância inativa pode manter recursos permanentes, como conexões de banco de dados abertas. A configuração de faturamento padrão é o faturamento com base em solicitações, a menos que você configure explicitamente o serviço para ter faturamento com base em instâncias.

Para manter as instâncias ociosas permanentemente disponíveis, use a configuração min-instance. Observe que o uso desse recurso gerará custos mesmo quando o serviço não estiver exibindo solicitações ativamente.

Escalonamento automático e solicitações pendentes

As solicitações ficarão pendentes por até 3,5 vezes o tempo médio de inicialização das instâncias de contêiner desse serviço ou 10 segundos, o que for maior.

Impacto do escalonamento automático em serviços de apoio

À medida que o número de instâncias aumenta automaticamente, o serviço do Cloud Run pode encontrar limites com os serviços de apoio. Por exemplo, o Cloud SQL tem um limite de cota da API. Verifique se esses serviços de backup têm cota suficiente e podem processar conexões de todas as instâncias do serviço do Cloud Run. Considere definir um número máximo de instâncias de contêiner para evitar sobrecarregar os serviços de apoio.

Escalonamento automático e Pub/Sub

O Google recomenda o uso de assinaturas por push para consumir mensagens de um tópico do Pub/Sub no Cloud Run. As mensagens enviadas são recebidas como solicitações HTTP pelo contêiner, acionando o mesmo comportamento de escalonamento automático.

Escalonamento automático e vários contêineres (arquivos secundários)

O Cloud Run considera a utilização da CPU das instâncias para o escalonamento automático, em que a utilização da CPU de uma instância é a porcentagem de CPU alocada em uso.

Você aloca a CPU ao definir limites de CPU no nível do contêiner. Se você usar vários contêineres por instância, a alocação real de CPU para essa instância será a soma dos limites de CPU definidos em cada contêiner.

A seguir