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

No Cloud Run, cada revisão é escalonada automaticamente para o número de instâncias necessárias para processar todas as solicitações recebidas, os eventos ou o uso da CPU.

Por padrão, quando uma revisão não recebe nenhum tráfego, ela é reduzida para zero instância. No entanto, é possível alterar esse padrão para especificar que uma instância seja mantida inativa ou "morna" usando a configuração de instâncias mínimas. Se você estiver usando a CPU fora das solicitações, defina o mínimo de instâncias como 1.

Além da taxa de solicitações recebidas, de eventos ou de utilização da CPU, o número de instâncias programadas é afetado por:

O escalonador automático do Cloud Run as avalia a cada 5 segundos.

CPU sempre alocada e escalonamento automático

Se você configurar o serviço do Cloud Run para ter a CPU sempre alocada, estará ciente do escalonamento para e de zero do seu modelo.

Escalonamento sempre alocado da CPU 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.

Escalonamento sempre alocado da CPU para 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

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.

É 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 é ampliada criando novas instâncias para sustentar a carga do tráfego de entrada. 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:

  • Se novas instâncias estiverem inicializando, como durante um escalonamento horizontal, as solicitações ficarão pendentes pelo menos durante o tempo médio de inicialização das instâncias de contêiner deste serviço. Isso inclui quando a solicitação inicia um escalonamento horizontal, como ao escalonar do zero.
  • Se o tempo de inicialização for menor que 10 segundos, as solicitações ficarão pendentes por até 10 segundos.
  • Se não houver instâncias no processo de inicialização e a solicitação não iniciar um escalonamento horizontal, as solicitações ficarão pendentes por até 10 segundos.

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

O Cloud Run não encerra imediatamente as instâncias depois de processar todas as solicitações. Para minimizar o impacto das inicializações a frio, o Cloud Run pode manter algumas instâncias inativas por no máximo 15 minutos. Essas instâncias estão prontas para lidar com solicitações em caso de um pico repentino de tráfego.

Por exemplo, quando uma instância termina de processar solicitações, ela pode permanecer inativa por um período caso outra solicitação precise ser processada. Uma instância inativa pode manter os recursos, como conexões de banco de dados abertas. Observe que a CPU só é alocada durante o processamento da solicitação, a menos que você configure explicitamente o serviço para que a CPU sempre seja alocada.

Para manter as instâncias inativas 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

  • Se novas instâncias estiverem inicializando, como durante um escalonamento horizontal, as solicitações ficarão pendentes pelo menos durante o tempo médio de inicialização das instâncias de contêiner deste serviço. Isso inclui quando a solicitação inicia um escalonamento horizontal, como ao escalonar do zero.
  • Se o tempo de inicialização for menor que 10 segundos, as solicitações ficarão pendentes por até 10 segundos.
  • Se não houver instâncias no processo de inicialização e a solicitação não iniciar um escalonamento horizontal, as solicitações ficarão pendentes por até 10 segundos.

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 de 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