À propos de l'autoscaling des instances dans les services Cloud Run

Cette page décrit le comportement d'autoscaling par défaut de Cloud Run. Pour une autre option de scaling vous permettant de configurer un nombre d'instances spécifique, consultez Scaling manuel.

Par défaut, chaque révision Cloud Run est automatiquement adaptée au nombre d'instances nécessaires pour traiter les requêtes entrantes, les événements ou l'utilisation du processeur. Vous pouvez également affiner ce comportement de scaling en configurant des cibles d'utilisation et de processeur personnalisées.

Lorsqu'une révision ne reçoit aucun trafic, elle est réduite par défaut à zéro instance. Vous pouvez modifier cette valeur par défaut pour spécifier qu'une instance doit rester inactive ou en attente à l'aide du paramètre nombre minimal d'instances. Si votre service utilise le processeur même lorsqu'il ne traite pas de requêtes, vous devez définir le nombre minimal d'instances sur 1.

L'autoscaler Cloud Run évalue régulièrement les métriques suivantes pour déterminer le nombre d'instances nécessaires pour diffuser le trafic :

  • Utilisation du processeur et de la simultanéité : Cloud Run ajuste le nombre d'instances pour maintenir la moyenne du processeur et de la simultanéité dans les seuils cibles.

  • Limites d'instances : Cloud Run limite le nombre d'instances entre les limites maximale et minimale que vous configurez.

Comportement de l'autoscaling horizontal des services

Cloud Run dispose de deux mécanismes d'autoscaling : le scaling basé sur les métriques et le scaling à la demande. Ils permettent de déterminer le nombre d'instances nécessaires pour traiter le trafic.

Scaling basé sur les métriques

Le scaling basé sur les métriques ajuste automatiquement le nombre d'instances en fonction de l'utilisation moyenne du processeur et des facteurs de scaling de la simultanéité moyenne des requêtes afin de fournir une capacité de diffusion stable pour votre service Cloud Run.

L'autoscaler détermine un nombre d'instances recommandé en fonction du nombre maximal d'instances qu'il calcule pour chacun des pilotes de scaling suivants, de manière indépendante :

  • Utilisation du processeur : calcule le nombre d'instances en faisant la moyenne de l'utilisation du processeur par seconde sur une période d'une minute, puis en divisant ce résultat par le nombre de processeurs par instance. Ce résultat est ensuite divisé par l'objectif de processeur.

  • Simultanéité des requêtes : calcule le nombre d'instances en faisant la moyenne de la simultanéité des requêtes par seconde sur une période d'une minute et de 10 minutes, puis en divisant ce nombre par la simultanéité maximale. Ce résultat est ensuite divisé par la cible de simultanéité des requêtes.

Pour chaque révision de service, vous pouvez configurer le nombre de processeurs par instance et la simultanéité maximale.

Cloud Run n'est pas compatible avec le scaling basé sur l'utilisation de la mémoire.

Par défaut, le scaling basé sur les métriques définit un seuil de 60 % pour les cibles d'utilisation du processeur et de simultanéité des requêtes. Vous pouvez activer les commandes de scaling (aperçu) pour spécifier des cibles personnalisées pour le processeur ou la simultanéité.

Lorsque Cloud Run effectue un scaling en fonction de l'utilisation du processeur, il tient compte de l'utilisation moyenne du processeur sur tous les processeurs alloués à une instance. Si votre application est monothreadée, mais déployée sur une instance à plusieurs processeurs, cela peut entraîner une faible utilisation moyenne, ce qui peut avoir un impact sur la façon dont les décisions de scaling basées sur le processeur sont prises. Pour en savoir plus sur l'optimisation de la configuration du processeur pour l'architecture de votre application, consultez Configurer les limites du processeur et Définir le nombre maximal de requêtes simultanées par instance.

Effectuer un scaling à la hausse

Cloud Run augmente le nombre d'instances en fonction du pilote de scaling qui en nécessite le plus. Pour éviter le démarrage et l'arrêt rapides des instances lors de variations mineures du trafic, l'autoscaler attend que l'utilisation atteigne environ 90 % de la capacité avant d'augmenter le nombre d'instances.

