Déploiement à l'échelle mondiale à l'aide de Compute Engine et de Spanner

Last reviewed 2024-05-12 UTC

Ce document fournit une architecture de référence pour une application à plusieurs niveaux qui s'exécute sur des VM Compute Engine et sur Spanner, selon une topologie mondiale dans Google Cloud. Il fournit également des conseils pour vous aider à créer une architecture utilisant d'autres services d'infrastructure Google Cloud. Il décrit les facteurs de conception à prendre en compte lors de la création d'une architecture multirégionale pour vos applications cloud. Ce document s'adresse aux architectes cloud.

Cette architecture est conforme à l'archétype de déploiement mondial. Nous recommandons cet archétype pour les applications desservant des utilisateurs partout dans le monde, et requérant haute disponibilité et robustesse en cas de pannes dans plusieurs régions. Cette architecture permet un scaling élastique au niveau du réseau, de l'application et de la base de données. Elle vous permet d'aligner les coûts sur l'utilisation qui est faite de cette architecture, sans avoir à faire de compromis sur les performances, la disponibilité ou l'évolutivité.

Architecture

Le schéma suivant illustre l'architecture d'une application s'exécutant sur une infrastructure distribuée à l'échelle mondiale dans plusieurs régions Google Cloud.

Architecture de déploiement à l'échelle mondiale à l'aide de Compute Engine et de Spanner

Dans cette architecture, un équilibreur de charge global répartit les requêtes entrantes vers les serveurs Web des régions appropriées en fonction de leur disponibilité, de leur capacité et de leur proximité avec la source du trafic. Une couche d'équilibrage de charge interne interrégional gère la répartition du trafic depuis les serveurs Web vers les serveurs d'applications appropriés, en fonction de leur disponibilité et de leur capacité. Les serveurs d'applications écrivent et lisent des données dans une base de données répliquée de manière synchrone, disponible dans toutes les régions.

L'architecture se compose des ressources Google Cloud suivantes :

Composant Objectif
Équilibreur de charge externe global

L'équilibreur de charge externe global reçoit et distribue les requêtes des utilisateurs à l'application. L'équilibreur de charge externe global annonce une seule adresse IP anycast, mais il est mis en œuvre sous la forme d'un grand nombre de proxys sur différents services Google Front End (GFE). Les requêtes des clients sont dirigées vers le GFE le plus proche du client.

Selon vos besoins, vous pouvez utiliser un équilibreur de charge d'application externe global ou un équilibreur de charge réseau proxy externe global. Pour en savoir plus, consultez la page Choisir un équilibreur de charge.

Pour protéger votre application contre les menaces telles que les attaques par déni de service distribué (attaque DDoS) et les scripts intersites (XSS), vous pouvez utiliser les stratégies de sécurité Google Cloud Armor.
Groupes d'instances gérés (MIG) régionaux pour le niveau Web

Le niveau Web de l'application est déployé sur des VM Compute Engine qui sont rattachées à des MIG régionaux. Ces MIG correspondent aux backends de l'équilibreur de charge global.

Chaque MIG contient des VM Compute Engine réparties dans trois zones différentes. Chacune de ces VM héberge une instance indépendante du niveau Web de l'application.

Couche d'équilibrage de charge interne interrégional

Les équilibreurs de charge internes avec des backends interrégionaux gèrent la répartition du trafic provenant des VM du niveau Web de n'importe quelle région vers les VM du niveau application, sur l'ensemble des régions.

Selon vos besoins, vous pouvez utiliser un équilibreur de charge d'application interne interrégional ou un équilibreur de charge réseau proxy interne interrégional. Pour en savoir plus, consultez la page Choisir un équilibreur de charge.

MIG régionaux pour le niveau application

Le niveau application est déployé sur des VM Compute Engine qui sont rattachées à des MIG régionaux. Ces MIG correspondent aux backends de la couche d'équilibrage de charge interne.

Chaque MIG contient des VM Compute Engine réparties dans trois zones différentes. Chaque VM héberge une instance indépendante du niveau Application.

Instance Spanner multirégionale

