Bonnes pratiques pour la sélection des régions Compute Engine

Cet article décrit les critères à prendre en compte lors du choix des régions Google Cloud à utiliser pour vos ressources Compute Engine, une décision généralement prise par les architectes cloud ou les équipes de gestion de l'ingénierie. Ce document se concentre principalement sur l'aspect du processus de sélection se rapportant à la latence. Il est destiné à être utilisé dans le contexte d'applications grand public, telles que les applications ou jeux mobiles ou Web, mais de nombreux concepts peuvent aussi bien s'appliquer à d'autres cas d'utilisation.

Google propose plusieurs régions du monde entier où vous pouvez déployer vos ressources Compute Engine. Plusieurs facteurs influencent le choix des régions :

  • Les restrictions spécifiques à la région
  • La latence côté utilisateur par région
  • Les exigences de votre application en matière de latence
  • Le niveau de contrôle sur la latence
  • L'équilibre entre faible latence et simplicité

Terminologie

Région
Un secteur géographique indépendant où vous exécutez vos ressources. Chaque région est composée de zones, généralement au moins trois.
zone
Un endroit servant au déploiement des ressources Google Cloud au sein d'une région. Le positionnement des ressources dans différentes zones d'une région les protège contre les pannes d'infrastructure qui les affecteraient toutes en même temps.
Ressources Compute Engine
Dans Compute Engine, les ressources telles que les instances de machine virtuelle sont déployées dans une zone au sein d'une région. D'autres produits, tels que Google Kubernetes Engine et Dataflow, utilisent les ressources Compute Engine et peuvent donc être déployés dans les mêmes régions ou zones.
Délai aller-retour (DAR)
Temps nécessaire à l'envoi d'un paquet IP et à la réception de la confirmation.

Quand choisir les régions Compute Engine

Au début de la phase d'architecture d'une application, déterminez le nombre de régions nécessaires et quelles régions utiliser. Le choix que vous ferez peut avoir des répercussions sur votre application. Par exemple :

  • L'architecture de votre application peut changer si vous synchronisez certaines données entre plusieurs copies, car les mêmes utilisateurs peuvent se connecter via des régions différentes à des moments différents.
  • Le prix diffère selon les régions.
  • Le processus de déplacement d'une application et de ses données entre les régions est fastidieux, et parfois coûteux, et devrait donc être évité une fois l'application lancée.

Facteurs à prendre en compte lors de la sélection des régions

Les gens ont tendance à déployer leur application dans la région où ils se trouvent. Ce faisant, ils oublient souvent de se demander si cela représente la meilleure expérience utilisateur possible. Supposons que vous êtes situé en Europe, que votre base d'utilisateurs est internationale et que vous souhaitez un déploiement dans une région unique. La plupart des gens envisageraient un déploiement dans une région européenne, mais il est généralement préférable d'héberger cette application dans une région des États-Unis, car il s'agit du pays le plus connecté aux autres régions.

Plusieurs facteurs doivent influencer le lieu où vous déciderez de déployer votre application.

Latence

Le principal facteur à prendre en compte est la latence de vos expériences utilisateur. Il s'agit cependant d'un problème complexe, car la latence côté utilisateur est affectée par plusieurs aspects, tels que les systèmes de mise en cache et d'équilibrage de charge.

Dans les cas d'utilisation en entreprise, la latence vers les systèmes sur site ou la latence pour un certain sous-ensemble d'utilisateurs ou de partenaires revêt une plus grande importance. Par exemple, choisir la région la plus proche de vos développeurs ou des services de bases de données sur site interconnectés avec Google Cloud peut être le facteur décisif.

Tarifs

Les coûts des ressources Google Cloud diffèrent selon les régions. Les ressources suivantes peuvent vous aider à estimer ces coûts :

Si vous optez pour un déploiement dans plusieurs régions, sachez qu'il existe des frais de transfert de données pour les données synchronisées entre les régions.

Hébergement en colocation avec d'autres services Google Cloud

Dans la mesure du possible, hébergez vos ressources Compute Engine en colocation avec d'autres services Google Cloud. Bien que la plupart des services sensibles à la latence soient disponibles dans toutes les régions, certains services ne sont disponibles que dans des emplacements spécifiques.

