Zones géographiques et régions

Les produits Google Cloud sont diffusés à partir de domaines de défaillance régionaux spécifiques et sont entièrement couverts par les contrats de niveau de service afin de vous assurer que vous concevez votre architecture d'application au sein de la structure de Google Cloud.

Les services d'infrastructure Google Cloud sont disponibles à différents emplacements en Amérique du Nord, en Amérique du Sud, en Asie, en Australie, en Europe et au Moyen-Orient. Ces emplacements sont organisés en régions et en zones. Vous pouvez choisir l'emplacement souhaité pour vos applications en fonction de vos critères de latence, de disponibilité et de durabilité.

Régions et zones

Les régions correspondent à des espaces géographiques indépendants qui sont constitués de zones. Les zones et les régions sont des abstractions logiques des ressources physiques sous-jacentes fournies dans un ou plusieurs centres de données physiques. Ces centres de données peuvent appartenir à Google et être répertoriés sur la page Emplacements Google Cloud. Vous pouvez également les louer à des fournisseurs tiers de centres de données. Pour obtenir la liste complète des emplacements des centres de données Google Cloud, consultez notre certificat ISO/IEC 27001. Que le centre de données soit acheté ou loué, Google Cloud sélectionne les centres de données et conçoit son infrastructure pour offrir un niveau uniforme de performances, de sécurité et de fiabilité.

Les zones servent au déploiement des ressources Google Cloud dans une région. Elles doivent être considérées comme un domaine de défaillance unique au sein d'une région. Pour déployer des applications tolérantes aux pannes et à haute disponibilité, et être mieux protégé contre les défaillances inattendues, déployez vos applications sur plusieurs zones d'une région.

Pour empêcher la perte d'une région entière à la suite d'une catastrophe naturelle, vous devez disposer d'un plan de reprise après sinistre et savoir comment remettre en service votre application dans le cas peu probable de la perte de votre région principale. Pour en savoir plus, consultez la section Remarques relatives au déploiement d'applications.

Pour plus d'informations sur les ressources spécifiques qui sont disponibles dans chaque option d'emplacement, consultez la page Emplacements Cloud.

Les services et ressources Google Cloud peuvent être zonaux, régionaux, ou gérés par Google dans plusieurs régions. Pour en savoir plus sur l'incidence que ces options peuvent avoir sur vos données, consultez la section Gestion géographique des données.

Google Cloud compte proposer au moins trois zones de disponibilité (zones physiques et logiquement distinctes) dans chaque région à usage général.

Ressources zonales

Les ressources zonales sont disponibles dans une seule zone. Les interruptions zonales peuvent affecter une partie ou l'ensemble des ressources de cette zone. Une instance de machine virtuelle (VM) Compute Engine résidant dans une zone spécifique est un exemple de ressource zonale.

Ressources régionales

Les ressources régionales sont déployées de façon redondante dans plusieurs zones d'une région. Il peut s'agir par exemple d'applications App Engine ou de groupes d'instances gérés régionaux. Elles offrent ainsi une disponibilité plus élevée que les ressources zonales.

Ressources multirégionales

Plusieurs services Google Cloud sont gérés par Google pour être redondants et distribués dans et entre les régions. Ils contribuent à optimiser la disponibilité, les performances et l'efficacité des ressources. Par conséquent, ces services requièrent des compromis entre la latence et le modèle de cohérence. Ces compromis sont documentés en fonction de chaque produit.

Les services suivants sont associés à un ou plusieurs emplacements multirégionaux, en plus des emplacements régionaux :

Artifact Registry
Bigtable
Protection des données sensibles
API Cloud Healthcare
Cloud KMS
Container Registry
Spanner
Cloud Storage
Database Migration Service
Datastore
Firestore

Ces services multirégionaux sont conçus pour fonctionner à la suite de la perte d'une seule région.

Pour en savoir plus, consultez la section Produits disponibles par emplacement ainsi que la documentation de chaque produit.

Services internationaux

Google Cloud a été entièrement conçu pour fonctionner dans le monde entier. Il effectue constamment des opérations de maintenance et des mises à niveau 24h/24, 7j/7 et 365 jours par an sans vous déranger. Notre réseau backbone mondial offre une flexibilité exceptionnelle en termes d'équilibrage de charge, et réduit la latence des utilisateurs finaux en établissant des interconnexions plus proches de vous. Notre plan global de gestion cloud simplifie la gestion des développements multirégionaux.

Services internes