L'application écrit et lit des données dans une instance Spanner multirégionale. La configuration multirégionale de cette architecture comprend les instances répliquées suivantes :

  • Quatre instances répliquées en lecture/écriture situées dans des zones distinctes et réparties sur deux régions
  • Une instance répliquée témoin dans une troisième région
Réseau et sous-réseaux de cloud privé virtuel (VPC)

Toutes les ressources de l'architecture utilisent un seul réseau VPC. Le réseau VPC comporte les sous-réseaux suivants :

  • Un sous-réseau dans chaque région pour les VM des serveurs Web
  • Un sous-réseau dans chaque région pour les VM des serveurs d'applications
  • (Non illustré dans le schéma de l'architecture) Un sous-réseau proxy réservé dans chaque région pour l'équilibreur de charge interne interrégional

Au lieu d'utiliser un seul réseau VPC, vous pouvez créer un réseau VPC distinct dans chaque région et connecter les réseaux à l'aide de Network Connectivity Center.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants :

  • Compute Engine : service de calcul sécurisé et personnalisable qui vous permet de créer et d'exécuter des machines virtuelles au sein de l'infrastructure de Google.
  • Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
  • Spanner : service de base de données relationnelle hautement évolutif, cohérent à l'échelle mondiale.

Considérations de conception

Cette section fournit des conseils pour vous aider à utiliser cette architecture de référence afin de développer une architecture répondant à vos exigences spécifiques en termes de conception, de sécurité et de conformité du système, de fiabilité, de coût, d'efficacité opérationnelle et de performances.

Conception du système

Cette section vous aide à choisir des régions Google Cloud pour votre déploiement mondial et à sélectionner les services Google Cloud appropriés.

Sélection de la région

Lorsque vous choisissez les régions Google Cloud dans lesquelles vos applications doivent être déployées, tenez compte des facteurs et exigences suivants :

  • Disponibilité des services Google Cloud dans chaque région. Pour en savoir plus, consultez la page Produits disponibles par emplacement.
  • Disponibilité des types de machines Compute Engine dans chaque région. Pour en savoir plus, consultez la page Régions et zones.
  • Exigences relatives à la latence tolérée par l'utilisateur final.
  • Coût des ressources Google Cloud.
  • Coûts des transferts de données interrégionaux.
  • Exigences réglementaires.

Certains de ces facteurs et exigences peuvent impliquer des compromis. Par exemple, la région la plus rentable en termes de coûts peut ne pas avoir l'empreinte carbone la plus basse. Pour en savoir plus, consultez la page Choisir des zones géographiques et des régions dans le framework d'architecture Google Cloud.

Services de calcul

L'architecture de référence décrite dans ce document utilise des VM Compute Engine pour les niveaux Web et application. Selon les exigences de votre application, vous pouvez choisir parmi d'autres services de calcul Google Cloud :

  • Vous pouvez exécuter des applications conteneurisées dans des clusters Google Kubernetes Engine (GKE). GKE est un moteur d'orchestration de conteneurs qui automatise le déploiement, le scaling et la gestion des applications conteneurisées.
  • Si vous préférez concentrer vos efforts informatiques sur vos données et vos applications plutôt que sur la configuration et l'exploitation des ressources d'infrastructure, vous pouvez utiliser des services sans serveur tels que Cloud Run et Cloud Functions.

La décision d'utiliser des VM, des conteneurs ou des services sans serveur implique un compromis entre la flexibilité de la configuration et les efforts de gestion. Les VM et les conteneurs offrent davantage de flexibilité de configuration, mais vous êtes responsable de la gestion des ressources. Dans une architecture sans serveur, vous déployez des charges de travail sur une plate-forme préconfigurée qui nécessite un effort de gestion minimal. Pour en savoir plus sur le choix des services de calcul appropriés pour vos charges de travail dans Google Cloud, consultez la page Choisir et gérer les ressources de calcul dans le framework d'architecture Google Cloud.

Services de stockage

L'architecture présentée dans ce document utilise des volumes Persistent Disk régionaux pour les VM. Les volumes Persistent Disk régionaux permettent une réplication synchrone des données sur deux zones d'une même région. Les données stockées sur des volumes Persistent Disk ne sont pas répliquées entre les régions.

Les autres options de stockage pour les déploiements multirégionaux incluent des buckets Cloud Storage birégionaux ou multirégionaux. Les objets stockés dans un bucket birégional ou un multirégional sont stockés de manière redondante dans au moins deux emplacements géographiques distincts. Les métadonnées sont écrites de manière synchrone entre les régions, et les données sont répliquées de manière asynchrone. Pour les buckets birégionaux, vous pouvez utiliser la réplication turbo, qui garantit une réplication plus rapide entre les régions. Pour en savoir plus, consultez la section Disponibilité et durabilité des données.

Pour stocker des fichiers amenés à être partagés sur plusieurs VM d'une région, par exemple l'ensemble des VM du niveau Web ou du niveau application, vous pouvez utiliser une instance Filestore Enterprise. Les fichiers que vous stockez dans une instance Filestore Enterprise sont répliqués de manière synchrone sur trois zones de la région. Cette réplication garantit la haute disponibilité et la robustesse en cas de pannes zonales. Vous pouvez stocker sur l'instance Filestore des fichiers de configuration partagés, des outils et utilitaires courants, ainsi que des journaux centralisés, et installer l'instance sur plusieurs VM.

Lorsque vous concevez le stockage pour vos charges de travail multirégionales, tenez compte des caractéristiques fonctionnelles des charges de travail, des exigences de résilience, des attentes en termes de performances et des objectifs de coûts. Pour en savoir plus, consultez la section Concevoir une stratégie de stockage optimale pour votre charge de travail cloud.

Des services de base de données

L'architecture de référence décrite dans ce document utilise Spanner, une base de données entièrement gérée, à évolutivité horizontale, distribuée à l'échelle mondiale et répliquée de manière synchrone. Nous recommandons une configuration Spanner multirégionale pour les déploiements critiques nécessitant une forte cohérence interrégionale. Spanner accepte la réplication interrégionale synchrone sans temps d'arrêt pour le basculement, la maintenance ou le redimensionnement.

Pour en savoir plus sur les autres services de base de données gérés que vous pouvez choisir en fonction de vos besoins, consultez la page Bases de données Google Cloud. Lorsque vous choisissez et configurez la base de données pour un déploiement multirégional, tenez compte des exigences de votre application concernant la cohérence interrégionale des données et soyez attentif aux compromis sur les performances et les coûts.

Options d'équilibrage de charge externe

Une architecture utilisant un équilibreur de charge externe global, telle que celle décrite dans ce document, est compatible avec certaines fonctionnalités qui vous aident à améliorer la fiabilité de vos déploiements. Par exemple, si vous utilisez l'équilibreur de charge d'application externe global, vous pouvez mettre en œuvre la mise en cache périphérique à l'aide de Cloud CDN.

Si votre application nécessite une terminaison TLS (Transport Layer Security) dans une région spécifique, ou si vous avez besoin de diffuser du contenu provenant de régions spécifiques, vous pouvez acheminer le trafic vers différentes régions en combinant Cloud DNS à des équilibreurs de charge régionaux. Pour en savoir plus sur les différences entre les équilibreurs de charge régionaux et mondiaux, consultez les ressources documentaires suivantes :

Sécurité et conformité

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir et créer une topologie mondiale dans Google Cloud, qui répond aux exigences de sécurité et de conformité de vos charges de travail.

Protection contre les menaces

Pour protéger votre application contre des menaces telles que les attaques DDoS et les scripts XSS, vous pouvez utiliser les stratégies de sécurité Google Cloud Armor. Chaque stratégie est un ensemble de règles qui spécifient certaines conditions devant être évaluées, et les mesures à prendre lorsque ces conditions sont remplies. Par exemple, une règle peut spécifier que le trafic doit être refusé si l'adresse IP source du trafic entrant correspond à une adresse IP ou à une plage CIDR spécifique. Vous pouvez également appliquer des règles de pare-feu d'application Web (WAF) préconfigurées. Pour en savoir plus, consultez la section Présentation des stratégies de sécurité.

Accès externe pour les VM

Dans l'architecture de référence décrite dans ce document, les VM hébergeant le niveau application et le niveau Web n'ont pas besoin d'un accès entrant depuis Internet. N'attribuez pas d'adresses IP externes à ces VM. Les ressources Google Cloud ne disposant que d'une adresse IP interne privée peuvent toujours accéder à certains services et API Google à l'aide de Private Service Connect ou de l'accès privé à Google. Pour en savoir plus, consultez la section Options d'accès privé pour les services.

Pour activer les connexions sortantes sécurisées à partir des ressources Google Cloud ne disposant que d'adresses IP privées, comme les VM Compute Engine de cette architecture de référence, vous pouvez utiliser le proxy Web sécurisé ou Cloud NAT.

Sécurité des images de VM

Pour vous assurer que vos VM n'utilisent que des images approuvées (c'est-à-dire, des images comportant des logiciels conformes à vos règles ou à vos exigences de sécurité), vous pouvez définir une règle d'administration limitant l'utilisation d'images dans des projets d'images publiques spécifiques. Pour en savoir plus, consultez la page Configurer des règlements relatifs aux images de confiance.