Disponibilité de type de machine

Certaines plates-formes de processeur et certains types de machines ne sont pas disponibles dans toutes les régions. La disponibilité de plates-formes de processeur ou de types d'instance spécifiques varie selon les régions et même selon les zones. Si vous souhaitez déployer des ressources à l'aide de certains types de machines, renseignez-vous sur la disponibilité zonale de ces ressources.

Quotas de ressources

Votre capacité à déployer des ressources Compute Engine est limitée par les quotas de ressources régionaux. Assurez-vous donc de demander un quota suffisant pour les régions dans lesquelles vous souhaitez faire votre déploiement. Si vous planifiez un déploiement particulièrement important, contactez l'équipe commerciale au plus tôt pour discuter de vos choix quant à la sélection des régions. Cela vous permettra de vous assurer que vous disposez de quotas suffisants.

Pourcentage d'énergie bas carbone

Pour alimenter chaque région Google Cloud, Google utilise l'électricité du réseau électrique où se trouve la région. Cette électricité génère plus ou moins d'émissions de carbone en fonction du type de centrale électrique qui produit de l'électricité pour ce réseau, au moment où Google la consomme. Google s'est récemment fixé pour objectif de disposer, d'ici 2030, d'électricité bas carbone pour alimenter vos applications au moment et à l'endroit où vous en avez besoin, 24 heures sur 24, dans toutes les régions Google Cloud.

En attendant que cet objectif soit atteint, chaque région Google Cloud est alimentée par une combinaison d'énergies carbone et sans émission de carbone toutes les heures. Nous appelons cette métrique notre pourcentage d'énergie bas carbone (CFE%) et nous publions le pourcentage d'énergie bas carbone pour les régions Google Cloud. Pour les nouvelles applications sur Google Cloud, vous pouvez utiliser ce tableau pour commencer à prendre en compte l'impact carbone dans vos décisions liées à l'architecture. Le choix d'une région avec un pourcentage d'énergie bas carbone plus élevé signifie que votre application sera en moyenne alimentée par une énergie bas carbone la plupart du temps, réduisant ainsi ses émissions brutes.

Évaluer les exigences en termes de latence

La latence est souvent un critère clé quand il s'agit de choisir des régions, car une latence élevée pour les utilisateurs peut conduire à une expérience utilisateur de qualité inférieure. Si vous pouvez modérer certains aspects de la latence, d'autres restent toutefois hors de votre contrôle.

Lorsqu'ils procèdent à des optimisations de latence, les architectes système ne prennent souvent en compte que la latence du réseau ou la distance entre le FAI de l'utilisateur et l'instance de machine virtuelle. Cependant, ce n'est là qu'un des nombreux facteurs affectant la latence côté utilisateur comme vous pouvez le constater dans le schéma suivant.

Évaluer la latence pour sélectionner des régions Compute Engine

En tant qu'architecte d'application, vous pouvez optimiser la sélection de la région et la latence des applications, mais vous n'avez aucun contrôle sur le dernier kilomètre et la latence côté utilisateur vers les points de présence (POP) périphériques de Google les plus proches.

La sélection de la région affecte seulement la latence vers la région Compute Engine, et non pas la latence totale. Selon le cas d'utilisation, elle ne constitue parfois qu'une petite partie seulement de la latence globale. Par exemple, si vos utilisateurs utilisent principalement des réseaux cellulaires, il peut s'avérer inutile d'essayer d'optimiser vos régions, car cela n'affectera guère la latence totale des utilisateurs.

Latence du dernier kilomètre

La latence de ce segment varie en fonction de la technologie utilisée pour accéder à Internet. Par exemple, la latence habituelle pour atteindre le FAI est de 1 à 10 ms sur des réseaux modernes. Inversement, les latences habituelles sur un réseau mobile 3G sont comprises entre 100 et 500 ms. La plage de latence pour les fournisseurs DSL et les opérateurs de réseau câblé est d'environ 10 à 60 ms.

Interface Google et latence du POP périphérique