L'intégration et la compatibilité de nombreux services Google Cloud destinés aux clients constituent un ensemble de services internes éprouvés tels que Spanner, Colossus, Borg et Chubby.

Ces services internes sont soit équilibrés en charge dans plusieurs régions, soit dédiés à chaque région dans laquelle ils sont disponibles. Lorsque les services sont équilibrés en charge dans plusieurs régions, nous déployons les mises à jour progressivement d'une région à l'autre, ce qui nous permet de détecter et de résoudre les problèmes sans affecter l'utilisation de votre service. Aucun de ces services internes n'est limité à un seul centre de données logique ou à une seule région.

Les services internes globaux peuvent s'exécuter ou être répliqués dans les régions cloud suivantes :

Amériques

southamerica-west1
us-central1
us-east1
us-east4
us-west1
us-west4

Europe

europe-north1
europe-west1
europe-west4

Asie

asia-east1
asia-southeast1

Dépendances de services

En général, pour les services Google Cloud, si une région tombe en panne, seuls les clients de cette région sont affectés. Les clients disposant de produits multirégionaux ne sont pas affectés. Google Cloud dispose d'une architecture conséquente dans le but d'éviter les pannes corrélées entre les régions.

Tous les services Google Cloud s'appuient sur des outils internes essentiels permettant de fournir des services fondamentaux tels que la mise en réseau (entrée et sortie des centres de données), l'accès aux centres de données et les systèmes d'autorisation d'identité. Ces outils sont résilients aux pannes régionales, l'objectif étant qu'une région ne soit pas touchée si d'autres régions sont indisponibles.

Google Cloud fournit des instructions claires sur la façon dont les clients peuvent concevoir leurs applications pour le niveau de résilience souhaité sur notre site Web public, en particulier pour les produits Google Cloud couramment utilisés tels que Compute Engine, BigQuery, Pub/Sub et d'autres services.

Nos principales dépendances sont répertoriées ci-dessous, en commençant par celles qui sont communes à tous les services. Notez que les détails de mise en œuvre de niveau inférieur sont susceptibles d'être modifiés.

Dépendances communes à tous les services

Plan de données d'identité pour l'authentification et l'autorisation
Services internes de journalisation, de stockage de métadonnées et de gestion des workflows
L'accès aux API Google Cloud dépend du DNS, des équilibreurs de charge distribués à l'échelle mondiale et des points de présence.
Configuration des ressources globales : par exemple, les stratégies IAM, les règles de pare-feu globales, les configurations globales d'équilibreur de charge et les sujets Pub/Sub sont stockés dans des bases de données répliquées.
Lorsque les services Google Cloud envoient des requêtes à des points de terminaison contrôlés par le client (par exemple, en récupérant les clés client Cloud EKM ou via Pub/Sub en diffusant des messages), ces requêtes dépendent de notre infrastructure réseau mondiale pour accéder à ces points de terminaison contrôlés par le client.

Services avec des dépendances supplémentaires

Services Compute Engine
- Les plans de données de la VM et du disque persistant Google Cloud dépendent de services Compute Engine et Cloud Storage de niveau inférieur tels que Borg et Colossus.
Les services de stockage de Google Cloud et d'infrastructure tels que Spanner, Bigtable et Cloud Storage dépendent des éléments suivants :
- Chiffrement et infrastructure de gestion des clés pour le client (Cloud KMS / Cloud EKM) et infrastructure interne pour les clés appartenant à Google
- Services internes de journalisation et d'audit de l'accès aux données
- Services de réplication de données internes, dans les cas où les données sont censées être disponibles dans plusieurs régions
- Les sauvegardes configurées explicitement et la réplication des autres régions dépendent du réseau interrégional
Services de messagerie
- Pub/Sub dépend de notre infrastructure réseau mondiale pour accéder aux points de terminaison contrôlés par le client
Services de mise en réseau
- L'équilibrage de charge au niveau mondial, le DNS et le basculement entre les régions dépendent tous d'une infrastructure de mise en réseau physique.
- La prévention des attaques DDos, et d'autres attaques similaires, dépend d'une infrastructure Compute Engine de niveau inférieur.
Services gérés et hébergés tels que GKE et Cloud SQL
- Dépendent de Compute Engine et de Container Registry ou Artifact Registry pour les images de VM.
Infrastructure de niveau inférieur autonome
- Notre plan de contrôle interne au niveau du cluster, notamment Borg et les structures réseau
- Stockage au niveau du cluster, tel que Colossus
- Infrastructure de chiffrement et de gestion des clés