Droits des comptes de service

Dans les projets Google Cloud pour lesquels l'API Compute Engine est activée, un compte de service par défaut est créé automatiquement. Pour les organisations Google Cloud créées avant le 3 mai 2024, ce compte de service par défaut se voit attribuer le rôle IAM Éditeur (roles/editor), sauf si ce comportement est désactivé.

Par défaut, le compte de service par défaut est associé à toutes les VM que vous créez à l'aide de Google Cloud CLI ou de la console Google Cloud. Le rôle Éditeur inclut un large éventail d'autorisations. L'association du compte de service par défaut aux VM crée donc un risque de sécurité. Pour éviter ce risque, vous pouvez créer et utiliser des comptes de service dédiés pour chaque application. Pour spécifier les ressources auxquelles le compte de service peut accéder, utilisez des stratégies précises. Pour en savoir plus, consultez la section Limiter les droits des comptes de service dans le document "Bonnes pratiques d'utilisation des comptes de service".

Autres considérations sur la sécurité

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations de sécurité au niveau de la plate-forme, fournies dans le plan de base Enterprise.

Fiabilité

Cette section décrit les facteurs de conception à prendre en compte lorsque vous utilisez cette architecture de référence pour créer et exploiter une infrastructure fiable pour un déploiement mondial dans Google Cloud.

