Présentation de l'outil d'autoscaling

Cette page présente l'outil Autoscaler pour Spanner, un outil Open Source que vous pouvez utiliser comme outil associé à Spanner. Cet outil vous permet d'augmenter ou de réduire automatiquement la capacité de calcul dans une ou plusieurs instances Spanner en fonction de la capacité utilisée.

Pour en savoir plus sur le scaling dans Spanner, consultez la page Autoscaling Spanner. Pour en savoir plus sur le déploiement de l'outil Autoscaler, consultez les pages suivantes:

Cette page présente les fonctionnalités, l'architecture, la configuration et les topologies de déploiement de l'autoscaler. Les rubriques qui suivent cette série vous guident tout au long du déploiement de l'autoscaler dans chacune des différentes topologies.

Autoscaler

L'outil Autoscaler est utile pour gérer l'utilisation et les performances de vos déploiements Spanner. Pour vous aider à équilibrer le contrôle des coûts et les besoins en performances, l'autoscaler surveille vos instances, et ajoute ou supprime automatiquement des nœuds ou des unités de traitement pour s'assurer qu'ils respectent les paramètres suivants:

L'autoscaling des déploiements Spanner permet à votre infrastructure de s'adapter et de s'adapter automatiquement pour répondre aux exigences de charge, avec peu ou pas d'intervention. L'autoscaling redimensionne également l'infrastructure provisionnée, ce qui peut vous aider à réduire les coûts.

Architecture

Cette section décrit plus en détail les composants d'Autoscaler et leurs fonctions respectives.

L'architecture de l'outil Autoscaler se compose de Cloud Scheduler, de deux sujets Pub/Sub, de deux Cloud Functions et de Firestore. L'API Cloud Monitoring permet d'obtenir des métriques d'utilisation du processeur et de stockage pour les instances Spanner.

Cloud Scheduler

À l'aide de Cloud Scheduler, vous définissez la fréquence à laquelle l'outil Autoscaler vérifie les seuils de métriques d'instances Spanner. Une tâche Cloud Scheduler peut vérifier une ou plusieurs instances en même temps. Vous pouvez définir autant de planifications de tâches que nécessaire.

Fonction Cloud d'interrogation

La fonction cloud d'interrogation est responsable de la collecte et du traitement des métriques de séries temporelles pour une ou plusieurs instances Spanner. Le Poller prétraite les données de métriques pour chaque instance Spanner afin que seuls les points de données les plus pertinents soient évalués et envoyés à la fonction Cloud Scaler. Le prétraitement effectué par la fonction Cloud Poller simplifie également le processus d'évaluation des seuils pour les instances Spanner régionales et multirégionales.

Fonction Cloud de scaling

La fonction Cloud du Scaler évalue les points de données reçus de la fonction Cloud Poller et détermine si vous devez ajuster le nombre de nœuds ou d'unités de traitement et, le cas échéant, dans quelle mesure. La fonction Cloud compare les valeurs de métriques au seuil, plus ou moins une marge autorisée, et ajuste le nombre de nœuds ou d'unités de traitement en fonction de la méthode de scaling configurée. Pour en savoir plus sur les méthodes de scaling, consultez la section Fonctionnalités de l'autoscaler.

Flux opérationnel

Cette section détaille le modèle opérationnel de l'outil Autoscaler, comme illustré dans le schéma d'architecture suivant.

Modèle opérationnel d'Autoscaler.

  1. Vous définissez la planification, l'heure et la fréquence de vos jobs d'autoscaling dans Cloud Scheduler.
  2. Selon le calendrier que vous définissez, Cloud Scheduler envoie un message contenant une charge utile JSON avec les paramètres de configuration de l'outil Autoscaler pour une ou plusieurs instances Spanner dans le sujet Pub/Sub d'interrogation.
  3. Lorsque le message est publié dans le sujet d'interrogation, une instance de la fonction Cloud d'interrogation est créée pour gérer le message.
  4. La fonction cloud de sondage lit la charge utile du message et interroge l'API Cloud Monitoring pour récupérer les métriques d'utilisation de chaque instance Spanner.
  5. Pour chaque instance Spanner énumérée dans le message, la fonction Poller envoie un message dans le sujet Pub/Sub "Scaling" pour le scaling, contenant les métriques et les paramètres de configuration à évaluer pour l'instance Spanner spécifique.

  6. Pour chaque message transmis au sujet Scaler, la fonction Cloud Scaler effectue les opérations suivantes:

    1. Compare les métriques de l'instance Spanner aux seuils configurés, plus ou moins une marge configurable.

    Vous pouvez la configurer vous-même ou utiliser la valeur par défaut. 1. Elle détermine si l'instance doit subir un scaling ou non. 1. Calcule le nombre de nœuds ou d'unités de traitement vers lesquels effectuer le scaling de l'instance en fonction de la méthode de scaling choisie.

  7. La fonction Cloud Scaler récupère l'heure du dernier scaling de l'instance depuis Firestore et la compare à l'heure actuelle pour déterminer si le scaling à la hausse ou à la baisse est autorisé en fonction des périodes de stabilisation.

  8. Si la période de stabilisation configurée est passée, la fonction Cloud Scaler envoie une requête à l'instance Spanner pour effectuer un scaling à la hausse ou à la baisse.

