Acerca do dimensionamento automático de instâncias nos serviços do Cloud Run

Esta página descreve o comportamento de escalabilidade automática predefinido do Cloud Run. Se precisar de mais controlo sobre o comportamento de escalonamento, saiba mais sobre a opção de escalonamento alternativa, o escalonamento manual.

Por predefinição, cada revisão do Cloud Run é dimensionada automaticamente para o número de instâncias necessárias para processar todos os pedidos, eventos ou utilização da CPU recebidos.

Quando uma revisão não recebe tráfego, por predefinição, é reduzida para zero instâncias. No entanto, se necessário, pode alterar esta predefinição para especificar uma instância a manter inativa ou "ativa" através da definição minimum instances. Se estiver a usar a CPU fora dos pedidos, deve definir o número mínimo de instâncias igual a 1.

Além da taxa de pedidos recebidos, eventos ou utilização da CPU, o número de instâncias agendadas é afetado pelos seguintes fatores:

O escalador automático do Cloud Run avalia-os periodicamente.

Faturação e escalabilidade automática baseadas em instâncias

Se configurar a faturação baseada em instâncias para o seu serviço do Cloud Run, deve ter em atenção o comportamento de escalabilidade para e a partir de zero.

Escalabilidade a partir do zero. O escalamento a partir de zero só pode ser acionado por um pedido, pelo que um serviço que não esteja a processar pedidos não pode ser escalado a partir de zero. Para estas cargas de trabalho, pode definir instâncias mínimas > 0 ou incluir um "pedido de ativação" no seu design para reiniciar o processamento após o escalonamento para zero.

Escalabilidade para zero. Uma vez que nenhuma instância está alguma vez a 0% da CPU, analisar toda a utilização da CPU nunca resultaria numa redução para zero. Isto significa que a decisão de dimensionar de um para zero só pode ser tomada verificando se a instância está a processar um pedido.

Acerca do número máximo de instâncias

Em alguns casos, pode querer limitar o número total de instâncias que podem ser iniciadas por motivos de controlo de custos ou para uma melhor compatibilidade com outros recursos usados pelo seu serviço. Por exemplo, o seu serviço do Cloud Run pode interagir com uma base de dados que só consegue processar um determinado número de ligações abertas em simultâneo.

Pode usar a definição de instâncias máximas para limitar o número total de instâncias que podem ser iniciadas em paralelo, conforme documentado no artigo Definir um número máximo de instâncias.

Excede o número máximo de instâncias

Em circunstâncias normais, a sua revisão é dimensionada horizontalmente através da criação de novas instâncias para processar a carga de tráfego recebida. No entanto, quando define um limite máximo de instâncias, em alguns cenários, existem instâncias insuficientes para satisfazer essa carga de tráfego. Nesse caso, os pedidos recebidos são colocados em fila de espera (pendentes) da seguinte forma:

Os pedidos ficam pendentes até 3, 5 vezes o tempo de arranque médio das instâncias de contentores deste serviço ou 10 segundos, consoante o que for superior.

Durante este período, se uma instância terminar de processar pedidos, fica disponível para processar os pedidos pendentes em fila. Se não ficarem disponíveis instâncias durante o período, o pedido falha com um código de erro 429.

Garantias de escalabilidade

O limite máximo de instâncias é um limite superior por revisão e significa que o número de instâncias para esta revisão não deve exceder o máximo.

Em circunstâncias normais, o Cloud Run consegue aumentar a escala até ao limite máximo de instâncias muito rapidamente para processar todos os pedidos ou eventos recebidos. No entanto, a definição de um limite elevado não significa que a sua revisão possa ser expandida para o número especificado de instâncias em qualquer momento. Em circunstâncias excecionais, o Cloud Run pode limitar o escalamento para garantir um bom serviço para todos os clientes.

Exceder o número máximo de instâncias devido a picos de tráfego

Em alguns casos, como picos de tráfego rápidos ou manutenção do sistema, o Cloud Run pode, durante um curto período, criar mais instâncias do que as especificadas na definição de instâncias máximas. É possível iniciar novas instâncias acima da definição de instâncias máximas para substituir as instâncias existentes e oferecer um período de tolerância para que os pedidos em curso terminem o processamento.