Autoscaling des MIG

Lorsque vous exécutez votre application sur plusieurs MIG régionaux, celle-ci reste disponible en cas de panne d'une zone isolée ou de panne régionale. La fonctionnalité d'autoscaling des MIG sans état vous permet de maintenir à des niveaux prévisibles la disponibilité et les performances de l'application. Pour contrôler le comportement d'autoscaling de vos MIG sans état, vous pouvez spécifier des métriques d'utilisation cibles, telles que l'utilisation moyenne du processeur. Vous pouvez également configurer l'autoscaling basé sur la planification pour les MIG sans état. Les MIG avec état ne peuvent pas faire l'objet d'un autoscaling. Pour en savoir plus, consultez la page Effectuer l'autoscaling des groupes d'instances.

Autoréparation de VM

Parfois, les VM qui hébergent votre application sont en cours d'exécution et disponibles, mais vous pouvez rencontrer des problèmes avec l'application proprement dite. Elle peut se figer, planter ou manquer de mémoire. Pour vérifier si une application répond comme prévu, vous pouvez configurer des vérifications d'état basées sur l'application dans le cadre de la règle d'autoréparation de vos MIG. Si l'application sur une VM particulière ne répond pas, le MIG répare automatiquement la VM. Pour en savoir plus sur la configuration de l'autoréparation, consultez la page Configurer la vérification d'état et l'autoréparation d'une application.

Emplacement de la VM

Dans l'architecture décrite dans ce document, le niveau Application et le niveau Web s'exécutent sur des VM Compute Engine réparties sur plusieurs zones. Cette répartition garantit que votre application résiste aux pannes zonales. Pour améliorer davantage sa robustesse, vous pouvez créer une stratégie d'emplacement par répartition et l'appliquer au modèle de MIG. Lorsque le MIG crée des VM, il les place alors dans chaque zone sur des serveurs physiques distincts (appelés hôtes) afin qu'elles résistent aux défaillances des hôtes individuels. Pour en savoir plus, consultez la page Appliquer des stratégies d'emplacement de répartition aux VM.