Tout au long du flux, l'autoscaler écrit un résumé de ses recommandations et actions dans Cloud Logging à des fins de suivi et d'audit.

Quelle que soit la topologie de déploiement choisie, le fonctionnement global de l'outil Autoscaler reste le même.

Fonctionnalités d'Autoscaler

Cette section décrit les principales fonctionnalités de l'autoscaler.

Gérer plusieurs instances

L'outil Autoscaler est capable de gérer plusieurs instances Spanner sur plusieurs projets. Les instances multirégionales et régionales ont également des seuils d'utilisation différents qui sont utilisés lors du scaling. Par exemple, les déploiements multirégionaux sont ajustés à 45% d'utilisation du processeur à priorité élevée, tandis que les déploiements régionaux sont ajustés à 65% d'utilisation du processeur à priorité élevée, à la fois en plus ou en moins d'une marge autorisée. Pour en savoir plus sur les différents seuils de scaling, consultez la section Alertes en cas d'utilisation élevée du processeur.

Paramètres de configuration indépendants

Chaque instance Spanner avec autoscaling peut avoir une ou plusieurs planifications d'interrogation. Chaque planification d'interrogation possède son propre ensemble de paramètres de configuration.

Ces paramètres déterminent les facteurs suivants :

  • Nombre minimal et maximal de nœuds ou d'unités de traitement qui contrôlent la taille de votre instance, ce qui vous aide à maîtriser les coûts.
  • La méthode de scaling utilisée pour ajuster votre instance Spanner en fonction de votre charge de travail.
  • Les intervalles entre chaque période d'autoscaling pendant lesquels Spanner peut gérer les divisions de données.

Différentes méthodes de scaling pour différentes charges de travail

L'outil Autoscaler propose trois méthodes de scaling différentes pour le scaling à la hausse et à la baisse de vos instances Spanner: par étapes, linéaire et direct. Chaque méthode est conçue pour gérer différents types de charges de travail. Vous pouvez appliquer une ou plusieurs méthodes à chaque instance Spanner faisant l'objet d'un autoscaling lorsque vous créez des planifications d'interrogation indépendantes.

Par étapes

Le scaling par étapes est utile pour les charges de travail associées à des pics faibles ou multiples. Il provisionne de la capacité pour les lisser avec un seul événement d'autoscaling.

Le graphique suivant présente un modèle de charge avec des plateaux ou étapes de charge multiples, où chaque étape comporte plusieurs petits pics. Ce modèle est particulièrement adapté à la méthode par étapes.

Schéma de charge avec des étapes multiples.

Lorsque le seuil de charge est dépassé, cette méthode provisionne et supprime des nœuds ou des unités de traitement à l'aide d'un nombre fixe, mais configurable. Par exemple, trois nœuds sont ajoutés ou supprimés pour chaque action de scaling. En modifiant la configuration, vous pouvez autoriser l'ajout ou la suppression d'incréments de capacité plus importants à tout moment.

Linéaire

Le scaling linéaire est préférable avec des modèles de charge qui changent plus progressivement ou présentent quelques pics importants. La méthode calcule le nombre minimal de nœuds ou d'unités de traitement requis pour maintenir l'utilisation en dessous du seuil de scaling. Le nombre de nœuds ou d'unités de traitement ajoutés ou supprimés dans chaque événement de scaling n'est pas limité à un nombre d'étapes fixe.