Vous pouvez activer les commandes de scaling (aperçu) pour passer à un modèle d'autoscaling plus précis. Dans ce modèle, l'autoscaling basé sur les métriques de Cloud Run répond précisément aux cibles que vous configurez, même pour les services avec un faible nombre d'instances. Si votre service diffère de vos configurations cibles personnalisées de plus de 10 % (seuil de tolérance), Cloud Run recommande le nombre d'instances requis pour que le pilote de scaling qui déclenche le scaling soit inférieur à la cible.

Scaling à la baisse

L'autoscaling de Cloud Run réduit le nombre d'instances en cours d'exécution lorsqu'elles ne sont plus nécessaires pour traiter le trafic entrant. Le scaling basé sur les métriques ajuste en permanence le nombre d'instances qu'il recommande en fonction de l'utilisation.

Lorsque l'utilisation moyenne du processeur ou le nombre moyen de requêtes actives diminuent, l'algorithme de scaling réduit le nombre d'instances recommandé. L'équilibreur de charge de requêtes Cloud Run tient compte de ces recommandations en acheminant de préférence les requêtes entrantes vers les instances recommandées. Les instances recommandées sont ainsi plus sollicitées, tandis que les autres instances sont inactives. Cloud Run réduit le nombre de ces instances non recommandées en leur accordant une priorité plus faible. Elles ne reçoivent donc du trafic que si toutes les instances recommandées sont occupées. Pour maintenir la stabilité, Cloud Run arrête les instances dont la priorité a été abaissée dans l'ordre suivant :

  1. Cloud Run arrête un groupe d'instances lorsque leur utilisation sur une période d'une minute est inférieure à 10 %.
  2. Un deuxième groupe d'instances reste en cours d'exécution jusqu'à ce qu'un délai d'inactivité de 15 minutes se produise, ce qui garantit la disponibilité de la capacité en cas de pic de trafic soudain.

Scaling à la demande

Cloud Run utilise le scaling à la demande lorsqu'il ne trouve pas d'instance disponible pour traiter la requête entrante. La mise à l'échelle à la demande répond en temps réel aux variations du trafic entrant sur une révision Cloud Run ou de la latence de la révision. Ce scaling tente de s'assurer que chaque requête entrante est acheminée vers une instance en peu de temps. Il s'agit du seul moteur de scaling à partir de zéro.

Étant donné que le scaling à la demande répond en temps réel aux changements soudains de trafic, Cloud Run gère le compromis entre la latence de démarrage à froid (le temps nécessaire pour démarrer une nouvelle instance) et la latence de la file d'attente (le temps pendant lequel une requête attend qu'un emplacement se libère sur une instance existante). Pour chaque requête, le système détermine si la mise en file d'attente pour une instance à venir ou une instance existante est plus rapide (dans cet ordre) avant d'essayer de démarrer une nouvelle instance à la demande. Une requête reste dans la file d'attente pendant 10 secondes maximum ou 3,5 fois le temps de démarrage à froid prévu (selon la valeur la plus élevée) avant que le système ne déclenche une nouvelle instance à la demande.

Réglage adaptatif de la simultanéité (ACT)

Cloud Run utilise le réglage adaptatif de la simultanéité (ACT, Adaptive Concurrency Tuning) pour éviter que la limitation du processeur n'entraîne une latence élevée des requêtes. Cette approche mesure l'utilisation du processeur pour chaque instance pour un nombre donné de requêtes et ajuste dynamiquement la valeur maximale des requêtes simultanées de l'instance afin de maintenir l'utilisation du processeur en dessous de 90 %. ACT ajuste la simultanéité en fonction des scénarios suivants :

  • Chaque fois que l'utilisation du processeur au cours de la dernière seconde dépasse 90 %, ACT réduit de 1 le nombre maximal de requêtes simultanées de l'instance.

  • Si l'instance atteint sa limite maximale de requêtes simultanées et que l'utilisation du processeur reste inférieure à 70 % pendant une seconde, ACT augmente de 1 le nombre maximal de requêtes simultanées pour l'instance.

  • Si vos métriques de scaling indiquent que la simultanéité n'atteint jamais le maximum que vous avez configuré, cela peut être dû au fait qu'ACT a abaissé dynamiquement le maximum réel pour protéger les performances de l'instance.

