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

Dans Cloud Run, chaque révision est automatiquement mise à l'échelle au nombre d'instances nécessaires pour traiter toutes les requêtes entrantes, tous les événements ou l'intégralité de l'utilisation de processeur.

Lorsqu'une révision ne reçoit aucun trafic, elle est réduite par défaut à zéro instance. Toutefois, si vous le souhaitez, 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 vous utilisez un processeur en dehors des requêtes, vous devez définir le nombre minimal d'instances sur 1.

Outre le taux de requêtes entrantes, les événements ou l'utilisation de processeur, le nombre d'instances planifiées est affecté par :

L'autoscaler Cloud Run les évalue toutes les cinq secondes.

Allocation systématique de processeur et autoscaling

Si vous configurez votre service Cloud Run pour qu'il dispose d'une allocation systématique de processeur, vous devez tenir compte du scaling vers et à partir de zéro.

Scaling à partir de zéro du processeur toujours alloué. 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 vers zéro du processeur toujours alloué. É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

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.

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 :

  • Si les nouvelles instances démarrent, par exemple lors d'une évolutivité horizontale, les requêtes seront mises en attente pendant au moins le temps de démarrage moyen des instances de conteneur de ce service. Cela inclut le moment où la requête lance un scaling horizontal, par exemple lors d'un scaling à partir de zéro.
  • Si le temps de démarrage est inférieur à 10 secondes, les requêtes sont mises en attente pendant une durée maximale de 10 secondes.
  • Si aucune instance n'est en cours de démarrage et que la requête n'initie pas de scaling horizontal, les requêtes seront mises en attente pendant une durée maximale de 10 secondes.

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

Cloud Run n'arrête pas immédiatement les instances une fois que toutes les requêtes ont été traitées. Pour minimiser l'impact des démarrages à froid, Cloud Run peut conserver certaines instances inactives pour une durée maximale de 15 minutes. Ces instances sont prêtes à traiter les requêtes en cas d'augmentation soudaine du trafic.

Par exemple, lorsqu'une instance a fini de traiter des requêtes, elle peut rester inactive pendant un certain temps au cas où une autre requête devrait être traitée. Une instance inactive peut conserver des ressources, telles que des connexions de base de données ouvertes. Notez que le processeur n'est alloué que pendant le traitement des requêtes, sauf si vous configurez explicitement votre service pour une allocation systématique du processeur.

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

  • Si les nouvelles instances démarrent, par exemple lors d'une évolutivité horizontale, les requêtes seront mises en attente pendant au moins le temps de démarrage moyen des instances de conteneur de ce service. Cela inclut le moment où la requête lance un scaling horizontal, par exemple lors d'un scaling à partir de zéro.
  • Si le temps de démarrage est inférieur à 10 secondes, les requêtes sont mises en attente pendant une durée maximale de 10 secondes.
  • Si aucune instance n'est en cours de démarrage et que la requête n'initie pas de scaling horizontal, les requêtes seront mises en attente pendant une durée maximale de 10 secondes.

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 tient compte de l'utilisation du processeur des instances pour l'autoscaling. L'utilisation du processeur d'une instance correspond au pourcentage de processeur alloué utilisé.

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

Étape suivante