Paramètres de facturation des services

Cette page décrit les paramètres de facturation en supposant que le comportement d'autoscaling par défaut de Cloud Run est utilisé. Pour en savoir plus sur l'utilisation de l'autoscaling manuel, consultez Comportement de facturation avec l'autoscaling manuel.

Il existe deux paramètres de facturation dans les services Cloud Run :

  • Facturation basée sur les requêtes (par défaut) : les instances de service Cloud Run ne sont facturées que lorsqu'elles traitent des requêtes, lorsqu'elles démarrent et lorsqu'elles s'arrêtent. Pour en savoir plus, consultez Cycle de vie des instances. Ce paramètre s'appelait auparavant Processeur alloué uniquement lors du traitement des requêtes.

  • Facturation basée sur les instances : les instances de service Cloud Run sont facturées pour l'intégralité du cycle de vie de chaque instance, même lorsqu'il n'y a aucune requête entrante. La facturation basée sur les instances peut être utile pour exécuter des tâches de courte durée en arrière-plan et d'autres tâches de traitement asynchrones. Ce paramètre s'appelait auparavant Processeur toujours alloué.

Si vous choisissez la facturation basée sur les requêtes, vous êtes facturé par requête et seulement lorsque l'instance traite une requête. Si vous choisissez la facturation basée sur les instances, 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 examine automatiquement le trafic reçu par votre service Cloud Run au cours du mois passé et recommande de passer de la facturation basée sur les requêtes à la facturation basée sur les instances, si cela est moins cher.

Contrairement aux services Cloud Run, tous les jobs Cloud Run utilisent la facturation basée sur les instances. Les pools de nœuds de calcul Cloud Run et les instances Cloud Run sont également facturés pour l'ensemble du cycle de vie de chaque instance à l'aide de leurs propres SKU de tarification dédiés. Pour comparer les types de ressources, consultez Comparaison des ressources Cloud Run.

Impact de l'allocation de processeur

La sélection d'un paramètre de facturation a un impact sur l'allocation du processeur.

  • Avec la facturation basée sur les requêtes, le processeur n'est alloué que lors du traitement des requêtes.
  • Avec la facturation basée sur les instances, le processeur est alloué pendant tout le cycle de vie de l'instance de conteneur.

Plafonds de dépenses du budget

Lorsque vous configurez des plafonds de dépenses pour les budgets Cloud Billing dans la console Cloud Billing ou de manière programmatique à l'aide de l'API Cloud Billing Budget, ces plafonds s'appliquent automatiquement à tous les types de ressources Cloud Run de votre projet.

Vous pouvez surveiller la progression de votre plafond de dépenses directement depuis la page de présentation de la console Cloud Run. Lorsque vous atteignez un plafond de dépenses, Google Cloud met en pause toutes les charges de travail Cloud Run pour éviter des frais supplémentaires sur les ressources Cloud Run suivantes :

  • Services : les services existants ne pourront pas diffuser de trafic et renverront des erreurs 5xx.
  • Jobs : les nouvelles exécutions de tâches ne démarrent pas et les tâches en cours ne se terminent pas.
  • Pools de nœuds de calcul : toutes les instances existantes cessent de traiter les tâches.
  • Instances : toutes les instances en cours d'exécution s'arrêtent, les nouvelles instances ou les redémarrages ne démarrent pas, et les requêtes envoyées aux URL d'instance renvoient des erreurs 5xx.

Si vous dépassez votre plafond de dépenses, vous recevrez une notification d'alerte et une bannière d'application s'affichera dans la console Cloud Run. Les plafonds de dépenses appliqués sont réinitialisés au début de chaque mois, le premier jour du cycle de facturation suivant. Cela débloque vos charges de travail et remet le montant des dépenses à zéro. Si vous dépassez votre plafond de dépenses et que vous souhaitez reprendre les opérations avant la réinitialisation mensuelle, ajustez ou supprimez manuellement le plafond sur la page de présentation de la console Cloud Run.