En fonction de votre modèle de déploiement, la latence vers la périphérie du réseau Google a aussi son importance. C'est là que les produits mondiaux d'équilibrage de charge mettent fin aux sessions TCP et SSL, et que Cloud Content Delivery Network diffuse les résultats mis en cache. Sur la base du contenu diffusé, de nombreux allers-retours risquent déjà de finir ici, car seule une partie des données doit être récupérée sur toute la distance. Cette latence peut être considérablement plus élevée si vous utilisez le niveau de service réseau standard.

Latence de la région Compute Engine

La requête de l'utilisateur entre dans le réseau Google au niveau du POP périphérique. La région Compute Engine représente l'endroit où sont situées les ressources Google Cloud traitant les requêtes. Ce segment correspond à la latence entre le POP périphérique et la région Compute Engine, et il est entièrement situé dans le réseau mondial de Google.

Latence de l'application

Il s'agit de la latence observée à partir du moment où l'application répond aux requêtes. Elle inclut le temps nécessaire à l'application pour traiter la requête.

Différentes applications ont des exigences de latence différentes. En fonction de l'application, les utilisateurs seront plus conciliants face aux problèmes de latence. Les applications qui interagissent de manière asynchrone ou les applications mobiles ayant un seuil de latence élevé (100 millisecondes ou plus) peuvent être déployées dans une seule région sans répercussion sur l'expérience utilisateur. Toutefois, pour les applications telles que les jeux en temps réel, une latence de quelques millisecondes peut avoir un impact plus important sur l'expérience utilisateur. Déployez ces types d'applications dans plusieurs régions proches des utilisateurs.

Modèles de déploiement global

Cette section explique la manière dont différents modèles de déploiement affectent les facteurs de latence.

Déploiement dans une seule région

L'image suivante illustre un déploiement dans une seule région.

Latence d'un déploiement d'interface dans une seule région

Même si votre application dessert une base d'utilisateurs mondiale, dans de nombreux cas, la meilleure option consiste à choisir une seule région. Les avantages liés à la réduction de la latence pourraient ne pas compenser la complexité du déploiement multirégion. Même avec un déploiement dans une seule région, vous pouvez toujours utiliser des optimisations, telles que Cloud CDN et l'équilibrage global de charge, pour réduire la latence côté utilisateur. Vous pouvez choisir d'utiliser une deuxième région pour des raisons liées à la sauvegarde et à la récupération après sinistre, mais cela n'affectera pas le chemin de desserte de l'application et n'affectera donc pas non plus la latence côté utilisateur.

Interface distribuée dans plusieurs régions et backend situé dans une seule région

Le schéma suivant illustre un modèle de déploiement dans lequel l'interface est distribuée dans plusieurs régions, tandis que le backend est limité à une seule région. Ce modèle vous permet de bénéficier d'une latence inférieure sur les serveurs frontend, sans avoir à synchroniser les données sur plusieurs régions.

Latence d'un déploiement d'interface distribué

Ce modèle de déploiement offre une latence côté utilisateur qui est faible lorsqu'une requête utilisateur typique ne nécessite pas ou peu de requêtes de données vers le backend central avant que l'application puisse renvoyer un résultat. Une application qui déploie une couche de mise en cache intelligente sur l'interface ou traite les écritures de données de manière asynchrone en constitue un exemple. En revanche, ce modèle risque de ne présenter que peu d'intérêt pour une application qui effectue de nombreuses requêtes nécessitant un aller-retour complet vers le backend.

Interface et backend distribués dans plusieurs régions

Un modèle de déploiement dans lequel vous distribuez l'interface et le backend dans plusieurs régions vous permet de minimiser la latence côté utilisateur, car l'application peut fournir une réponse complète à toute requête localement. Cependant, ce modèle présente une complexité supplémentaire, car toutes les données doivent être stockées et accessibles localement. Pour répondre à toutes les requêtes des utilisateurs, les données doivent être entièrement répliquées dans toutes les régions.

Latence d'un déploiement distribué dans plusieurs régions