Cloud Run calcule les valeurs ACT pour chaque déploiement. Ces métriques ne sont pas conservées d'un déploiement à l'autre. Si ACT réduit la simultanéité en dessous du niveau préféré, augmentez le processeur alloué par requête simultanée maximale. Les tâches en arrière-plan qui provoquent des pics de processeur périodiques peuvent également interférer avec cette approche de scaling. Les métriques ACT ne sont pas observables.

Facturation et autoscaling basés sur les instances

Si vous configurez la facturation basée sur les instances pour votre service Cloud Run, vous devez tenir compte du scaling vers et à partir de zéro.

Scaling à partir de zéro. Le scaling à partir de zéro ne peut être déclenché que par une requête. Par conséquent, un service qui ne traite pas de requêtes ne peut pas effectuer de scaling à partir de zéro. Pour ces charges de travail, vous pouvez définir un nombre minimal d'instances supérieur à 0 ou inclure une "requête de démarrage" dans votre conception pour redémarrer le traitement après un scaling à zéro instance.

Scaling à zéro instance : Étant donné qu'aucune instance n'utilise 0 % du processeur, examiner toute l'utilisation du processeur entraînerait un scaling à zéro instance. Cela signifie que la décision de passer de un à zéro ne peut être prise qu'en vérifiant si l'instance traite une requête.

À propos du nombre maximal d'instances pour les services

Dans certains cas, vous voudrez peut-être limiter le nombre total d'instances pouvant être démarrées, pour des raisons de contrôle des coûts ou pour une meilleure compatibilité avec d'autres ressources utilisées par votre service. C'est par exemple le cas si votre service Cloud Run interagit avec une base de données qui ne peut gérer qu'un certain nombre de connexions ouvertes simultanément.

Une limite maximale d'instances est attribuée par défaut à tous les services, même si vous ne spécifiez pas votre propre limite. Définissez et surveillez cette limite pour déterminer le comportement de scaling et les coûts associés à votre service. Pour en savoir plus, consultez Limites maximales d'instances.

Le nombre maximal d'instances est un paramètre permettant de limiter le nombre total d'instances pouvant être démarrées en parallèle, comme indiqué sur la page Définir un nombre maximal d'instances.

Dépassement du nombre maximal d'instances

En temps normal, votre révision effectue un scaling horizontal en créant des instances afin de gérer la charge de trafic entrant. Toutefois, lorsque vous définissez une limite maximale du nombre d'instances, le nombre d'instances sera dans certains cas insuffisant pour répondre à cette charge de trafic. Dans ce cas, les requêtes entrantes sont mises en file d'attente (en attente) comme suit :

Les requêtes seront mises en attente pendant une durée maximale de 3,5 fois le temps de démarrage moyen des instances de conteneur de ce service, ou 10 secondes, selon la valeur la plus élevée.

Pendant ce laps de temps, si une instance termine le traitement de requêtes, elle devient disponible pour traiter les requêtes en attente. Si aucune instance ne devient disponible pendant cette période, la requête échoue avec un code d'erreur 429.

Garanties relatives au scaling

Le nombre maximal d'instances constitue une limite supérieure par révision, ce qui signifie que le nombre d'instances pour cette révision ne doit pas dépasser la valeur maximale.

En temps normal, Cloud Run peut effectuer un scaling horizontal jusqu'à la limite maximale d'instances très rapidement, afin de gérer toutes les requêtes ou événements entrants. Toutefois, si vous définissez une limite élevée, cela ne veut pas dire que votre révision pourra effectuer un scaling horizontal de façon à atteindre le nombre d'instances spécifié à un moment donné. Dans des circonstances exceptionnelles, Cloud Run peut limiter le scaling afin de garantir un service de qualité à tous les clients.

Dépassement du nombre maximal d'instances en raison de pics de trafic