L'exemple de modèle de charge dans le graphique suivant montre des augmentations et des diminutions soudaines plus importantes de la charge. Ces fluctuations ne sont pas regroupées dans des étapes perceptibles, comme elles l'étaient dans le graphique précédent. Ce modèle est plus facile à gérer à l'aide du scaling linéaire.

Schéma de charge avec fluctuations.

L'outil Autoscaler utilise le ratio de l'utilisation observée par rapport au seuil d'utilisation pour déterminer s'il faut ajouter des nœuds ou des unités de traitement au nombre total actuel ou en retirer.

La formule permettant de calculer le nouveau nombre de nœuds ou d'unités de traitement se présente comme suit :

newSize = currentSize * currentUtilization / utilizationThreshold

Direct

Le scaling direct offre une augmentation immédiate de la capacité. Cette méthode est destinée à gérer les charges de travail par lots dans lesquelles un nombre de nœuds prédéterminé plus élevé est périodiquement exigé dans une planification avec une heure de début connue. Cette méthode fait évoluer l'instance jusqu'au nombre maximal de nœuds ou d'unités de traitement spécifié dans la planification. Elle est destinée à être utilisée en complément d'une méthode linéaire ou par étapes.

Le graphique suivant décrit l'augmentation planifiée importante de la charge, pour laquelle Autoscaler a préprovisionné la capacité à l'aide de la méthode directe.

Modèle de charge avec scaling direct préprovisionné.

Une fois la charge de travail par lot terminée et l'utilisation repassée à un niveau normal, selon votre configuration, le scaling linéaire ou par étapes est appliqué pour effectuer un scaling à la baisse de l'instance automatiquement.

Méthodes de déploiement

L'outil Autoscaler peut être déployé dans un projet individuel ou avec les instances Spanner qu'il gère. L'outil Autoscaler est conçu pour être flexible et peut gérer la séparation existante des responsabilités entre les équipes chargées des opérations et des applications. La responsabilité de la configuration de l'autoscaling des instances Spanner peut être centralisée à une seule équipe chargée des opérations, ou celle-ci peut être distribuée aux équipes plus proches des applications diffusées par ces instances Spanner.

Les différents modèles de déploiement sont décrits plus en détail dans la section Topologies de déploiement.

Sans serveur pour une simplicité du déploiement et de la gestion

L'outil d'autoscaling est conçu uniquement à l'aide des outils Google Cloud sans serveur et nécessitant peu de gestion, tels que Cloud Functions, Pub/Sub, Cloud Scheduler et Firestore. Cette approche réduit les coûts et les coûts opérationnels liés à l'exécution de l'outil d'autoscaling.

Grâce aux outils Google Cloud intégrés, l'autoscaler peut tirer pleinement parti d'IAM (IAM) pour l'authentification et l'autorisation.

Configuration

L'outil Autoscaler dispose de différentes options de configuration que vous pouvez utiliser pour gérer le scaling de vos déploiements Spanner. Les sections suivantes décrivent les options de configuration de base et les options de configuration plus avancées.

Configuration de base

L'outil Autoscaler gère les instances Spanner via la configuration définie dans Cloud Scheduler. Si plusieurs instances Spanner doivent être interrogées avec le même intervalle, nous vous recommandons de les configurer dans la même tâche Cloud Scheduler. La configuration de chaque instance est représentée par un objet JSON. Voici un exemple de configuration dans laquelle deux instances Spanner sont gérées avec une seule tâche Cloud Scheduler:

   [
    {
        "projectId": "my-spanner-project", "instanceId": "spanner1",
        "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
        "units": "NODES", "minSize": 1, "maxSize": 3
     },
     {
        "projectId":
        "different-project", "instanceId": "another-spanner1", "scalerPubSubTopic":
        "projects/my-spanner-project/topics/spanner-scaling", "units":
        "PROCESSING_UNITS", "minSize": 500, "maxSize": 3000, "scalingMethod": "DIRECT"
    }
   ]

Les instances Spanner peuvent avoir plusieurs configurations sur différents jobs Cloud Scheduler. Par exemple, une instance peut disposer d'une configuration Autoscaler avec la méthode linéaire pour les opérations normales, mais aussi d'une autre configuration Autoscaler avec la méthode directe pour les charges de travail par lot planifiées.