Spanner, le service de base de données géré offrant une cohérence à l'échelle mondiale, propose une option multirégionale sur trois continents composée non seulement d'instances en lecture-écriture répliquées aux États-Unis, mais aussi de deux instances en lecture répliquées en Europe et en Asie. Cette option fournit un accès en lecture à faible latence aux données des instances de calcul situées aux États-Unis, en Europe ou en Asie. Si votre service cible les États-Unis, une option multirégionale avec réplication aux États-Unis existe également.

Si vous décidez d'exécuter votre propre service de base de données sur Compute Engine, vous devez procéder vous-même à la réplication des données. La réplication est une tâche complexe, car il est difficile de maintenir les données synchronisées de manière cohérente à l'échelle mondiale. La situation est plus facile à gérer si les écritures dans la base de données sont réalisées de manière asynchrone dans une seule région, tandis que les autres régions hébergent des instances dupliquées en lecture seule.

La réplication de bases de données sur plusieurs régions présente ses difficultés, et nous vous recommandons de faire appel à un partenaire solide et expérimenté dans ce domaine, tel que Datastax pour la réplication Cassandra.

Applications parallèles multiples

Selon la nature de votre application, vous pouvez préserver la faible latence côté utilisateur tout en réduisant le besoin de réplication constante des données si vous optez pour une variante de l'approche précédente. Comme illustré dans l'image suivante, cette variante repose sur plusieurs applications parallèles, toutes composées d'une interface et d'un backend, les utilisateurs étant dirigés vers l'application appropriée. Seule une petite partie des données est partagée entre les sites.

Latence des applications parallèles

Par exemple, lorsque vous exploitez une entreprise de vente au détail, vous pouvez servir des utilisateurs de différentes régions à travers différents domaines de pays, et exploiter des sites parallèles dans toutes ces régions, en ne synchronisant les données produits et utilisateurs que lorsque cela s'avère nécessaire. Les sites locaux gèrent la disponibilité locale de leur stock, et les utilisateurs se connectent à un site hébergé localement en sélectionnant un domaine de pays. Lorsqu'un utilisateur accède à un domaine de pays différent, il est redirigé vers le domaine approprié.

Un autre exemple concerne les jeux en temps réel. Peut-être ne disposez-vous que d'un service de hall global dans lequel les utilisateurs choisissent une salle de jeux ou un monde proche de leur emplacement actuel, et où ces salles ou mondes ne partagent pas de données entre eux.

Un troisième exemple consiste à proposer le SaaS (Software as a Service) dans différentes régions où l'emplacement des données est sélectionné lors de la création du compte en fonction de l'emplacement de l'utilisateur ou en fonction du choix qu'il aura émis. Une fois qu'il est connecté, l'utilisateur est redirigé vers un sous-domaine spécifique à son emplacement et utilise ainsi le service au niveau régional.

Optimiser la latence entre les utilisateurs et les régions

Quel que soit votre modèle de déploiement, vous pouvez combiner plusieurs méthodes d'optimisation afin de réduire la latence visible pour l'utilisateur final. Certaines de ces méthodes sont des fonctionnalités Google Cloud, tandis que d'autres nécessitent que vous modifiiez votre application.

Utiliser la mise en réseau de niveau Premium

Google propose des niveaux de service réseau Premium (par défaut) et Standard. Le trafic de niveau Standard est acheminé via des FAI de transit depuis les régions Google Cloud. Le niveau Premium offre quant à lui une latence réduite en acheminant le trafic via le réseau privé mondial de Google. La mise en réseau de niveau Premium réduit la latence côté utilisateur et doit être utilisée pour toutes les parties de l'application dans le trajet de desserte. La mise en réseau de niveau Premium est également nécessaire pour utiliser les produits d'équilibrage de charge mondial de Google.

Utiliser Cloud Load Balancing et Cloud CDN

Cloud Load Balancing, à savoir l'équilibrage de charge HTTP(S) et l'équilibrage de charge proxy TCP et SSL, par exemple, vous permet de rediriger automatiquement les utilisateurs vers la région la plus proche de leur emplacement où des backends ont encore de la capacité.