Gérer et améliorer la disponibilité et la résilience

L'ingénierie en fiabilité des sites (SRE) constitue l'organisation interne de Google dédiée à la disponibilité, à la latence, aux performances et à la capacité. Les pannes et l'indisponibilité d'un service sont corrélées au déploiement d'un nouveau code ou aux modifications apportées à l'environnement. En appliquant les bonnes pratiques du secteur, l'ingénierie SRE assure un juste équilibre entre la nécessité de publier de nouveaux logiciels et la sécurité de l'environnement en ayant conscience que ces modifications nécessaires peuvent provoquer un temps d'arrêt.

Collaborer avec les clients pour créer des services résilients

Si vous avez des besoins critiques en ce qui concerne l'architecture pour la résilience et la reprise après sinistre, nos équipes SRE/CRE et PSO peuvent vous aider à concevoir vos applications pour qu'elles relient plusieurs régions et zones, et à concevoir des systèmes à haute disponibilité.

Si vous avez des exigences de disponibilité plus importantes à des dates spécifiques (par exemple, au moment du Black Friday ou du Cyber Monday), Google Cloud dispose d'un programme qui vous aide à examiner et à valider votre application spécifique exécutée sur Google Cloud, et à identifier toutes les dépendances de services entre votre application et nos services.

Points de présence (POP)

Google gère un réseau mondial de points de présence d'appairage, ce qui signifie que le trafic client peut transiter au sein du réseau Google jusqu'à ce qu'il soit proche de sa destination, offrant ainsi aux utilisateurs une expérience améliorée et une meilleure sécurité. Pour en savoir plus, consultez la page Emplacements en périphérie du réseau.

Gestion géographique des données

Pour les services Google Cloud, la localité des données est régie par les Conditions d'utilisation, y compris les Conditions spécifiques du service. Nous sommes conscients que chaque client est susceptible d'avoir des exigences spécifiques en termes de sécurité et de conformité. L'équipe commerciale de Google Cloud peut vous aider à répondre à vos besoins.

Lorsque vous utilisez des ressources de stockage régionales ou zonales, nous vous recommandons vivement de répliquer les données dans une autre région ou de créer un instantané de ces données dans une ressource de stockage multirégionale en vue d'une reprise après sinistre.

Remarques relatives au déploiement d'applications

Création de services et d'applications à disponibilité élevée pouvant supporter des défaillances de zones

Utilisez les ressources suivantes :

Des ressources régionales, telles que les applications App Engine, des groupes d'instances gérés régionaux ou des ressources multirégionales gérées, telles que Cloud Storage, Datastore, Firestore ou Spanner.
Des ressources zonales, telles que les VM Compute Engine, mais vous devez gérer vous-même la redondance des ressources de calcul et de stockage dans les différentes zones ou régions.

Création d'applications pouvant faire l'objet d'une reprise après sinistre et capables de supporter la perte prolongée de régions entières

Pour les données, adoptez une ou plusieurs des stratégies suivantes :

Utilisez des services de stockage multirégionaux gérés, tels que Cloud Storage, Datastore, Firestore ou Spanner.
Utilisez des ressources zonales ou régionales, mais créez un instantané des données dans une ressource multirégionale, telle que Cloud Storage, Datastore, Firestore ou Spanner.
Utilisez des ressources zonales ou régionales, mais gérez votre propre processus de réplication des données dans une ou plusieurs autres régions.

Pour les ressources de calcul, adoptez la stratégie suivante :

Utilisez des ressources zonales ou régionales, telles que Compute Engine ou App Engine, mais remettez en service, de façon manuelle ou automatique, votre application dans une autre région (en cas de défaillance régionale) à partir de copies des données principales si celles-ci ne se trouvent pas déjà dans une ressource multirégionale gérée.

Pour plus d'informations sur les dépendances de service, contactez le service commercial.

Autres solutions et tutoriels

Les solutions et tutoriels ci-dessous vous aident à garantir la haute disponibilité de votre application et à supporter les interruptions de service.

Modèles d'applications évolutives et résilientes

Apprenez à utiliser Google Cloud afin de créer des architectures d'applications évolutives et résilientes à l'aide de modèles et de bonnes pratiques largement applicables à toute application Web.

Créer un équilibreur de charge HTTPS

Configurez des instances Compute Engine dans différentes régions et utilisez l'équilibrage de charge HTTP pour distribuer le trafic entre ces dernières. Vous pouvez ainsi améliorer la disponibilité dans les différentes régions et permettre le basculement en cas d'interruption de service.