Lorsque la tâche Cloud Scheduler s'exécute, elle envoie un message Pub/Sub au sujet Pub/Sub d'interrogation. La charge utile de ce message correspond au tableau JSON des objets de configuration pour toutes les instances configurées dans la même tâche. Consultez la liste complète des options de configuration dans le fichier README d'interrogation.

Configuration avancée

L'outil Autoscaler dispose d'options de configuration avancées qui vous permettent de contrôler plus précisément quand et comment vos instances Spanner sont gérées. Les sections suivantes présentent une sélection de ces commandes.

Seuils personnalisés

L'outil Autoscaler détermine le nombre de nœuds ou d'unités de traitement à ajouter ou à soustraire à une instance à l'aide des seuils Spanner recommandés pour les métriques de charge suivantes:

  • Processeur à priorité élevée
  • Utilisation du processeur, moyenne glissante de 24 heures
  • Utilisation du stockage

Nous vous recommandons d'utiliser les seuils par défaut, comme décrit dans la section Créer des alertes pour les métriques Spanner. Toutefois, dans certains cas, vous souhaiterez peut-être modifier les seuils utilisés par l'autoscaler. Par exemple, vous pouvez utiliser des seuils plus bas pour que l'outil d'autoscaling réagisse plus rapidement que pour des seuils plus élevés. Cette modification permet d'éviter le déclenchement d'alertes à des seuils plus élevés.

Métriques personnalisées

Bien que les métriques par défaut de l'autoscaler répondent à la plupart des scénarios de performances et de scaling, dans certains cas, vous devrez peut-être spécifier vos propres métriques pour déterminer quand effectuer un scaling vertical et horizontal. Dans ces scénarios, vous définissez des métriques personnalisées dans la configuration à l'aide de la propriété metrics.

Marges

Une marge définit une limite supérieure et inférieure au seuil. L'outil d'autoscaling ne déclenche un événement d'autoscaling que si la valeur de la métrique est supérieure ou inférieure à la limite supérieure.

L'objectif de ce paramètre est d'éviter les déclenchements d'événements d'autoscaling pour les fluctuations de charge de travail mineures autour du seuil, réduisant ainsi la fluctuation des actions d'Autoscaler. Le seuil et la marge définissent la plage suivante, en fonction de la valeur de métrique souhaitée : 

[threshold - margin, threshold + margin]
Plus la marge est faible, plus la plage est étroite, ce qui augmente la probabilité qu'un événement d'autoscaling soit déclenché.

La spécification d'un paramètre de marge pour une métrique est facultative et sa valeur par défaut est de cinq points de pourcentage, avant et sous le paramètre.

Topologies de déploiement

Pour déployer l'outil Autoscaler, choisissez parmi les topologies suivantes celles qui répondent le mieux à vos besoins techniques et opérationnels:

  • Topologie par projet: l'infrastructure de l'autoscaler est déployée dans le même projet que Spanner, qui doit faire l'objet d'un autoscaling.
  • Topologie centralisée: l'outil Autoscaler est déployé dans un projet et gère une ou plusieurs instances Spanner dans différents projets.
  • Topologie distribuée : la majeure partie de l'infrastructure de l'autoscaler est déployée dans un projet, mais certains composants d'infrastructure sont déployés avec l'autoscaling des instances Spanner dans différents projets.

Topologie par projet

Dans un déploiement de topologie par projet, chaque projet avec une instance Spanner devant être soumis à un autoscaling a également son propre déploiement indépendant des composants d'Autoscaler. Nous recommandons cette topologie aux équipes indépendantes qui souhaitent gérer leurs propres configuration et infrastructure d'Autoscaler. C'est également un bon point de départ pour tester les fonctionnalités de l'autoscaler.

Le schéma suivant présente une vue conceptuelle générale d'un déploiement par projet.

Vue conceptuelle d'un déploiement par projet.

Les déploiements par projet décrits dans le schéma précédent présentent les caractéristiques suivantes:

  • Deux applications, Application 1 et Application 2, utilisent chacune leurs propres instances Spanner.
  • Les instances Spanner (A) résident dans les projets Application 1 et Application 2.
  • Un autoscaler indépendant (B) est déployé dans chaque projet pour contrôler l'autoscaling des instances d'un projet.

Pour obtenir un schéma plus détaillé d'un déploiement par projet, consultez la section Architecture.

Un déploiement par projet présente les avantages et les inconvénients suivants.