Même si votre application n'est déployée que dans une seule région, le fait d'utiliser Cloud Load Balancing permet de réduire la latence côté utilisateur, car les sessions TCP et SSL sont interrompues à la périphérie du réseau. Vous pourrez interrompre facilement le trafic utilisateur avec HTTP/2 et le protocole QUIC (Quick UDP Internet Connections). Vous pourrez également intégrer Cloud CDN avec l'équilibrage de charge HTTP(S) pour fournir des éléments statiques directement depuis la périphérie du réseau, ce qui réduira davantage la latence côté utilisateur.

Mettre en cache localement

Lorsque vos emplacements d'interface sont différents de vos emplacements de backend, veillez à mettre en cache les réponses des services de backend autant que possible. Lorsque l'interface et le backend se trouvent dans la même région, la latence des applications est réduite, car le nombre de requêtes de longue durée est également réduit. Vous pouvez par exemple utiliser Memorystore pour Redis, un magasin de stockage de données en mémoire entièrement géré.

Optimiser l'application client ou l'interface Web

Vous pouvez utiliser des techniques côté client (une application mobile ou une interface Web) pour optimiser la latence côté utilisateur. Par exemple, effectuez un préchargement d'éléments ou de données en cache dans l'application.

Vous pouvez également optimiser la manière dont l'application récupère les informations en réduisant le nombre de requêtes et en récupérant les informations en parallèle autant que possible.

Mesurer la latence côté utilisateur

Une fois que vous avez défini vos exigences en termes de latence, étudiez votre base d'utilisateurs pour déterminer le placement idéal de vos ressources Google Cloud. Selon qu'il s'agisse d'une application nouvelle ou existante, vous pouvez utiliser différentes stratégies.

Utilisez les stratégies suivantes pour mesurer la latence vers les partenaires auxquels vous avez accès pendant la diffusion de l'application, ou pour mesurer la latence vers votre réseau sur site qui peut être interconnecté avec votre projet Google Cloud via Cloud VPN ou une interconnexion dédiée.

Estimer la latence pour les nouvelles charges de travail

Si vous ne disposez pas déjà d'une application avec une base d'utilisateurs semblable à celle de votre nouvelle application, estimez la latence à partir de différentes régions Google Cloud en fonction de la répartition approximative de votre base d'utilisateurs prévue.

Estimez à 1 ms la latence aller-retour pour 100 km parcourus. Étant donné que les réseaux ne suivent pas une trajectoire idéale entre la source et la destination, vous pouvez généralement deviner que la distance réelle sera environ égale à 1,5 à 2 fois la distance mesurée sur une carte. Bien entendu, dans certaines régions moins densément peuplées, les réseaux pourraient suivre une trajectoire encore moins idéale. La latence qu'ajoutent les équipements actifs au sein des réseaux des FAI est généralement négligeable si l'on considère les distances interrégionales.

Ces chiffres peuvent vous aider à estimer la latence vers les nœuds de POP périphériques et les nœuds Cloud CDN, ainsi que vers les régions Compute Engine du monde entier, répertoriées sur la carte du réseau.

Mesurer la latence vers les utilisateurs existants

Si vous disposez déjà d'une application avec une base d'utilisateurs semblable, vous pouvez utiliser plusieurs outils afin d'estimer les latences avec plus de précision.

  • Utilisateurs représentatifs : si vous avez des utilisateurs ou des partenaires représentant un échantillon de votre répartition géographique et souhaitant travailler avec vous, ou si vous avez des employés dans ces pays, demandez-leur de mesurer la latence vers différentes régions Google Cloud. Des sites Web tiers tels que Google Cloud ping peuvent vous aider à obtenir certaines mesures.
  • Journaux d'accès : si vous avez une application active hébergée hors de Google Cloud, utilisez les données des journaux d'accès pour obtenir un échantillon approximatif d'utilisateurs. Vos journaux peuvent fournir des informations sur le pays ou la ville de ces utilisateurs, ce qui vous permettra d'estimer les latences.
  • Adresse IP : si vous avez accès aux adresses IP de vos utilisateurs, créez des scripts pour tester l'accessibilité et les latences à partir de différentes régions Google Cloud. Si leur pare-feu bloque vos vérifications, essayez de sélectionner de manière aléatoire le dernier octet IP pour obtenir une réponse d'un autre appareil dont la latence est semblable à celle de votre application.

  • Informations sur la latence provenant de Google Cloud : si vous avez disposez déjà d'une application dans Google Cloud, il existe plusieurs façons de collecter des informations sur la latence.