Planification de la capacité des VM

Pour vous assurer que la capacité des VM Compute Engine est disponible en cas de besoin pour l'autoscaling des MIG, vous pouvez créer des réservations. Une réservation garantit la capacité dans une zone spécifique pour un nombre spécifié de VM d'un type de machine que vous choisissez. Une réservation peut être spécifique à un projet ou partagée entre plusieurs projets. Pour en savoir plus sur les réservations, y compris les aspects concernant la facturation, consultez la section Réservations de ressources zonales Compute Engine.

Disques persistants avec état

Une bonne pratique de conception d'application consiste à éviter d'avoir à utiliser des disques locaux avec état. Toutefois, si l'exigence existe, vous pouvez configurer vos disques persistants pour qu'ils soient à état afin de vous assurer que les données sont conservées lors de la réparation ou de la recréation des VM. Cependant, nous vous recommandons de garder les disques de démarrage sans état, afin de pouvoir les mettre à jour facilement vers les dernières images comportant les nouvelles versions et les correctifs de sécurité. Pour en savoir plus, consultez la page Configurer des disques persistants avec état dans les groupes d'instances gérés.

Durabilité des données

Vous pouvez utiliser le service Backup and DR pour créer, stocker et gérer des sauvegardes des VM Compute Engine. L'outil de sauvegarde et reprise après sinistre stocke les données de la sauvegarde dans leur format d'origine lisible par l'application. Si nécessaire, vous pouvez restaurer vos charges de travail en production en utilisant directement les données d'un stockage de sauvegarde à long terme sans perdre du temps à déplacer les données ni à les préparer.

Compute Engine offre les options suivantes pour vous aider à garantir la durabilité des données stockées dans les volumes de disques persistants :

  • Les instantanés standards vous permettent de capturer l'état des volumes Persistent Disk à un moment précis. Les instantanés sont stockés de manière redondante dans plusieurs régions, avec des sommes de contrôle automatiques permettant de garantir l'intégrité des données. Les instantanés sont incrémentiels par défaut. Ils utilisent donc moins d'espace de stockage et vous réalisez des économies. Les instantanés sont stockés dans un emplacement Cloud Storage que vous pouvez configurer. Pour obtenir d'autres recommandations sur l'utilisation et la gestion des instantanés, consultez la page bonnes pratiques relatives aux instantanés de disques Compute Engine.
  • Les volumes Persistent Disk régionaux vous permettent d'exécuter des applications à disponibilité élevée, qui ne sont pas affectées en cas de défaillances des disques persistants. Lorsque vous créez un volume de disque persistant régional, Compute Engine gère une instance répliquée du disque dans une autre zone de la même région. Les données sont répliquées de manière synchrone sur les disques des deux zones. En cas de panne dans l'une des deux zones, les données restent disponibles.

Vous pouvez utiliser la fonctionnalité de sauvegarde et de restauration de Spanner pour vous protéger contre la corruption des données résultant d'erreurs des opérateurs et de problèmes associés à l'application. Pour en savoir plus, consultez la page Présentation des fonctionnalités Spanner de sauvegarde et de restauration.

Fiabilité de la base de données

Les données stockées dans une instance Spanner multirégionale sont répliquées de manière synchrone dans plusieurs régions. La configuration Spanner illustrée dans le schéma d'architecture précédent inclut les instances répliquées suivantes :

  • Quatre instances répliquées en lecture/écriture situées dans des zones distinctes et réparties sur deux régions
  • Une instance répliquée témoin dans une troisième région

Une opération d'écriture sur une instance Spanner multirégionale est confirmée après qu'au moins trois instances répliquées (situées dans des zones distinctes de deux régions) ont validé l'opération. En cas de défaillance zonale ou régionale, Spanner a accès à toutes les données, y compris celles des dernières opérations d'écriture, et continue de diffuser les requêtes de lecture et d'écriture.