Choisir le bon paramètre de facturation

Le choix du paramètre de facturation adapté à 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

  • La facturation basée sur les requêtes est recommandée lorsque le trafic entrant est sporadique, irrégulier ou présente des pics.
  • La facturation basée sur les instances est recommandée lorsque le trafic entrant est stable et varie lentement.

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

La sélection de la facturation basée sur les instances alloue le processeur même en dehors du traitement des requêtes, ce qui 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.

Si votre charge de travail nécessite une seule instance de longue durée qui s'exécute en continu pendant des heures ou des jours sans autoscaling horizontal, déployez une instance Cloud Run au lieu d'un service. Contrairement aux instances de service, qui sont réduites après au plus 15 minutes d'inactivité, une instance Cloud Run peut s'exécuter sans interruption pendant sept jours maximum et accepte des règles de redémarrage configurables. Les instances Cloud Run sont donc bien adaptées aux agents IA personnels, aux moteurs de workflow avec état et aux environnements de développement à distance. Pour en savoir plus, consultez Quand utiliser des instances Cloud Run et Cycle de vie des instances Cloud Run.

Considérations liées au coût

Si vous utilisez la facturation basée sur les requêtes, la facturation basée sur les instances peut être plus économique si :

  • 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.

Si vous n'avez besoin que d'une seule instance en cours d'exécution en continu sans autoscaling horizontal, une instance Cloud Run peut coûter moins cher qu'un service avec un nombre minimal d'instances et une facturation basée sur les instances. Les instances Cloud Run ont leurs propres SKU de tarification et sont compatibles avec un modèle de processeur partagé avec capacité de burst (vCPU de référence de 6,25% avec burst jusqu'à 100%), ce qui réduit les coûts continus pour les charges de travail singleton principalement inactives.

Considérations relatives à l'autoscaling

Par défaut, Cloud Run effectue l'autoscaling du nombre d'instances de conteneur.

Pour un service défini sur facturation basée sur les requêtes, Cloud Run effectue l'autoscaling du nombre d'instances en fonction de l'utilisation du processeur uniquement pendant le traitement des requêtes.

Pour un service défini sur facturation à l'instance, Cloud Run effectue l'autoscaling du nombre d'instances en fonction de l'utilisation du processeur pour tout le cycle de vie de l'instance de conteneur, sauf lors du scaling vers et à partir de zéro, où il utilise uniquement les requêtes.

Consultez la section Scaling manuel pour en savoir plus si vous utilisez le scaling manuel au lieu de la fonctionnalité d'autoscaling de Cloud Run.

Remarques sur la facturation basée sur les instances

Même si le paramètre de facturation est défini sur Facturation basée sur les instances, 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 la facturation basée sur les instances 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.

Utilisez un service avec facturation basée sur les instances et un nombre minimal d'instances lorsque votre charge de travail en arrière-plan ou agentive doit effectuer un autoscaling au-delà d'une seule instance pendant les pics de charge. Pour d'autres modèles d'arrière-plan, consultez les ressources Cloud Run suivantes :

  • Charges de travail de longue durée à instance unique : utilisez une instance Cloud Run si vous n'avez besoin que d'une seule instance avec un contrôle direct du cycle de vie (démarrage, arrêt et redémarrage) et sans autoscaling.
  • Charges de travail non HTTP basées sur l'extraction : utilisez un pool de nœuds de calcul Cloud Run pour les consommateurs en arrière-plan continus, tels que les nœuds de calcul Pub/Sub ou Kafka, qui ne nécessitent pas de point de terminaison HTTP.

Si vous utilisez des vérifications d'état, vous devez utiliser la facturation à l'instance pour chaque vérification. Reportez-vous aux vérifications de l'état des conteneurs pour plus d'informations sur la facturation.

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 :

Si vous déployez un service ou une fonction à partir du code source, vous devez également disposer de rôles supplémentaires sur votre projet et votre compte de service Cloud Build.

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 APIGoogle 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 pages Autorisations de déploiement et Gérer les accès.