Connectivité mondiale

Lorsque vous estimez la latence, tenez compte de la topologie du réseau mondial de Google.

  • POP : les points où le trafic utilisateur entre dans le réseau.
  • Nœuds Cloud CDN : les endroits où le trafic est mis en cache.
  • Régions : les endroits où vos ressources peuvent être situées.
  • Connectivité : entre les POP et les régions.

Accédez au site PeeringDB pour obtenir une liste des emplacements où une interconnexion existe entre Google et d'autres FAI.

Assurez-vous de prendre en compte la topologie interrégionale lorsque vous choisissez les régions de déploiement. Par exemple, si vous souhaitez déployer une application avec une base d'utilisateurs mondiale dans une seule région, il est généralement préférable que cette application soit hébergée dans l'une des régions des États-Unis, car les États-Unis sont connectés à la plupart des régions. Bien qu'il existe une connectivité directe entre de nombreux continents, il existe des cas où celle-ci fait défaut (entre l'Europe et l'Asie, par exemple, ce qui oblige le trafic entre ces deux continents à passer par les États-Unis).

Si votre application est hébergée dans plusieurs régions et que vous devez synchroniser vos données, soyez conscient de la latence entre ces régions. Bien que cette latence puisse changer avec le temps, elle est généralement stable. Mesurez la latence vous-même en créant des instances de test dans toutes les régions potentielles ou utilisez des sites Web tiers pour vous faire une idée des latences actuelles entre les régions.

Faire la synthèse

Maintenant que vous avez pris en compte les exigences de latence, les modèles de déploiement potentiels et la répartition géographique de votre base d'utilisateurs, vous comprenez comment ces facteurs affectent la latence dans certaines régions. Il est temps désormais de décider dans quelles régions lancer votre application.

Bien qu'il n'existe pas de méthode correcte pour comparer les différents facteurs, la méthodologie suivante, qui vous est présentée étape par étape, peut vous aider à faire un choix :

  1. Vérifiez si des facteurs non liés à la latence, tels que le prix ou l'hébergement en colocation, vous empêchent de procéder à un déploiement dans des régions spécifiques. Supprimez-les de votre liste de régions.
  2. Choisissez un modèle de déploiement basé sur les exigences de latence et l'architecture générale de l'application. Pour la plupart des applications mobiles et autres applications pour lesquelles la latence n'est pas un facteur critique, le choix idéal pourrait être un déploiement dans une seule région, avec une distribution des contenus pouvant être mis en cache sur Cloud CDN et une terminaison SSL à la périphérie.

  3. Selon votre modèle de déploiement, choisissez des régions en fonction de la répartition géographique de votre base d'utilisateurs et de vos mesures de latence :

    • Pour un déploiement dans une seule région :

      • Si vous avez besoin d'un accès à faible latence aux locaux de votre entreprise, déployez l'application dans la région la plus proche de cet emplacement.
      • Si vos utilisateurs proviennent principalement d'un pays ou d'une région spécifique, déployez l'application dans une région proche de celle de vos utilisateurs représentatifs.
      • Pour une base d'utilisateurs mondiale, déployez l'application dans une région des États-Unis.

    • Pour un déploiement multirégional :

      • Choisissez des régions proches de vos utilisateurs en fonction de leur répartition géographique et des exigences de latence de l'application. En fonction de l'application, optimisez le déploiement pour une latence médiane spécifique ou assurez-vous que 95 à 99 % des utilisateurs reçoivent une latence cible spécifique. Les utilisateurs situés à certains emplacements géographiques ont souvent une tolérance plus élevée à la latence en raison des limites de leur infrastructure.

  4. Si la latence des utilisateurs est similaire dans plusieurs régions, la tarification peut constituer le facteur décisif.

Lorsque vous sélectionnez des régions Compute Engine, la latence est l'un des principaux facteurs que vous devez prendre en compte. Évaluez et mesurez les besoins en latence pour offrir une expérience utilisateur de qualité, et répétez le processus si la répartition géographique de votre base d'utilisateurs change.

Étape suivante