Dans Cloud Run, chaque révision est automatiquement adaptée au nombre d'instances nécessaires pour traiter toutes les requêtes entrantes.
Plus il y a d'instances qui traitent des requêtes, plus le nombre de ressources processeur et mémoire utilisées augmente, ce qui entraîne des coûts plus élevés.
Pour vous offrir davantage de contrôle, Cloud Run fournit un paramètre nombre maximal de requêtes simultanées par instance qui spécifie le nombre maximal de requêtes pouvant être traitées simultanément par une instance donnée.
Nombre maximal de requêtes simultanées par instance
Vous pouvez configurer le nombre maximal de requêtes simultanées par instance. Vous pouvez l'augmenter jusqu'à 1 000. Par défaut, les instances Cloud Run déployées à l'aide de Google Cloud CLI ou de Terraform ont une simultanéité maximale égale à 80 fois le nombre de processeurs virtuels. Cette valeur par défaut ne s'applique qu'à la création d'un service. Elle ne s'applique pas aux déploiements ultérieurs d'une révision. Les instances Cloud Run déployées à l'aide de la console Google Cloud ont une simultanéité par défaut de 80.
Bien que vous deviez utiliser la valeur par défaut, vous pouvez réduire la simultanéité maximale si nécessaire. Par exemple, si votre code ne peut pas traiter les requêtes parallèles, définissez la simultanéité sur 1.
La valeur de simultanéité spécifiée est une limite maximale. Si le processeur d'une instance est déjà très sollicité, Cloud Run peut décider de limiter à une valeur inférieure le nombre de requêtes à envoyer à cette instance. Dans ce cas, l'instance Cloud Run peut indiquer que la simultanéité maximale n'est pas utilisée. Par exemple, si l'utilisation élevée du processeur est soutenue, le nombre d'instances peut augmenter à la place.
Le schéma suivant montre comment le paramètre de nombre maximal de requêtes simultanées par instance affecte le nombre d'instances nécessaires pour gérer les requêtes simultanées entrantes :
Ajuster la simultanéité pour l'autoscaling et l'utilisation des ressources
Ajuster la simultanéité maximale par instance a une incidence considérable sur la façon dont votre service évolue et utilise les ressources.
- Simultanéité plus faible : force Cloud Run à utiliser plus d'instances pour le même volume de requêtes, car chaque instance gère moins de requêtes. Cela peut améliorer la réactivité des applications qui ne sont pas optimisées pour un parallélisme interne élevé ou des applications que vous souhaitez mettre à l'échelle plus rapidement en fonction de la charge de requêtes.
- Simultanéité plus élevée : permet à chaque instance de traiter davantage de requêtes, ce qui peut réduire le nombre d'instances actives et les coûts. Cette option convient aux applications efficaces pour les tâches parallèles liées aux E/S ou aux applications qui peuvent réellement utiliser plusieurs processeurs virtuels pour le traitement simultané des requêtes.
Commencez par la simultanéité par défaut, surveillez de près les performances et l'utilisation de votre application, et ajustez-les si nécessaire.
Simultanéité avec les instances à plusieurs processeurs virtuels
Le réglage de la simultanéité est particulièrement important si votre service utilise plusieurs vCPU, mais que votre application est monothread ou effectivement monothread (lié au processeur).
- Points chauds de vCPU : une application monothread sur une instance à plusieurs vCPU peut saturer un vCPU tandis que les autres sont inactifs. L'autoscaler de processeur Cloud Run mesure l'utilisation moyenne du processeur sur tous les processeurs virtuels. Dans ce scénario, l'utilisation moyenne du processeur peut rester étonnamment faible, ce qui empêche un scaling efficace basé sur le processeur.
- Utiliser la simultanéité pour le scaling : si l'autoscaling basé sur le processeur est inefficace en raison de points chauds de processeur virtuel, la réduction de la simultanéité maximale devient un outil important. Les points chauds de processeur virtuel se produisent souvent lorsque plusieurs processeurs virtuels sont choisis pour une application à thread unique en raison de besoins élevés en mémoire. L'utilisation de la simultanéité pour le scaling force le scaling en fonction du débit des requêtes. Cela permet de démarrer davantage d'instances pour gérer la charge, ce qui réduit la mise en file d'attente et la latence par instance.
Quand limiter l'accès simultané maximal à une requête à la fois
Vous pouvez limiter la simultanéité de sorte qu'une seule requête à la fois soit envoyée à chaque instance en cours d'exécution. Vous devriez envisager de le faire dans les cas suivants :
- Lorsque chaque requête utilise la majeure partie du processeur ou de la mémoire disponible.
- Lorsque votre image de conteneur n'est pas conçue pour traiter plusieurs requêtes simultanément, par exemple si votre conteneur repose sur un état global qui deux requêtes ne peuvent pas partager.
Sachez qu'une simultanéité de 1 risque d'affecter négativement les performances de scaling, car le traitement d'un pic de requêtes entrantes nécessitera le démarrage de nombreuses instances. Pour en savoir plus, consultez Compromis entre débit, latence et coûts.
Étude de cas
Les métriques suivantes illustrent un cas d'utilisation dans lequel 400 clients envoient trois requêtes par seconde à un service Cloud Run dont le nombre maximal de requêtes simultanées est défini sur 1. La courbe verte en haut représente le nombre de requêtes au fil du temps. La courbe bleue en bas représente le nombre d'instances démarrées afin de traiter les requêtes.
Les métriques suivantes illustrent un cas d'utilisation dans lequel 400 clients envoient trois requêtes par seconde à un service Cloud Run dont le nombre maximal de requêtes simultanées est défini sur 80. La courbe verte en haut représente le nombre de requêtes au fil du temps. La courbe bleue en bas représente le nombre d'instances démarrées afin de traiter les requêtes. Notez que beaucoup moins d'instances sont nécessaires pour gérer le même volume de requêtes.
Simultanéité pour les déploiements de code source
Lorsque la simultanéité est activée, Cloud Run ne fournit pas d'isolation entre les requêtes simultanées traitées par la même instance. Dans de tels cas, vous devez vous assurer que votre code peut s'exécuter en toute sécurité simultanément. Vous pouvez modifier ce paramètre en définissant une autre valeur de simultanéité. Nous vous recommandons de commencer par une simultanéité modérée, définie par exemple sur la valeur 8, puis de l'augmenter progressivement. Le fait de commencer avec une simultanéité trop élevée peut entraîner un comportement inattendu en raison des contraintes exercées sur les ressources (telles que la mémoire ou le processeur).
Les runtimes de langage peuvent également avoir un impact sur la simultanéité. Voici quelques exemples d'impacts spécifiques à une langue :
Node.js est intrinsèquement monothread. Pour profiter de la simultanéité, utilisez le style de code asynchrone de JavaScript, qui est idiomatique dans Node.js. Pour en savoir plus, consultez la page Contrôle de flux asynchrone dans la documentation officielle de Node.js.
Pour Python 3.8 et versions ultérieures, la prise en charge d'une simultanéité élevée par instance nécessite suffisamment de threads pour gérer la simultanéité. Nous vous recommandons de définir une variable d'environnement d'exécution afin que la valeur des threads soit égale à la valeur de la simultanéité. Par exemple :
THREADS=8.
Étape suivante
Pour gérer le nombre maximal de requêtes simultanées par instance de vos services Cloud Run, consultez la page Définir le nombre maximal de requêtes simultanées par instance.
Pour optimiser le nombre maximal de requêtes simultanées par instance, consultez les conseils de développement pour le réglage de la simultanéité.