Spanner utilise un stockage désagrégé dans lequel les ressources de calcul et de stockage sont découplées. Vous n'avez pas besoin de déplacer des données lorsque vous ajoutez la capacité de calcul pour la haute disponibilité ou le scaling. Les nouvelles ressources de calcul obtiennent des données lorsqu'elles en ont besoin à partir du nœud Colossus le plus proche. Le basculement et le scaling sont ainsi plus rapides et moins risqués.

Spanner assure la cohérence externe, qui est une propriété plus stricte que la sérialisabilité pour les systèmes de traitement de transactions. Pour en savoir plus, consultez les ressources suivantes :

Autres considérations sur la fiabilité

Lorsque vous créez l'architecture cloud pour votre charge de travail, passez en revue les bonnes pratiques et les recommandations liées à la fiabilité fournies dans la documentation suivante :

Optimisation des coûts

Cette section fournit des conseils pour optimiser les coûts de configuration et d'exploitation d'une topologie Google Cloud mondiale, que vous créez à l'aide de cette architecture de référence.

Types de machine des VM

Pour vous aider à optimiser l'utilisation de vos ressources de VM, Compute Engine propose des recommandations de types de machines. Utilisez les recommandations pour choisir les types de machines qui correspondent aux exigences de calcul de votre charge de travail. Pour les charges de travail ayant des besoins en ressources prévisibles, vous pouvez personnaliser le type de machine en fonction de vos besoins et réaliser des économies en utilisant des types de machines personnalisés.

Modèle de provisionnement de VM

Si votre application est tolérante aux pannes, les VM Spot peuvent vous aider à réduire les coûts Compute Engine pour les VM des niveaux Web et application. Le coût des VM Spot est nettement inférieur à celui des VM standards. Toutefois, Compute Engine peut arrêter ou supprimer les VM Spot de manière préemptive pour récupérer de la capacité. Les VM Spot conviennent aux jobs par lots pouvant tolérer la préemption et ne nécessitant pas de haute disponibilité. Les VM Spot offrent les mêmes types de machines, options et performances que les VM standards. Toutefois, lorsque la capacité des ressources d'une zone est limitée, les MIG risquent de ne pas pouvoir mener un scaling horizontal (c'est-à-dire créer des VM) jusqu'à la taille cible spécifiée tant que la capacité requise n'est pas disponible.

Utilisation des ressources de VM

La fonctionnalité d'autoscaling des MIG sans état permet à votre application de gérer sans heurt les hausses de trafic et de réduire les coûts lorsque les besoins en ressources sont faibles. Les MIG avec état ne peuvent pas faire l'objet d'un autoscaling.

Coûts associés à la base de données

Spanner permet de s'assurer que les coûts associés à votre base de données sont prévisibles. La capacité de calcul que vous spécifiez (nombre de nœuds ou d'unités de traitement) détermine la capacité de stockage. Les débits en lecture et en écriture évoluent de manière linéaire avec la capacité de calcul. Vous ne payez que ce que vous consommez. Si vous devez aligner les coûts avec les besoins de votre charge de travail, vous pouvez ajuster la taille de votre instance Spanner.

Licences tierces

Lorsque vous migrez des charges de travail tierces vers Google Cloud, vous pouvez peut-être réduire les coûts en utilisant vos propres licences (BYOL). Par exemple, pour déployer des VM Microsoft Windows Server, vous pouvez créer et utiliser une image BYOL Windows personnalisée plutôt que d'utiliser une image payante qui entraîne des coûts supplémentaires pour la licence tierce. Vous ne payez alors que pour l'infrastructure de VM que vous utilisez sur Google Cloud. Cette stratégie vous permet de continuer à tirer profit de vos investissements existants en licences tierces. Si vous décidez d'utiliser l'approche BYOL, nous vous recommandons d'effectuer les opérations suivantes :

  • Provisionnez le nombre de cœurs de CPU requis indépendamment de la mémoire, en utilisant les types de machines personnalisés. Cela permet de limiter le coût des licences tierces au nombre de cœurs de CPU dont vous avez besoin.
  • Réduisez le nombre de vCPU par cœur de 2 à 1 en désactivant le multithreading simultané (SMT) pour réduire vos coûts de licence de 50 %.

