Cette section du guide des archétypes de déploiement Google Cloud décrit l'archétype de déploiement régional.
Dans une architecture cloud qui utilise l'archétype de déploiement régional, les instances de l'application s'exécutent dans au moins deux zones d'une même région Google Cloud. Toutes les instances d'application utilisent un dépôt partagé de fichiers de configuration géré de manière centralisée. Les données de l'application sont répliquées de manière synchrone dans toutes les zones de l'architecture.
Le schéma suivant illustre la topologie cloud pour une application haute disponibilité qui s'exécute indépendamment dans trois zones d'une même région Google Cloud :
Le schéma précédent montre une application avec des composants frontend et backend qui s'exécutent indépendamment dans trois zones d'une région Google Cloud. Un équilibreur de charge externe transfère les requêtes des utilisateurs vers l'un des frontends. Un équilibreur de charge interne transfère le trafic des interfaces vers les backends. L'application utilise une base de données répliquée dans toutes les zones. En cas de panne zonale, la base de données bascule vers une instance répliquée d'une autre zone.
La topologie du schéma précédent est robuste face aux pannes zonales, mais pas face aux pannes régionales. Pour pouvoir vous remettre des pannes régionales, vous devez avoir déployé une instance répliquée passive de l'application dans une deuxième région (de basculement), comme illustré dans le schéma suivant :
Lorsqu'une panne se produit dans la région principale, vous devez promouvoir la base de données dans la région de basculement et laisser les règles de routage DNS acheminer le trafic vers l'équilibreur de charge dans la région de basculement.
Pour optimiser le coût de l'infrastructure de basculement, vous pouvez exploiter la région de basculement à une capacité inférieure en déployant moins de ressources.
Cas d'utilisation
Les sections suivantes fournissent des exemples de cas d'utilisation pour lesquels l'archétype de déploiement régional constitue un choix approprié.
Application haute disponibilité avec des utilisateurs dans une zone géographique
Nous recommandons l'archétype de déploiement régional pour les applications qui doivent être robustes face aux pannes zonales, mais pouvant tolérer des temps d'arrêt causés par les pannes régionales. Si une partie de la pile d'applications échoue, l'application continue de s'exécuter si au moins un composant fonctionnel disposant d'une capacité suffisante existe à chaque niveau. Si une panne zonale se produit, la pile d'applications continue de s'exécuter dans les autres zones.
Faible latence pour les utilisateurs de l'application
Si les utilisateurs d'une application se trouvent dans une zone géographique telle qu'un seul pays, l'archétype de déploiement régional peut contribuer à améliorer les performances perçues par les utilisateurs. Vous pouvez optimiser la latence réseau pour les requêtes des utilisateurs en déployant l'application dans la région Google Cloud la plus proche de vos utilisateurs.
Mise en réseau à faible latence entre les composants d'application.
Une architecture à région unique peut être adaptée aux applications telles que le calcul par lot qui nécessitent des connexions réseau à faible latence et à bande passante élevée entre les nœuds de calcul. Toutes les ressources se trouvent dans une seule région Google Cloud. Par conséquent, le trafic réseau inter-ressources est conservé dans la région. La latence réseau inter-ressource est faible, et vous n'encourez pas de coûts de transfert de données interrégionaux. Les coûts réseau intrarégionaux continuent de s'appliquer.
Respect des exigences de résidence et de souveraineté des données
L'archétype de déploiement régional peut vous aider à répondre aux exigences réglementaires en matière de résidence des données et de souveraineté opérationnelle. Par exemple, un pays situé en Europe peut exiger que toutes les données utilisateur soient stockées et consultées dans des centres de données situés physiquement dans ce pays. Pour répondre à cette exigence, vous pouvez déployer l'application dans une région Google Cloud en Europe.
Considérations de conception
Lorsque vous créez une architecture basée sur l'archétype de déploiement régional, tenez compte des facteurs de conception suivants.
Temps d'arrêt en cas de panne régionale
En cas d'indisponibilité d'une région, l'application est indisponible. Vous pouvez réduire les temps d'arrêt causés par les pannes régionales en conservant une instance répliquée passive (de basculement) de la pile d'infrastructure dans une autre région Google Cloud. Si une panne se produit dans la région principale, vous pouvez activer la pile dans la région de basculement et utiliser des règles de routage DNS pour acheminer le trafic vers l'équilibreur de charge dans la région de basculement.
Coût des ressources redondantes
Une architecture multizone comporte généralement plus de ressources cloud qu'un déploiement à zone unique. Tenez compte du coût de ces ressources cloud lorsque vous créez votre architecture. Pour les applications nécessitant une robustesse face aux pannes zonales, l'avantage en termes de disponibilité d'une architecture multizone peut justifier le coût plus élevé.
Architecture de référence
Pour obtenir une architecture de référence permettant de concevoir un déploiement régional sur des VM Compute Engine, consultez la page Déploiement régional sur Compute Engine.