Dans certains cas (comme lors d'une augmentation soudaine du trafic ou de la maintenance du système), Cloud Run peut créer, pendant une courte durée, un nombre d'instances supérieur à celui spécifié dans le paramètre du nombre maximal d'instances. Les nouvelles instances peuvent être démarrées au-delà du paramètre du nombre maximal d'instances pour remplacer les instances existantes et accorder un délai de grâce pour les requêtes en cours afin de terminer leur traitement.

La limite maximale d'instances peut être dépassée dans le cadre d'un fonctionnement normal plusieurs fois par semaine. Le délai de grâce dure généralement 15 minutes ou correspond à la valeur spécifiée dans le paramètre de délai avant expiration de la requête. Ces instances supplémentaires sont détruites dans les 15 minutes suivant leur inactivité.

Si de nombreux remplacements sont nécessaires, les mises à jour sont généralement réparties sur plusieurs minutes ou plusieurs heures, mais chaque remplacement a une instance excédentaire pendant le délai de grâce. Les instances dépassant la valeur maximale sont généralement deux fois moins nombreuses que la limite maximale d'instances configurée, mais peuvent être beaucoup plus importantes en cas de pics de trafic soudains importants.

Dans les tests de charge, un plus grand nombre d'instances dépassent le nombre maximal d'instances, car le système peut modifier l'endroit où les pics de trafic sont diffusés pour préserver la capacité des charges de travail existantes dont les modèles de charge sont soutenus.

Si votre service ne peut pas tolérer ce comportement temporaire, vous pouvez appliquer une marge de sécurité et définir une valeur maximale d'instances inférieure.

Répartition du trafic

La limite maximale du nombre d'instances étant une limite pour chaque révision, si le service répartit le trafic sur plusieurs révisions, le nombre total d'instances du service peut dépasser le nombre maximal d'instances par révision. Cette situation peut être observée dans les métriques du nombre d'instances.

Déploiements

Lorsque vous déployez une nouvelle révision pour diffuser 100% du trafic, Cloud Run démarre suffisamment d'instances de la nouvelle révision avant d'y diriger le trafic. Cela réduit l'impact des nouveaux déploiements de révisions sur la latence des requêtes, en particulier lors de la diffusion de niveaux élevés de trafic. Comme la limite maximale du nombre d'instances est une limite pour chaque révision, lors d'un déploiement, le nombre total d'instances du service peut dépasser le nombre maximal d'instances par révision. Cette situation peut être observée dans les métriques du nombre d'instances.

Instances inactives et minimisation des démarrages à froid

Pour minimiser les démarrages à froid, Cloud Run peut maintenir l'inactivité des instances pendant une certaine période après le traitement des requêtes (jusqu'à 15 minutes, ou 10 minutes pour les GPU).

Une instance inactive peut conserver des ressources, telles que des connexions de base de données ouvertes. Notez que le paramètre de facturation par défaut est la facturation basée sur les requêtes, sauf si vous configurez explicitement votre service pour une facturation basée sur les instances.

Pour vous assurer que les instances inactives restent disponibles de façon permanente, utilisez le paramètre min-instance. Notez que l'utilisation de cette fonctionnalité entraîne des frais, même si le service ne diffuse pas activement de requêtes.

Autoscaling et requêtes en attente

Les requêtes seront mises en attente pendant une durée maximale de 3,5 fois le temps de démarrage moyen des instances de conteneur de ce service, ou 10 secondes, selon la valeur la plus élevée.

Impact de l'autoscaling sur les services externes

Étant donné que le nombre d'instances augmente automatiquement, votre service Cloud Run peut rencontrer des limites avec ses services externes. Par exemple, Cloud SQL a une limite de quota d'API. Assurez-vous que ces services externes disposent d'un quota suffisant et peuvent gérer les connexions à partir de toutes les instances de votre service Cloud Run. Envisagez de définir un nombre maximal d'instances pour éviter de surcharger les services externes.

Autoscaling et Pub/Sub

Google recommande d'utiliser des abonnements push pour consulter les messages d'un sujet Pub/Sub sur Cloud Run. Les messages envoyés sont reçus comme des requêtes HTTP par le conteneur, déclenchant ainsi le même comportement d'autoscaling.

Autoscaling et conteneurs multiples (side-cars)

Cloud Run prend en compte l'utilisation du processeur des instances pour l'autoscaling. L'utilisation du processeur d'une instance correspond au pourcentage de processeur alloué qui est utilisé.

Notez que vous allouez du processeur lorsque vous définissez des limites de processeur au niveau du conteneur. Si vous utilisez plusieurs conteneurs par instance, l'allocation de processeur réelle pour cette instance correspond à la somme des limites de processeur que vous avez définies pour chaque conteneur.

Étapes suivantes