Autres considérations sur les coûts

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales fournies dans la section Framework d'architecture Google Cloud : optimisation des coûts.

Efficacité opérationnelle

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir et créer dans Google Cloud une topologie mondiale que vous pouvez exploiter efficacement.

Mises à jour de la configuration des VM

Pour mettre à jour la configuration des VM d'un MIG (par exemple, le type de machine ou l'image du disque de démarrage), vous devez créer un modèle d'instance avec la configuration requise, puis appliquer le nouveau modèle au MIG. Le MIG met à jour les VM à l'aide de la méthode de mise à jour que vous choisissez : automatique ou sélective. Choisissez une méthode appropriée en fonction de vos exigences en termes de disponibilité et d'efficacité opérationnelle. Pour en savoir plus sur ces méthodes de mise à jour de MIG, consultez la section Appliquer de nouvelles configurations de VM dans un MIG.

Images de VM

Pour vos modèles d'instances de MIG, au lieu d'utiliser des images publiques fournies par Google, nous vous recommandons de créer et d'utiliser des images personnalisées contenant les configurations et logiciels requis par vos applications. Vous pouvez regrouper vos images personnalisées dans une famille d'images personnalisées. Une famille d'images pointe toujours vers la plus récente des images qu'elle contient, ce qui permet aux modèles d'instance et aux scripts d'utiliser cette image sans qu'il soit nécessaire de mettre à jour les références pour désigner une version spécifique de l'image.

Modèles d'instances déterministes

Si les modèles d'instance que vous utilisez pour vos MIG incluent des scripts de démarrage permettant d'installer des logiciels tiers, assurez-vous qu'ils spécifient explicitement les paramètres d'installation des logiciels, tels que la version. Dans le cas contraire, lorsque le MIG crée les VM, le logiciel installé sur les VM risque de ne pas être cohérent. Par exemple, si votre modèle d'instance inclut un script de démarrage qui installe Apache HTTP Server 2.0 (le package apache2), assurez-vous que le script spécifie exactement la version de apache2 qui doit être installée, par exemple la version 2.4.53. Pour en savoir plus, consultez la page Modèles d'instances déterministes.

Migration vers Spanner

Vous pouvez migrer vos données vers Spanner à partir d'autres bases de données comme MySQL, SQL Server et Oracle Database. Le processus de migration dépend de facteurs tels que la base de données source, la taille de vos données, les contraintes de temps d'arrêt et la complexité du code de l'application. Pour vous aider à planifier et mettre en œuvre efficacement la migration vers Spanner, nous fournissons une gamme d'outils Google Cloud et d'outils tiers. Pour en savoir plus, consultez la page Présentation de la migration.

Administration des bases de données

Avec Spanner, vous n'avez pas besoin de configurer ni de surveiller la réplication ou le basculement. La réplication synchrone et le basculement automatique sont intégrés. Votre application ne subit aucun temps d'arrêt pour la maintenance de la base de données et le basculement. Pour réduire davantage la complexité opérationnelle, vous pouvez configurer l'autoscaling. Lorsque l'autoscaling est activé, vous n'avez pas besoin de surveiller ni de faire évoluer manuellement la taille de l'instance.

Autres considérations opérationnelles

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales pour l'efficacité opérationnelle décrites dans la section Framework d'architecture Google Cloud : excellence opérationnelle.

Optimisation des performances

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir et créer dans Google Cloud une topologie mondiale qui répond aux exigences de performances de vos charges de travail.

Emplacement de la VM

Pour les charges de travail nécessitant une faible latence réseau entre VM, vous pouvez créer une stratégie d'emplacement compact et l'appliquer au modèle de MIG. Lorsque le MIG crée des VM, il les place alors sur des serveurs physiques proches les uns des autres. Pour en savoir plus, consultez la section Réduire la latence à l'aide de stratégies de concentration.

Types de machine des VM

Compute Engine propose un large éventail de types de machines prédéfinis et personnalisables, que vous pouvez choisir sur la base de vos exigences en matière de coûts et de performances. Les types de machines sont regroupés en séries et familles de machines. Le tableau suivant récapitule les familles de machines recommandées pour différents types de charges de travail :