O limite máximo de instâncias pode ser excedido no funcionamento normal algumas vezes por semana. Normalmente, o período de tolerância dura até 15 minutos ou até ao valor especificado na definição de tempo limite do pedido. Estas instâncias adicionais são destruídas no prazo de 15 minutos após ficarem inativas.

Se forem necessárias muitas substituições, as atualizações são normalmente distribuídas ao longo de vários minutos ou horas, mas cada substituição tem uma instância em excesso apenas durante o período de tolerância. Normalmente, as instâncias que excedem o valor máximo de instâncias são inferiores ao dobro do limite máximo de instâncias configurado, mas podem ser muito superiores em picos de tráfego grandes e súbitos.

Os testes de carga têm mais instâncias a exceder a definição de instâncias máximas porque o sistema pode alterar o local onde os picos de tráfego são publicados para preservar a capacidade das cargas de trabalho existentes que têm padrões de carga sustentados.

Se o seu serviço não tolerar este comportamento temporário, é aconselhável ter em conta uma margem de segurança e definir um valor de instâncias máximo inferior.

Divisões de tráfego

Uma vez que o limite máximo de instâncias é um limite para cada revisão, se o serviço dividir o tráfego por várias revisões, o número total de instâncias do serviço pode exceder o número máximo de instâncias por revisão. Isto pode ser observado nas métricas de contagem de instâncias.

Implementações

Quando implementa uma nova revisão para publicar 100% do tráfego, o Cloud Run inicia instâncias suficientes da nova revisão antes de direcionar o tráfego para a mesma. Isto reduz o impacto das implementações de novas revisões nas latências de pedidos, especialmente quando serve níveis elevados de tráfego. Uma vez que o limite máximo de instâncias é um limite para cada revisão, durante uma implementação, o número total de instâncias do serviço pode exceder o número máximo de instâncias por revisão. Isto pode ser observado nas métricas de contagem de instâncias.

Instâncias inativas e minimização dos inícios a frio

O Cloud Run não encerra imediatamente as instâncias assim que estas tiverem processado todos os pedidos. Para minimizar o impacto dos inícios a frio, o Cloud Run pode manter algumas instâncias inativas durante um máximo de 15 minutos. Os recursos do Cloud Run com GPUs ativadas podem manter algumas instâncias inativas durante um máximo de 10 minutos. Estas instâncias estão prontas para processar pedidos em caso de um pico de tráfego repentino.

Por exemplo, quando uma instância termina de processar pedidos, pode permanecer inativa durante algum tempo caso seja necessário processar outro pedido. Uma instância inativa pode manter recursos, como ligações de base de dados abertas. Tenha em atenção que a predefinição de faturação é a faturação baseada em pedidos, a menos que configure explicitamente o seu serviço para ter faturação baseada em instâncias.

Para manter as instâncias inativas permanentemente disponíveis, use a definição min-instance. Tenha em atenção que a utilização desta funcionalidade incorre em custos, mesmo quando o serviço não está a publicar ativamente pedidos.

Ajuste de escala automático e pedidos pendentes

Os pedidos ficam pendentes até 3, 5 vezes o tempo de arranque médio das instâncias de contentores deste serviço ou 10 segundos, consoante o que for superior.

Impacto do dimensionamento automático nos serviços de apoio

À medida que o número de instâncias aumenta automaticamente, o seu serviço do Cloud Run pode encontrar limites com os respetivos serviços de apoio. Por exemplo, o Cloud SQL tem um limite de quota da API. Certifique-se de que estes serviços de apoio têm quota suficiente e conseguem processar ligações de todas as instâncias do seu serviço do Cloud Run. Considere definir um número máximo de instâncias para evitar a sobrecarga dos serviços de apoio.

Escala automática e Pub/Sub

A Google recomenda a utilização de subscrições push para consumir mensagens de um tópico do Pub/Sub no Cloud Run. As mensagens enviadas por push são recebidas como pedidos HTTP pelo contentor, o que aciona o mesmo comportamento de escalamento automático.

Dimensionamento automático e vários contentores (sidecars)

O Cloud Run considera a utilização da CPU das instâncias para a escala automática, em que a utilização da CPU de uma instância é a percentagem da CPU alocada em utilização.

Tenha em atenção que atribui CPU quando define limites de CPU ao nível do contentor. Se usar vários contentores por instância, a atribuição real de CPU para essa instância é a soma dos limites de CPU que definir em cada contentor.

O que se segue?