Allocation du processeur (services)

Par défaut, l'allocation de processeur aux instances Cloud Run ne se fait que lors du traitement des requêtes et du démarrage et de l'arrêt des conteneurs (reportez-vous à la section Cycle de vie de l'instance). Vous pouvez modifier ce comportement de sorte que le processeur soit toujours alloué et disponible même en l'absence de requêtes entrantes. Il peut être utile de définir l'allocation systématique du processeur pour exécuter des tâches de courte durée en arrière-plan et d'autres tâches de traitement asynchrones.

Même si le processeur est toujours alloué, l'autoscaling Cloud Run est toujours appliqué et peut mettre fin aux instances si elles ne sont pas nécessaires pour gérer le trafic entrant ou l'utilisation actuelle de processeur sans lien avec les requêtes. Une instance ne reste jamais inactive plus de 15 minutes après le traitement d'une requête, sauf si elle reste active en utilisant un nombre minimal d'instances.

Combiner le processeur toujours alloué avec un certain nombre minimal d'instances résulte en l'exécution d'un certain nombre d'instances avec un accès complet aux ressources de processeur, ce qui permet des cas d'utilisation du traitement en arrière-plan. Lorsque vous utilisez ce modèle, Cloud Run applique l'autoscaling des instances même si un service utilise un processeur sans lien avec les requêtes.

Si vous utilisez des vérifications d'état, le processeur est alloué à chaque vérification. Reportez-vous aux vérifications de l'état des conteneurs pour plus d'informations sur la facturation.

Impact sur les tarifs

Si vous choisissez de n'allouer le processeur que lors du traitement des requêtes, vous êtes facturé par requête et seulement lorsque l'instance traite une requête. Si vous choisissez le paramètre CPU toujours alloué, le cycle de vie complet de l'instance vous est facturé. Pour en savoir plus, consultez les grilles tarifaires de Cloud Run.

L'outil de recommandation de Google examine automatiquement le trafic reçu par votre service Cloud Run au cours du mois passé et recommande de passer du processeur alloué lors du traitement des requêtes au processeur toujours alloué, si cela est moins cher.

Choisir la bonne allocation de processeurs

Le choix de l'allocation de processeurs adaptée à votre cas d'utilisation dépend de plusieurs facteurs, tels que les modèles de trafic, l'exécution en arrière-plan et les coûts, chacun d'entre eux étant décrit dans les sections suivantes.

Remarques concernant les modèles de trafic

• L'utilisation d'un processeur uniquement lors du traitement des requêtes est recommandée lorsque le trafic entrant est sporadique, intensif ou irrégulier.
• L'utilisation d'un processeur toujours alloué est recommandée lorsque le trafic entrant est constant et varie lentement.

Considérations sur l'exécution en arrière-plan

La sélection de Processeur toujours alloué vous permet d'exécuter des tâches de courte durée en arrière-plan et d'effectuer d'autres tâches de traitement asynchrone après avoir renvoyé des réponses. Exemple :

• Exploiter des agents de surveillance tels qu'OpenTelemetry, qui peuvent supposer qu'ils peuvent s'exécuter en arrière-plan
• Utiliser les goroutines Go, asynchrones Node.js, les threads Java et les coroutines Kotlin
• Utilisation de frameworks d'application qui reposent sur des fonctionnalités de planification et d'arrière-plan intégrées

Les instances inactives, y compris celles qui sont gardées en attente en utilisant un nombre minimal d'instances, peuvent être arrêtées à tout moment. Si vous devez terminer des tâches en cours avant l'arrêt du conteneur, vous pouvez intercepter le signal SIGTERM pour accorder un délai de grâce de 10 secondes à une instance avant son arrêt.

Envisagez d'utiliser Cloud Tasks pour exécuter des tâches asynchrones. Cloud Tasks relance automatiquement les tâches ayant échoué et accepte des temps d'exécution allant jusqu'à 30 minutes.

Considérations liées au coût

Si vous utilisez actuellement le processeur uniquement alloué pendant le traitement des requêtes, le processeur toujours alloué est probablement plus économique dans les cas suivants :

• Votre service Cloud Run traite un grand nombre de requêtes en cours à un rythme relativement régulier.
• Vous ne voyez pas beaucoup d'instances "inactives" lorsque vous consultez la métrique de comptage d'instances.

Vous pouvez utiliser le simulateur de coût pour estimer les différences de coût.

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 à zéro instance 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.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer et déployer des services Cloud Run, demandez à votre administrateur de vous accorder les rôles IAM suivants :

• Développeur Cloud Run (roles/run.developer) sur le service Cloud Run
• Utilisateur du compte de service (roles/iam.serviceAccountUser) sur l'identité du service

Pour obtenir la liste des rôles et des autorisations IAM associés à Cloud Run, consultez les sections Rôles IAM Cloud Run et Autorisations IAM Cloud Run. Si votre service Cloud Run communique avec les API Google Cloud, telles que les bibliothèques clientes Cloud, consultez le guide de configuration de l'identité du service. Pour en savoir plus sur l'attribution de rôles, consultez les sections Autorisations de déploiement et Gérer les accès.

Définir et mettre à jour l'allocation du processeur

Tout changement de configuration entraîne la création d'une révision. Les révisions ultérieures obtiennent aussi automatiquement le même paramètre de configuration, à moins que vous ne le mettiez explicitement à jour.

Si vous choisissez l'option de processeur toujours alloué, vous devez spécifier au moins 512 Mio de mémoire.

Par défaut, le processeur n'est alloué que pendant le traitement des requêtes pour chaque instance de conteneur. Vous pouvez modifier cette valeur par défaut à l'aide de la console Google Cloud, de la ligne de commande gcloud ou d'un fichier YAML lorsque vous créez un service ou déployez une nouvelle révision :

gcloud run services update SERVICE --no-cpu-throttling 

gcloud run services update SERVICE --cpu-throttling 

gcloud run deploy --image IMAGE_URL --no-cpu-throttling

gcloud run deploy --image IMAGE_URL --cpu-throttling

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-cpu-allocation"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
      resources {
        # If true, garbage-collect CPU when once a request finishes
        cpu_idle = false
      }
    }
  }
}

Afficher les paramètres d'allocation de processeur

Pour afficher les paramètres actuels d'allocation de processeur pour votre service Cloud Run, procédez comme suit :