Avantages :

  • Conception la plus simple: la topologie par projet est la conception la plus simple des trois topologies, car tous les composants de l'autoscaler sont déployés avec les instances Spanner en cours d'autoscaling.
  • Configuration: le contrôle des paramètres du programmeur appartient à l'équipe propriétaire de l'instance Spanner, ce qui lui donne plus de liberté pour adapter l'outil d'autoscaling à ses besoins qu'avec une topologie centralisée ou distribuée.
  • Limite claire de la responsabilité de l'infrastructure : la conception d'une topologie par projet établit une limite claire de responsabilité et de sécurité sur l'infrastructure d'Autoscaler, car le propriétaire d'équipe des instances Spanner est également propriétaire de l'infrastructure d'Autoscaler.

Inconvénients :

  • Maintenance globale plus importante: chaque équipe est responsable de la configuration et de l'infrastructure de l'autoscaler. Il peut donc être difficile de vérifier que tous les outils de l'autoscaler suivent les mêmes consignes de mise à jour.
  • Audit plus complexe : chaque équipe ayant un haut niveau de contrôle, un audit centralisé peut devenir plus complexe.

Pour savoir comment configurer l'autoscaler à l'aide d'une topologie par projet, consultez la page Déployer un outil d'autoscaler par projet ou centralisé pour Spanner.

Topologie centralisée

Comme pour la topologie par projet, dans un déploiement de topologie centralisée, tous les composants de l'outil d'autoscaling se trouvent dans le même projet. Cependant, les instances Spanner se trouvent dans des projets différents. Ce déploiement convient à une équipe qui gère la configuration et l'infrastructure de plusieurs instances Spanner à partir d'un seul déploiement de l'outil d'autoscaling de manière centralisée.

Le schéma suivant présente une vue conceptuelle générale d'un déploiement de projet centralisé :

Vue conceptuelle d'un déploiement de projet centralisé.

Le déploiement centralisé illustré dans le schéma précédent présente les caractéristiques suivantes :

  • Deux applications, Application 1 et Application 2, utilisent chacune leurs propres instances Spanner.
  • Les instances Spanner (A) se trouvent dans les projets Application 1 et Application 2.
  • L'autoscaler (B) est déployé dans un projet distinct pour contrôler l'autoscaling des instances Spanner dans les projets Application 1 et Application 2.

Pour obtenir un schéma plus détaillé d'un déploiement de projet centralisé, consultez la page Déployer un outil d'autoscaling par projet ou un autoscaler centralisé pour Spanner.

Un déploiement centralisé présente les avantages et les inconvénients suivants :

Avantages :

  • Configuration et infrastructure centralisées: une seule équipe contrôle les paramètres du programmeur et l'infrastructure de l'autoscaler. Cette approche peut être utile dans les secteurs hautement réglementés.
  • Réduction de la maintenance globale: la maintenance et la configuration sont généralement plus simples à gérer qu'un déploiement par projet.
  • Règles et audits centralisés : les bonnes pratiques des différentes équipes peuvent être plus simples à spécifier et à exécuter. Les audits peuvent être plus faciles à exécuter.

Inconvénients :

  • Configuration centralisée: toute modification apportée aux paramètres de l'autoscaler doit être transmise à l'équipe centralisée, même si l'équipe qui demande la modification est propriétaire de l'instance Spanner.
  • Risque supplémentaire: l'équipe centralisée peut devenir elle-même un point de défaillance unique, même si l'infrastructure de l'autoscaler est conçue dans un souci de haute disponibilité.

Pour obtenir un tutoriel pas à pas sur la configuration de l'autoscaler à l'aide de cette option, consultez la page Déployer un outil d'autoscaler par projet ou centralisé pour Spanner.

Topologie distribuée

Dans un déploiement de topologie distribuée, les instances Cloud Scheduler et Spanner qui doivent faire l'objet d'un autoscaling se trouvent dans le même projet. Les autres composants de l'outil Autoscaler se trouvent dans un projet géré de manière centralisée. Ce déploiement est hybride. Les équipes qui possèdent les instances Spanner ne gèrent que les paramètres de configuration de l'autoscaler pour leurs instances, tandis qu'une équipe centrale gère le reste de l'infrastructure de l'autoscaler.

Le schéma suivant présente une vue conceptuelle générale d'un déploiement de projet distribué.