Définir et mettre à jour la facturation

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 sélectionnez la facturation basée sur les instances, vous devez spécifier au moins 512 Mio de mémoire.

Vous pouvez modifier le paramètre de facturation à l'aide de la console Google Cloud , de la gcloud CLI ou d'un fichier YAML lorsque vous créez un service ou déployez une nouvelle révision :

Console

  1. Dans la console Google Cloud , accédez à Cloud Run :

    Accédez à Cloud Run

  2. Sélectionnez Services dans le menu de navigation Cloud Run, puis cliquez sur Déployer un conteneur pour configurer un nouveau service. Si vous configurez un service existant, cliquez sur celui-ci.

  3. Si vous configurez un nouveau service, remplissez la page initiale des paramètres du service.

  4. Si vous configurez un service existant, cliquez sur l'onglet Scaling.

  5. Sous Facturation, sélectionnez Basée sur les requêtes pour que vos instances ne soient facturées que pendant le traitement des requêtes, ou sélectionnez Basée sur les instances pour que vos instances soient facturées pendant toute leur durée de vie.

  6. Cliquez sur Créer pour un nouveau service. Cliquez sur Afficher les différences et redéployer, puis sur Déployer les modifications pour un service existant.

gcloud

Vous pouvez modifier le paramètre de facturation. Pour définir la facturation basée sur les instances pour un service donné :

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

Remplacez SERVICE par le nom du service.

Pour définir la facturation basée sur les requêtes :

gcloud run services update SERVICE --cpu-throttling

Vous pouvez également définir votre paramètre de facturation lors du déploiement. Pour définir votre paramètre de facturation sur la facturation basée sur les instances, procédez comme suit :

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

Pour définir votre paramètre de facturation sur la facturation basée sur les requêtes :

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

Remplacez IMAGE_URL par une référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL respecte le format LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.

YAML

  1. Si vous créez un service, ignorez cette étape. Si vous mettez à jour un service existant, téléchargez sa configuration YAML :

    gcloud run services describe SERVICE --format export > service.yaml

  2. Mettez à jour l'attribut cpu :

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/cpu-throttling: 'BOOLEAN'
      name: REVISION

    Remplacez les éléments suivants :

    • SERVICE : nom de votre service Cloud Run.
    • BOOLEAN : true pour définir la facturation basée sur les requêtes, ou false pour définir la facturation basée sur les instances.
    • REVISION : un nouveau nom de révision ou supprimez-le (le cas échéant). Si vous indiquez un nouveau nom de révision, il doit répondre aux critères suivants :
      • Commencer par SERVICE-
      • Ne contenir que des lettres minuscules, des chiffres et -
      • Ne pas se terminer par -
      • Ne pas dépasser 63 caractères

  3. Créez ou mettez à jour le service à l'aide de la commande suivante :

    gcloud run services replace service.yaml

    Par défaut, la commande gcloud run services replace utilise le fichier service.yaml s'il est présent.

Terraform

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez Commandes Terraform de base.

Ajoutez les éléments suivants à une ressource google_cloud_run_v2_service dans votre configuration Terraform :

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

  deletion_protection = false # set to "true" in production

  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 de facturation

Pour afficher les paramètres de facturation actuels de votre service Cloud Run :

Console

  1. Dans la console Google Cloud , accédez à la page Services de Cloud Run :

    Accédez à Cloud Run

  2. Cliquez sur le service pour ouvrir la page Informations sur le service.

  3. Cliquez sur l'onglet Scaling (Scaling) pour trouver le paramètre Billing (Facturation).

gcloud

  1. Exécutez la commande suivante pour afficher la configuration de facturation :

    gcloud run services describe SERVICE --format=yaml

  2. Dans la sortie YAML, recherchez le paramètre run.googleapis.com/cpu-throttling. La valeur false indique une facturation basée sur les instances. Si ce paramètre est manquant, cela indique une facturation basée sur les requêtes.