Présentation de l'outil d'autoscaler

Cette page présente l'outil Autoscaler pour Spanner (Autoscaler), un outil Open Source que vous pouvez utiliser en tant qu'outil associé à Spanner. Cet outil vous permet d'augmenter ou de réduire automatiquement la capacité de calcul Instances Spanner en fonction de la capacité utilisée.

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

Cette page présente les fonctionnalités, l'architecture, la configuration et le déploiement de l'autoscaler. Les sujets suivants de cette série vous guident tout au long du déploiement d'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 les coûts en fonction des besoins en termes de performances, l'outil Autoscaler surveille vos instances, et ajoute ou supprime automatiquement des nœuds ou des unités de traitement afin de garantir qu'ils restent dans les paramètres suivants :

L'autoscaling des déploiements Spanner permet à votre infrastructure s'adaptent et s'adaptent automatiquement aux exigences de charge de l'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 comprend Cloud Scheduler, deux sujets Pub/Sub, deux fonctions Cloud Run et Firestore. La API Cloud Monitoring permet d'obtenir des métriques sur l'utilisation du processeur et le stockage pour Spanner. Compute Engine.

Cloud Scheduler

À l'aide de Cloud Scheduler, vous définissez la fréquence à laquelle l'outil Autoscaler vérifie les seuils des métriques de scaling de vos 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 Run d'interrogation

La fonction Cloud Run d'interrogation est chargée de collecter et de traiter les métriques de séries temporelles pour une ou plusieurs instances Spanner. Elle prétraite les données des métriques pour chaque instance Spanner de sorte que seuls les points de données les plus pertinents soient évalués et envoyés à la fonction Cloud Run de scaling. Le prétraitement effectué par la fonction Cloud Run d'interrogation permet également de simplifier le processus d'évaluation des seuils pour les instances Spanner régionales, birégionales et multirégionales.

Fonction Cloud Run de scaling

Le scaler Fonction Cloud Run Il évalue les points de données reçus de la fonction Poller Cloud Run. détermine si vous devez ajuster le nombre de nœuds ou d'unités de traitement et, si oui, dans quelle mesure. Fonction Cloud Run compare les valeurs de la métrique au seuil, plus ou moins une valeur marge , et ajuste le nombre de nœuds ou d'unités de traitement en fonction de la configuration de mise à l'échelle. Pour en savoir plus sur les méthodes de scaling, consultez la page Fonctionnalités de l'autoscaler. pour en savoir plus.

Flux opérationnel

Cette section détaille le modèle opérationnel de l'outil Autoscaler, 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 transfère 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 Run d'interrogation est créée pour gérer le message.
  4. La fonction Cloud Run de sondage lit la charge utile du message et interroge l'API Cloud Monitoring pour récupérer pour chaque instance Spanner.
  5. Pour chaque instance Spanner énumérée dans le message, la fonction d'interrogation transmet un message au sujet Pub/Sub de scaling, contenant les métriques et les paramètres de configuration à évaluer pour l'instance Spanner spécifique.

  6. Pour chaque message envoyé dans le sujet "Scaler", le scaler La fonction Cloud Run effectue les opérations suivantes:

    1. Il compare les métriques de l'instance Spanner avec des seuils configurés, plus ou moins une valeur marge.

    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 que l'instance doit être ajusté en fonction de la méthode de scaling choisie.

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

  8. Si la période d'attente configurée est passée, le Scaler La fonction Cloud Run envoie une requête à Spanner Scaling à la hausse ou à la baisse de l'instance.

Tout au long du flux, l'outil 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 que vous choisissez, l'opération globale de l'outil Autoscaler reste la même.

Fonctionnalités d'Autoscaler

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

Gérer plusieurs instances

L'autoscaler est capable de gérer plusieurs instances Spanner plusieurs projets. Les instances multirégionales, birégionales et régionales disposent toutes différents seuils d'utilisation utilisés lors du scaling. Par exemple : les déploiements multirégionaux et birégionaux font l'objet d'un scaling à 45% du processeur à priorité élevée d'utilisation, tandis que les déploiements régionaux sont ajustés avec 65% de ressources d'utilisation, plus ou moins une valeur marge. Pour en savoir plus sur les différents seuils de scaling, consultez Alertes en cas d'utilisation intensive 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 permet de contrôler les tailles maximale et minimale de votre instance, et ainsi contrôler les coûts.
  • La méthode de scaling utilisée pour ajuster votre instance Spanner en fonction de votre charge de travail.
  • Les périodes d'attente pour permettre à Spanner de gérer les divisions de données.

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

