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 dans une ou plusieurs 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:
- Déployer un outil Autoscaler centralisé ou par projet pour Spanner
- Déployer un outil Autoscaler distribué pour Spanner
Cette page présente les fonctionnalités, l'architecture, la configuration et les topologies de déploiement d'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:
- Les valeurs maximales recommandées pour l'utilisation du processeur.
La limite recommandée pour le stockage par nœud
plus ou moins une marge configurable.
Les déploiements d'autoscaling de Spanner permettent à votre infrastructure de s'adapter et d'effectuer des scalings 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 comprend Cloud Scheduler, deux sujets Pub/Sub, deux fonctions Cloud Run et Firestore. L'API Cloud Monitoring permet d'obtenir des métriques de stockage et d'utilisation du processeur 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 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
La fonction Cloud Run de scaling évalue les points de données reçus de la fonction Cloud Run d'interrogation 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 Run compare les valeurs des 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 d'Autoscaler.
Flux opérationnel
Cette section détaille le modèle opérationnel de l'outil Autoscaler, comme illustré dans le schéma architectural suivant.
- Vous définissez la programmation, l'heure et la fréquence de vos tâches d'autoscaling dans Cloud Scheduler.
- 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.
- 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.
- La fonction Cloud Run d'interrogation 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.
- 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.
Pour chaque message transmis au sujet de scaling, la fonction Cloud Run de scaling effectue les opérations suivantes:
- Compare les métriques d'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. Elle calcule le nombre de nœuds ou d'unités de traitement vers lequel l'instance doit être mise à l'échelle en fonction de la méthode choisie.
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.
Si la période de transition configurée est passée, la fonction Cloud Run de scaling envoie une requête à l'instance Spanner pour effectuer un scaling à la hausse ou à la baisse.
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'outil Autoscaler.
Gérer plusieurs instances
L'outil Autoscaler est capable de gérer plusieurs instances Spanner sur plusieurs projets. Les instances multirégionales, birégionales et régionales ont toutes des seuils d'utilisation différents qui sont utilisés lors du scaling. Par exemple, le scaling des déploiements multirégionaux et birégionaux est de 45% de l'utilisation du processeur par les tâches à priorité élevée, tandis que le scaling des déploiements régionaux est de 65% de l'utilisation du processeur par les tâches à priorité élevée, plus ou moins une marge autorisée. Pour en savoir plus sur les différents seuils de scaling, consultez la page 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 de transition pour permettre à Spanner de gérer les divisions des 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 une ou plusieurs méthodes à chaque instance Spanner qui subit 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 qui présentent des pics petits ou nombreux. 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.
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é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é 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.
L'outil Autoscaler utilise le ratio de l'utilisation observée par rapport au seuil d'utilisation pour déterminer s'il faut ajouter ou soustraire des nœuds ou des unités de traitement au 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.
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 sans serveur et de gestion faible Google Cloudseulement, tels que les fonctions Cloud Run, Pub/Sub, Cloud Scheduler et Firestore. Cette approche réduit les coûts et les frais opérationnels liés à l'exécution de l'outil Autoscaler.
Grâce aux outils Google Cloud intégrés, l'outil 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 des 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 au 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 sous la forme d'un objet JSON. Voici un exemple de configuration dans laquelle deux instances Spanner sont gérées avec une 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é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'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 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 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'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 de tels 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 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]
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 Autoscaler est déployé dans un projet et gère une ou plusieurs instances Spanner dans différents projets.
- Topologie distribuée : la plupart des infrastructures d'Autoscaler sont déployées dans un projet, mais certains composants d'infrastructure sont déployés avec les instances Spanner subissant un 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. Il constitue également un bon point de départ pour tester les fonctionnalités de l'outil Autoscaler.
Le schéma suivant présente une vue conceptuelle générale 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 programmeur appartient à l'équipe qui possède l'instance Spanner. L'équipe dispose ainsi de plus de liberté pour adapter l'outil Autoscaler à ses besoins que si elle utilisait 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 d'Autoscaler. Il peut donc être difficile de s'assurer que tous les outils d'Autoscaler de l'entreprise 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 apprendre à configurer Autoscaler à l'aide d'une topologie par projet, consultez la page Déployer un outil 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 déploiement est adapté à une équipe qui gère la configuration et l'infrastructure de plusieurs instances Spanner à partir d'un seul déploiement de l'outil Autoscaler dans un emplacement central.
Le schéma suivant présente une vue conceptuelle générale 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 respectifs de l'Application 1 et de l'Application 2.
- Autoscaler (B) est déployé dans un projet distinct pour contrôler l'autoscaling des instances Spanner dans les projets de l'Application 1 et de l'Application 2.
Pour obtenir un schéma plus détaillé d'un déploiement de projet centralisé, consultez la page Déployer un outil 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 d'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.
- Potentiel de risque supplémentaire: l'équipe centralisée elle-même peut devenir un point de défaillance unique, même si l'infrastructure d'Autoscaler est conçue pour une haute disponibilité.
Pour obtenir un tutoriel par étapes sur la configuration de l'outil Autoscaler à l'aide de cette option, consultez la page Déployer un outil Autoscaler centralisé ou par projet pour Spanner.
Topologie distribuée
Dans un déploiement de topologie distribuée, les instances Cloud Scheduler et Spanner devant faire l'objet d'un autoscaling résident dans le même projet. Les autres composants de l'outil Autoscaler résident dans un projet géré de manière centralisée. Ce déploiement est un déploiement hybride. Les équipes qui possèdent les instances Spanner ne gèrent que les paramètres de configuration d'Autoscaler pour leurs instances, tandis qu'une équipe centrale gère l'infrastructure restante d'Autoscaler.
Le schéma suivant présente une vue conceptuelle générale 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.
Inconvénients :
- Configuration plus complexe: les équipes chargées des applications doivent fournir des comptes de service pour écrire dans le sujet d'interrogation.
- Potentiel de risque supplémentaire: l'infrastructure partagée peut devenir un point de défaillance unique, même si l'infrastructure est conçue pour une haute 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 gèrent et diffusent indépendamment les données selon les divisions définies. 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 organisées en divisions, et Spanner gère celles-ci automatiquement. 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 défaut, les périodes de transition d'autoscaling à 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 de transition, consultez la page Scaling des instances Spanner.
Coûts
La consommation de ressources de l'outil Autoscaler est minime. Par conséquent, dans la plupart des cas d'utilisation, les coûts sont négligeables. Autoscaler est gratuit lorsqu'il est utilisé sur Google Cloud. Par exemple, l'exécution d'un outil Autoscaler pour gérer trois instances Spanner avec 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 500 ms de la fonction Cloud Run
- 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. Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Étape suivante
- Découvrez comment déployer l'outil Autoscaler dans une topologie centralisée ou par projet.
- Découvrez comment déployer l'outil Autoscaler dans une topologie distribuée.
- En savoir plus sur les seuils recommandés de Spanner
- Apprenez-en plus sur les métriques d'utilisation du processeur et les métriques de latence de Spanner.
- Découvrez les bonnes pratiques pour la conception de schéma Spanner afin d'éviter les hotspots et de charger des données dans Spanner.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.