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.
Ce document fait partie d'une série qui comprend également les documents suivants:
- Autoscaling Spanner
- Présentation de l'outil d'autoscaling
- Déploiement de l'outil d'ajustement automatique de la taille pour Spanner sur Google Kubernetes Engine (GKE)
Cette série est destinée aux équipes informatique et aux équipes chargées des opérations et de l'ingénierie en fiabilité des sites (SRE) qui souhaitent réduire les coûts opérationnels et optimiser le coût des déploiements Spanner.
Cette page présente trois façons de déployer l'autoscaleur dans les fonctions Cloud Run, en fonction de vos besoins:
- Topologie de déploiement par projet : L'infrastructure d'Autoscaler est déployée dans le même projet que Spanner devant faire l'objet d'un autoscaling. Nous recommandons cette topologie aux équipes indépendantes qui souhaitent gérer leurs propres configuration et infrastructure d'Autoscaler. Une topologie de déploiement par projet constitue également un bon point de départ pour tester les fonctionnalités de l'Autoscaler.
- Topologie de déploiement centralisée : L'outil Autoscaler est déployé dans un projet et gère une ou plusieurs instances Spanner dans différents projets. Nous recommandons cette topologie aux équipes qui gèrent la configuration et l'infrastructure d'une ou de plusieurs instances Spanner, tout en maintenant les composants et la configuration d'Autoscaler dans un emplacement centralisé. Dans la topologie centralisée, en plus d'un projet Autoscaler, vous configurez un deuxième projet, appelé projet d'application dans ce tutoriel. Le projet d'application contient les ressources de l'application, y compris Spanner.
- Topologie de déploiement distribué : 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. Nous recommandons cette topologie aux organisations qui comptent plusieurs équipes, où les équipes qui possèdent les instances Spanner ne souhaitent gérer que les paramètres de configuration d'Autoscaler pour leurs instances, tandis que le reste de l'infrastructure d'Autoscaler est géré par une équipe centrale.
Sans serveur pour une simplicité du déploiement et de la gestion
Dans ce modèle, 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 réduit les coûts et le fonctionnement opérationnel de l'exécution de l'outil Autoscaler.
Grâce aux outils Google Cloud intégrés, l'outil Autoscaler peut tirer pleinement parti d'Identity and Access Management (IAM) pour l'authentification et l'autorisation.
Configuration
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": "my-spanner",
"scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
"units": "NODES",
"minSize": 1,
"maxSize": 3
},
{
"projectId": "different-project",
"instanceId": "another-spanner",
"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.
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.
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 le guide par étapes du déploiement par projet.
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.
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 savoir comment configurer Autoscaler à l'aide d'une topologie centralisée, consultez le guide par étapes du déploiement centralisé.
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.
Fonction de transfert
Cloud Scheduler ne peut publier des messages que sur les sujets d'un même projet. Dans le cadre de la topologie distribuée, un composant intermédiaire appelé fonction de transfert est requis.
La fonction de transfert transmet les messages publiés à Pub/Sub à partir de Cloud Scheduler, vérifie leur syntaxe JSON et les transmet au sujet Pub/Sub du service d'interrogation. Le sujet peut appartenir à un projet distinct dans Cloud Scheduler.
Le schéma suivant montre les composants utilisés pour le mécanisme de transfert :
Comme le montre le schéma précédent, les instances Spanner se trouvent dans des projets nommés Application 1 et Application 2:
- Le projet Cloud Scheduler est le même que celui des instances Spanner.
(2a) Cloud Scheduler publie ses messages dans le sujet de transfert dans les projets Application 1 et Application 2.
(2b) La fonction de transfert lit les messages à partir du sujet de transfert.
(2c) La fonction de transfert transmet les messages au sujet d'interrogation résidant dans le projet de l'Autoscaler.
La fonction d'interrogation lit les messages à partir du sujet de l'interrogation et le processus se poursuit, comme décrit dans la section Poller.
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 Autoscaler à l'aide d'une topologie distribuée, consultez le guide par étapes du déploiement distribué.
Étape suivante
- Découvrez comment déployer l'outil Autoscaler sur GKE.
- Apprenez-en 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.