Vue conceptuelle d'un déploiement de projet distribué.

Le déploiement hybride illustré dans le schéma précédent présente les caractéristiques suivantes :

  • Deux applications, Application 1 et Application 2, utilisent leurs propres instances Spanner.
  • Les instances Spanner (A) se trouvent dans les projets de l'Application 1 et de l'Application 2.
  • Un composant Cloud Scheduler (C) indépendant est déployé dans chaque projet: Application 1 et Application 2.
  • Les composants restants d'Autoscaler (B) sont déployés dans un projet distinct.
  • L'outil Autoscaler effectue l'autoscaling des instances Spanner dans les projets Application 1 et Application 2 à l'aide des configurations envoyées par les composants Cloud Scheduler indépendants de chaque projet.

Pour obtenir un schéma plus détaillé du déploiement centralisé de projets, consultez la page Déployer un outil d'autoscaler distribué pour Spanner.

Un déploiement distribué présente les avantages et les inconvénients suivants :

Avantages :

  • Les équipes applications contrôlent la configuration et les calendriers : Cloud Scheduler est déployé en même temps que les instances Spanner en cours d'autoscaling, ce qui permet aux équipes d'application de mieux contrôler la configuration et la planification.
  • L'équipe chargée des opérations contrôle l'infrastructure: les composants principaux de l'autoscaler sont déployés de manière centralisée, ce qui permet aux équipes chargées des opérations de contrôler l'infrastructure de l'autoscaler.
  • Maintenance centralisée: l'infrastructure Scaler est centralisée, ce qui réduit les frais généraux.

Inconvénients :

  • Configuration plus complexe: les équipes d'application doivent fournir des comptes de service pour écrire dans le sujet d'interrogation.
  • Risque supplémentaire: l'infrastructure partagée peut devenir un point de défaillance unique, même si elle est conçue dans un souci de haute disponibilité.

Pour apprendre à configurer l'autoscaler dans un déploiement distribué, consultez la page Déployer un outil d'autoscaler distribué pour Spanner.

Divisions des données

Spanner attribue des plages de données appelées divisions aux nœuds ou aux subdivisions d'un nœud appelés unités de traitement. Le nœud ou les unités de traitement gèrent et diffusent indépendamment les données dans les divisions réparties. Les divisions de données sont créées en fonction de plusieurs facteurs, tels que le volume de données et les modèles d'accès. Pour en savoir plus, consultez la page Schéma et modèle de données de Spanner.

Les données sont organisées en divisions, qui sont gérées automatiquement par Spanner. Ainsi, lorsque l'autoscaler ajoute ou supprime des nœuds ou des unités de traitement, il doit laisser au backend Spanner suffisamment de temps pour réattribuer et réorganiser les divisions à mesure que de nouvelles capacités sont ajoutées ou supprimées des instances.

L'outil Autoscaler utilise des périodes d'attente sur les événements de scaling à la hausse et à la baisse pour contrôler la vitesse à laquelle il peut ajouter ou supprimer des nœuds ou des unités de traitement d'une instance. Cette méthode laisse à l'instance le temps nécessaire pour réorganiser les relations entre les notes de calcul ou les unités de traitement et les divisions de données. Par défaut, les périodes d'attente entre le scaling à la hausse et à la baisse sont définies sur les valeurs minimales suivantes:

  • Valeur de scaling à la hausse : 5 minutes
  • Valeur de scaling à la baisse : 30 minutes

Pour en savoir plus sur les recommandations de scaling et les périodes d'attente, consultez la page Scaling des instances Spanner.

Coûts

La consommation des ressources de l'outil Autoscaler étant minimale, les coûts sont négligeables dans la plupart des cas d'utilisation. Autoscaler est gratuit lorsqu'il est utilisé sur Google Cloud. Par exemple, vous pouvez exécuter sans frais un outil d'autoscaling pour gérer trois instances Spanner avec un intervalle d'interrogation de cinq minutes pour chacune d'elles. Cette estimation comprend les éléments suivants:

  • 3 tâches Cloud Scheduler
  • 0,15 Go de messages Pub/Sub
  • 51 840 appels de 500 ms de la fonction Cloud
  • Moins de 10 Mo de données dans Firestore

L'estimation n'inclut pas les coûts d'exploitation de la base de données Spanner. Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Étapes suivantes