L'outil Autoscaler fournit trois méthodes de scaling différentes pour les instances Spanner en termes de scaling à la hausse et à la baisse : par étapes, linéaire et directe. Chaque méthode est conçue pour accepter différents types de charges de travail. Vous pouvez appliquer un ou de méthodes supplémentaires pour chaque instance Spanner faisant l'objet d'un autoscaling lorsque vous créez des calendriers de sondage indépendants.

Par étapes

Le scaling par étapes est utile pour les charges de travail présentant des pics petits ou multiples. Il provisionne la capacité pour les éliminer à l'aide d'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 en utilisant un nombre fixe mais configurable. Par exemple, trois nœuds sont ajoutées ou supprimées pour chaque action de scaling. En modifiant la configuration, vous pouvez autoriser l'ajout ou la suppression d'incréments de capacité supérieurs à 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 pour chaque événement de scaling n'est pas soumis à un incrément 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 d'utilisation observée sur le le seuil d'utilisation pour calculer s'il faut ajouter ou soustraire des nœuds, d'unités de traitement à partir du nombre total actuel.

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 procède au scaling à la hausse de l'instance jusqu'à atteindre le nombre maximal de nœuds ou d'unités de traitement spécifié dans la planification. Elle est prévue pour être utilisée en plus 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é soit dans un projet individuel, soit avec les instances Spanner qu'il gère. L'outil Autoscaler est conçu pour être flexible et s'adapte à la séparation des responsabilités entre votre équipe chargée des opérations et celle chargée des applications. La responsabilité de la configuration de l'autoscaling des instances Spanner peut être centralisée avec une seule équipe d'opérations ou ê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 Autoscaler est conçu à l'aide d'outils Google Cloud sans serveur et de gestion faible seulement, tels que les fonctions Cloud Run, Pub/Sub, Cloud Scheduler et Firestore. Cette approche minimise le coût et les coûts opérationnels liés à l'exécution de l'autoscaler.

À l'aide des outils Google Cloud intégrés, l'autoscaler peut exploiter les avantages offerts par IAM (IAM) pour l'authentification et l'autorisation.

Configuration

L'outil Autoscaler propose 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 des options de configuration plus avancées.

Configuration de base

L'outil Autoscaler gère les instances Spanner via la configuration définies dans Cloud Scheduler. Si plusieurs instances Spanner doivent être interrogées au même intervalle, nous vous recommandons de les configurer dans la même tâche Cloud Scheduler. La configuration de chaque instance représentée sous forme d'objet JSON. Voici un exemple de configuration où deux instances Spanner sont gérées Job 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érentes tâches 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'autoscaler dispose d'options de configuration avancées qui vous permettent contrôler 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 d'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 Créer des alertes pour les métriques Spanner pour en savoir plus. Toutefois, dans certains cas, vous souhaiterez peut-être modifier les seuils utilisés par l'outil Autoscaler. Par exemple, vous pouvez définir des seuils inférieurs pour que l'outil Autoscaler 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'outil Autoscaler répondent à la plupart des scénarios de scaling et de performances, il peut arriver que vous deviez spécifier vos propres métriques pour déterminer quand effectuer un scaling à la hausse et à la baisse. Pour ces scénarios, vous définissez des métriques personnalisées dans la configuration metrics .

Marges

Une marge définit une limite supérieure et inférieure au seuil. L'autoscaler ne déclenche un événement d'autoscaling que si la valeur de la métrique est supérieure à la limite supérieure ou inférieure à la limite infé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 donne un 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, identifiez laquelle des topologies suivantes correspond le mieux à vos besoins techniques et opérationnels :

  • Topologie par projet : l'infrastructure d'Autoscaler est déployée dans le même projet que Spanner devant faire l'objet d'un autoscaling.
  • Topologie centralisée: l'outil d'autoscaling 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 Instances Spanner en cours d'autoscaling 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 aussi un est 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 illustrés 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 respectifs de l'Application 1 et de l'Application 2.
  • Un Autoscaler indépendant (B) est déployé dans chaque projet pour contrôler l'autoscaling des instances au sein 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 d'Autoscaler sont déployés avec les instances Spanner qui subissent un autoscaling.
  • Configuration: le contrôle des paramètres du planificateur appartient à l'équipe propriétaire de l'instance Spanner, ce qui offre à l'équipe la liberté d'adapter l'outil Autoscaler à ses besoins par rapport à une solution centralisée ou une topologie 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 :

  • Une maintenance globale plus importante: chaque équipe est responsable de l'autoscaler. la configuration et l'infrastructure. Il peut donc devenir difficile de s'assurer que tous les outils d'autoscaler de l'entreprise suivent la même mise à jour consignes.
  • 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 Déployez un outil d'autoscaler centralisé ou par projet pour Spanner.

Topologie centralisée

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

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 leur propre aux instances Spanner.
  • Les instances Spanner (A) se trouvent dans les projets respectifs de l'Application 1 et de l'Application 2.
  • L'autoscaler (B) est déployé dans un projet distinct pour contrôler des instances Spanner des instances d'application 1 Projets Application 2

Pour obtenir un schéma plus détaillé d'un déploiement de projet centralisé, consultez Déployez un outil d'autoscaler centralisé ou par projet 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 fortement réglementés.
  • Moins de maintenance globale : la maintenance et la configuration demandent généralement moins d'efforts que les déploiements 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 des paramètres d'Autoscaler doit passer par l'équipe centralisée, même si l'équipe qui demande la modification détient l'instance Spanner.
  • Risque supplémentaire de risque: l'équipe centralisée elle-même peut devenir un point de défaillance unique, même si l'infrastructure de l'autoscaler est conçue tout en gardant à l'esprit la haute disponibilité.

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

Topologie distribuée

Dans un déploiement de topologie distribuée, Cloud Scheduler et Les instances Spanner nécessitant un autoscaling se trouvent dans le même projet. Les autres composants de l'outil Autoscaler résident dans un projet géré de manière centralisée. Il s'agit d'un déploiement hybride. Les équipes qui possèdent Les instances Spanner ne gèrent que la configuration de l'autoscaler pour leurs instances, et une équipe centrale gère le reste Infrastructure d'autoscaler

Le schéma suivant présente une vue conceptuelle globale d'un dans 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 indépendant (C) 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 de l'Application 1 et de l'Application 2 en utilisant les configurations envoyées par les composants indépendants de Cloud Scheduler dans chaque projet.

Pour obtenir un schéma plus détaillé du déploiement du projet centralisé, consultez la page Déployer un outil Autoscaler distribué pour Spanner.

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

Avantages :

  • Les équipes chargées des applications contrôlent la configuration et les planifications : Cloud Scheduler est déployé en même temps que les instances Spanner faisant l'objet d'un autoscaling, ce qui permet aux équipes chargées des applications 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'outil 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 d'Autoscaler.
  • Maintenance centralisée : l'infrastructure de scaling est centralisée, ce qui réduit les coûts de maintenance.

Inconvénients :

  • Configuration plus complexe: les équipes en charge des applications doivent fournir un service pour écrire dans le sujet de sondage.
  • Risque supplémentaire de risque: l'infrastructure partagée peut devenir point de défaillance unique, même si l'infrastructure est conçue avec des la disponibilité.

Pour apprendre à configurer l'outil Autoscaler dans un déploiement distribué, consultez la page Déployer un outil 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é unités de traitement. Le nœud ou les unités de traitement indépendamment gérer et diffuser les données dans les répartitions réparties. Les divisions des données sont créées en fonction de plusieurs facteurs, y compris le volume de données et les modèles d'accès. Pour en savoir plus, consultez la page Spanner : schéma et modèle de données.

Les données sont divisées en divisions, et Spanner gère automatiquement les écrans fractionnés. Ainsi, lorsque l'outil Autoscaler ajoute ou supprime des nœuds ou des unités de traitement, il doit laisser suffisamment de temps au backend Spanner pour réattribuer et réorganiser les divisions en fonction de la capacité ajoutée ou supprimée des instances.

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

  • 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 de stabilisation, consultez Effectuer le scaling d'instances Spanner

Coûts

L'outil Autoscaler consomme très peu de ressources. Dans la plupart des cas, sont négligeables. Autoscaler est gratuit lorsqu'il est utilisé sur Google Cloud. Exemple , qui exécute un autoscaler pour gérer trois instances Spanner avec une un intervalle d'interrogation de 5 minutes pour chaque instance est disponible sans frais. Cette estimation comprend les éléments suivants :

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

L'estimation n'inclut pas les coûts liés aux opérations de base de données Spanner. Utilisez la Simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

Étape suivante