Prérequis Famille de machines recommandée
Le meilleur rapport prix/performances pour des charges de travail diverses Famille de machines à usage général
Performances les plus élevées par cœur, optimisées pour les charges de travail exigeantes en calcul Famille de machines optimisées pour le calcul
Ratio mémoire/vCPU élevé pour les charges de travail exigeantes en mémoire Famille de machines à mémoire optimisée
GPU pour des charges de travail massivement parallélisées Famille de machines optimisées pour les accélérateurs
Faible utilisation des cœurs et densité de stockage élevée Famille de machines optimisées pour le stockage

Pour en savoir plus, consultez le Guide des ressources de familles de machines et guide comparatif.

Multithreading de VM

Chaque processeur virtuel que vous allouez à une VM Compute Engine est mis en œuvre sous la forme d'un multithread matériel unique. Par défaut, deux processeurs virtuels partagent un cœur physique de processeur. Pour les charges de travail hautement parallèles ou qui effectuent des calculs à virgule flottante (tels que l'analyse de séquences génétiques et la modélisation des risques financiers), vous pouvez améliorer les performances en réduisant le nombre de threads s'exécutant sur chaque cœur de processeur physique. Pour en savoir plus, consultez la section Définir le nombre de threads par cœur.

Niveaux de service réseau

Les niveaux de service réseau vous permettent d'optimiser le coût et les performances réseau de vos charges de travail. Selon vos besoins, vous pouvez choisir le niveau Premium ou Standard.

L'architecture décrite dans ce document utilise un équilibreur de charge externe global avec une adresse IP externe et des backends situés dans plusieurs régions. Cette architecture nécessite l'utilisation du niveau Premium, qui exploite le réseau backbone mondial extrêmement fiable de Google pour vous aider à réduire au minimum la perte de paquets et la latence.

Si vous utilisez des équilibreurs de charge externes régionaux et que vous acheminez le trafic vers des régions à l'aide de Cloud DNS, vous avez le choix entre le niveau Premium ou Standard, selon vos besoins. Le prix du niveau Standard est inférieur à celui du niveau Premium. Le niveau Standard convient au trafic non sensible à la perte de paquets et qui ne présente pas d'exigences de faible latence.

Performances de Spanner

Lorsque vous provisionnez une instance Spanner, vous spécifiez la capacité de calcul de l'instance en fonction du nombre de nœuds ou d'unités de traitement. Surveillez l'utilisation des ressources de votre instance Spanner, et faites évoluer la capacité en fonction de la charge attendue et des exigences de performances de votre application. Vous pouvez définir un scaling manuel, ou bien automatique, de la capacité d'une instance Spanner. Pour en savoir plus, consultez la page Présentation de l'autoscaling.

Avec une configuration multirégionale, Spanner réplique les données de manière synchrone sur plusieurs régions. Cette réplication permet d'effectuer des opérations de lecture à faible latence à partir de plusieurs emplacements. En contrepartie, les opérations d'écriture subissent une latence plus élevée car les instances répliquées du quorum sont réparties sur plusieurs régions. Pour réduire le plus possible la latence des transactions en lecture-écriture dans une configuration multirégionale, Spanner utilise le routage optimisé vers la région responsable (activé par défaut).

Pour obtenir des recommandations afin d'optimiser les performances de votre instance Spanner et de vos bases de données, consultez les ressources documentaires suivantes :

Mise en cache

Si votre application diffuse des éléments de site Web statiques et si votre architecture inclut un équilibreur de charge d'application externe global, vous pouvez utiliser Cloud CDN pour mettre en cache le contenu statique fréquemment consulté, de sorte que celui-ci se trouve à proximité de vos utilisateurs. Cloud CDN peut vous aider à améliorer les performances pour vos utilisateurs, à réduire l'utilisation des ressources d'infrastructure dans le backend et à réduire vos coûts de diffusion réseau. Pour en savoir plus, consultez la page Performances Web plus rapides et protection Web améliorée pour l'équilibrage de charge.

Autres considérations sur les performances

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales fournies dans la section Framework d'architecture Google Cloud : optimisation des performances.

Étapes suivantes

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :