Configurations régionales et multirégionales

Cette page décrit les configurations des instances et les deux types de configurations d'instance offerts par Cloud Spanner: les configurations régionales et multirégionales. Elle décrit également les différences et les compromis entre les configurations régionales et multirégionales.

Configurations d'instance

La configuration d'une instance permet de définir l'emplacement géographique et la réplication des bases de données au sein de cette instance. Lorsque vous créez une instance, vous devez décider si elle sera régionale (toutes les ressources seront comprises dans une seule région Google Cloud) ou multirégionale (les ressources s'étaleront sur plusieurs régions). Pour ce faire, sélectionnez une configuration d'instance, qui déterminera l'emplacement de stockage des données de votre instance.

Vous pouvez modifier la configuration de l'instance en suivant les instructions de la page Étapes pour déplacer une instance. Pour obtenir des informations générales sur le déplacement d'une instance, consultez la page Déplacer une instance vers une autre configuration.

Configurations régionales

Les services Google Cloud sont disponibles à différents emplacements en Amérique du Nord, en Amérique du Sud, en Europe, en Asie et en Australie. Si vos utilisateurs et services se trouvent dans la même région, choisissez une configuration d'instance régionale pour assurer une latence faible lors des opérations de lecture et d'écriture.

Configurations disponibles

Cloud Spanner permet les configurations d'instances régionales suivantes :

Nom de la région Description de la région
Amériques
northamerica-northeast1 Montréal
northamerica-northeast2 Toronto
southamerica-east1 São Paulo
us-central1 Iowa
us-east1 Caroline du Sud
us-east4 Virginie du Nord
us-west1 Oregon
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas
Europe
europe-central2 Varsovie
europe-north1 Finlande
europe-west1 Belgique
europe-west2 Londres
europe-west3 Francfort
europe-west4 Pays-Bas
europe-west6 Zurich
Asie-Pacifique
asia-east1 Taïwan
asia-east2 Hong Kong
asia-northeast1 Tokyo
asia-northeast2 Osaka
asia-northeast3 Séoul
asia-south1 Mumbai
asia-south2 Delhi
asia-southeast1 Singapour
asia-southeast2 Jakarta
australia-southeast1 Sydney
australia-southeast2 Melbourne

Pour toute configuration régionale, Cloud Spanner gère trois instances dupliquées en lecture/écriture, chacune étant dans une zone Google Cloud différente dans cette région. Chaque instance dupliquée en lecture/écriture contient une copie complète de votre base de données opérationnelle, capable de diffuser les requêtes en lecture/écriture et en lecture seule. Cloud Spanner utilise des instances dupliquées dans différentes zones, de sorte que votre base de données reste disponible en cas de défaillance d'une zone unique.

Réplication

Les configurations régionales contiennent exactement trois instances dupliquées en lecture/écriture. Comme décrit dans la section Réplication, chaque mutation de Cloud Spanner nécessite un quorum d'écriture composé d'une majorité d'instances dupliquées participant au vote. Les quorums d'écriture se composent de deux des trois instances dupliquées dans la configuration régionale.

Bonnes pratiques

Pour optimiser les performances, suivez les bonnes pratiques suivantes :

  • Concevez un schéma qui évite les hotspots et autres problèmes de performances.
  • Placez les ressources de calcul critiques dans la même région que votre instance Cloud Spanner.
  • Provisionnez suffisamment de capacité de calcul pour maintenir une utilisation totale à haute priorité du processeur inférieure à 65%.

Performances

Lorsque vous suivez les bonnes pratiques décrites ci-dessus, chaque unité de traitement de 1 000 (1 nœud) peut fournir jusqu'à 10 000 requêtes par seconde (RPS) en lecture ou 2 000 RPS écriture (écriture de lignes uniques à 1 Ko de données par ligne).

Configurations multirégionales

Comme décrit ci-dessus, les configurations régionales Cloud Spanner répliquent les données entre plusieurs zones d'une même région. Toutefois, si votre application doit souvent lire des données à partir de plusieurs emplacements géographiques (par exemple, pour diffuser des données à des utilisateurs d'Amérique du Nord et d'Asie) ou si vos opérations d'écriture proviennent d'un emplacement différent de vos opérations de lecture (par exemple, si vous avez des charges de travail d'écriture importantes en Amérique du Nord et des charges de lecture importantes en Europe), il est possible qu'une configuration régionale ne soit pas optimale.

Les configurations multirégionales vous permettent de répliquer les données de la base de données dans plusieurs zones, mais également dans plusieurs zones de plusieurs régions, comme défini par la configuration de l'instance. Avec ces instances dupliquées supplémentaires, vous pouvez lire des données avec une faible latence à partir de plusieurs emplacements proches ou dans les régions de la configuration. Toutefois, il existe des compromis. Dans une configuration multirégionale, les instances dupliquées du quorum (lecture/écriture) sont réparties sur plusieurs régions. Par conséquent, elles peuvent générer une latence du réseau supplémentaire lorsque ces instances dupliquées communiquent entre elles afin de voter pour des écritures. En d'autres termes, les configurations multirégionales permettent à votre application d'effectuer des opérations de lecture plus rapidement et dans plus d'emplacements, au prix d'une légère augmentation de la latence en écriture.

Configurations disponibles

Un continent

Nom Zone Régions de lecture/écriture Régions de lecture seule Région témoin
asia1 Asie Tokyo : asia-northeast1 L,2R
Osaka : asia-northeast2 2R
None Séoul : asia-northeast3
eur3 Europe Belgique : europe-west1 L,2R
Pays-Bas : europe-west4 2R
None Finlande : europe-north1
eur5 Europe Londres : europe-west2 L,2R
Belgique : europe-west1 2R
None Pays-Bas : europe-west4
eur6 Europe Pays-Bas : europe-west4 L,2R
Francfort : europe-west3 2R
Aucun Zurich : europe-west6
nam3 Amérique du Nord Virginie du Nord : us-east4 L,2R
Caroline du Sud : us-east1 2R
None Iowa : us-central1
nam6 Amérique du Nord Iowa : us-central1 L,2R
Caroline du Sud : us-east1 2R
Oregon : us-west1 1R
Los Angeles : us-west2 1R
Oklahoma : us-central2
nam7 Amérique du Nord Iowa : us-central1 L,2R
Virginie du Nord : us-east4 2R
Aucun Oklahoma : us-central2
nam8 Amérique du Nord Los Angeles : us-west2 L,2R
Oregon : us-west1 2R
Aucun Salt Lake City : us-west3
nam9 Amérique du Nord Virginie du Nord : us-east4 L,2R
Iowa : us-central1 2R
Oregon : us-west1 2R Caroline du Sud : us-east1
nam10 Amérique du Nord Iowa : us-central1 L,2R
Salt Lake City : us-west3 2R
None Oklahoma : us-central2
nam11 Amérique du Nord Iowa : us-central1 L,2R
Caroline du Sud : us-east1 2R
None Oklahoma : us-central2
nam12 Amérique du Nord Iowa : us-central1 L,2R
Virginie du Nord : us-east4 2R
Oregon : us-west1 2R Oklahoma : us-central2
  • L : région principale par défaut

  • 1R : une instance dupliquée dans la région

  • 2R : deux instances dupliquées dans la région

Trois continents

Nom Zones Régions de lecture/écriture Régions de lecture seule Région témoin
nam-eur-asia1 Amérique du Nord
Europe
Asie
Iowa : us-central1 L,2R
Oklahoma : us-central2 2R
Belgique : europe-west1 2R
Taïwan : asia-east1 2R
Caroline du Sud : us-east1

Avantages

Les instances multirégionales offrent les principaux avantages suivants :

  • Disponibilité de 99,999 % : supérieure à la disponibilité de 99,99 % fournie par les configurations régionales de Cloud Spanner.

  • Distribution des données : Cloud Spanner réplique automatiquement vos données sur plusieurs régions avec des garanties élevées en matière de cohérence. Cela permet de stocker vos données là où elles sont utilisées, ce qui peut réduire la latence et améliorer l'expérience utilisateur.

  • Cohérence externe : même si Cloud Spanner est répliqué sur des emplacements géographiquement éloignés, vous pouvez toujours l'utiliser comme s'il s'agissait d'une base de données s'exécutant sur un seul ordinateur. Les transactions sont assurées d'être sérialisables et l'ordre des transactions dans la base de données est le même que celui dans lequel les clients consultent les transactions qui ont été validées. La cohérence externe est une garantie plus forte que la "cohérence forte" fournie par d'autres produits. Consultez la section TrueTime et cohérence externe pour en savoir plus sur cette propriété.

Réplication

Chaque configuration multirégionale contient deux régions désignées comme régions de lecture/écriture, chacune contenant deux instances dupliquées en lecture/écriture. L'une de ces régions de lecture/écriture est désignée comme région principale par défaut, ce qui signifie qu'elle contient les instances dupliquées principales de votre base de données. Cloud Spanner place également une instance dupliquée témoin dans une troisième région nommée région témoin.

Lorsqu'un client émet une mutation dans votre base de données, un formulaire de quorum d'écriture est créé. Il se compose de l'une des instances dupliquées issues de la région principale par défaut et de deux des quatre instances dupliquées supplémentaires participant au vote. (Le quorum peut être constitué d'instances dupliquées provenant de deux ou trois des régions composant votre configuration, en fonction des autres instances dupliquées participant au vote.) En plus de ces cinq instances dupliquées participant au vote, la configuration peut également contenir des instances dupliquées en lecture seule permettant de diffuser des opérations de lecture à faible latence. Les régions contenant des instances dupliquées en lecture seule sont nommées régions de lecture seule.

En général, les régions participant au vote dans une configuration multirégionale sont placées dans une zone géographiquement proche (à une distance de moins de 1 600 kilomètres) pour créer un quorum à faible latence qui permet des opérations d'écriture rapides. En savoir plus Toutefois, les régions sont encore suffisamment éloignées les unes des autres (en général, d'au moins quelques centaines de kilomètres) pour éviter les défaillances coordonnées.

Les sections suivantes décrivent plus en détail chacun de ces types de région et expliquent comment placer vos charges de travail d'écriture et de lecture en conséquence.

Types de région

Régions de lecture/écriture

Comme décrit ci-dessus, chaque configuration multirégionale contient deux régions d'opérations de lecture/écriture, chacune comportant deux instances dupliquées en lecture/écriture. L'une de ces régions de lecture/écriture est désignée comme étant la région principale par défaut. Une instance principale est choisie pour chaque division parmi les instances dupliquées de la région principale par défaut. En cas de défaillance de l'instance dupliquée principale, l'autre instance dupliquée de la région principale par défaut prend sa place. En réalité, les instances principales procèdent elles-mêmes à des vérifications d'état et peuvent renoncer de façon préemptive au leadership si elles se rendent compte qu'elles ne sont pas opérationnelles. Dans des conditions normales, lorsque toutes les instances dupliquées de la région principale par défaut sont disponibles, cette région contient les instances dupliquées principales. C'est donc ici que les opérations d'écriture sont traitées en premier.

La deuxième région de lecture/écriture contient les instances dupliquées supplémentaires pouvant être désignées comme principales. Dans l'éventualité peu probable où toutes les instances dupliquées dans la région principale par défaut sont perdues, de nouvelles instances dupliquées principales sont choisies depuis la seconde région de lecture/écriture.

Vous pouvez configurer la région principale d'une base de données en suivant les instructions de la section Modifier la région principale d'une base de données. Pour obtenir des informations générales sur la configuration de la région principale, consultez la section Configurer la région principale par défaut.

Régions de lecture seule

Les régions de lecture seule contiennent des instances dupliquées en lecture seule qui peuvent diffuser des opérations de lecture à faible latence aux clients situés en dehors des régions de lecture/écriture.

Régions témoins

Une région témoin contient une instance dupliquée témoin, qui permet de voter sur des opérations d'écriture. Les témoins sont importants dans l'éventualité peu probable où les régions de lecture/écriture deviennent indisponibles.

Bonnes pratiques

Pour optimiser les performances, suivez les bonnes pratiques suivantes :

  • Concevez un schéma qui évite les hotspots et autres problèmes de performances.
  • Pour une latence optimale en écriture, placez les ressources de calcul allouées aux charges de travail lourdes en écriture dans ou à proximité de la région principale par défaut.
  • Pour des performances en lecture optimales en dehors de la région principale par défaut, utilisez une obsolescence d'au moins 15 secondes.
  • Pour éviter de dépendre d'une seule région pour vos charges de travail, placez les ressources de calcul critiques dans au moins deux régions. Une bonne solution consiste à les placer à côté des deux régions en lecture/écriture différentes afin qu'aucune panne de région n'affecte l'ensemble de votre application.
  • Provisionnez suffisamment de capacité de calcul pour maintenir une utilisation totale à haute priorité du processeur inférieure à 45% dans chaque région.

Performances

Chaque configuration Cloud Spanner présente des caractéristiques de performance légèrement différentes en fonction de la topologie de réplication.

Lorsque vous suivez les bonnes pratiques décrites ci-dessus, chaque unité de traitement de 1 000 unités (1 nœud) de capacité de calcul peut fournir les performances approximatives suivantes:

Configuration multirégionale Pic de lectures approximatif (RPS par région) Pic d'écritures approximatif (RPS total)
asia1 7 000 1 800
eur3 7 000 1 800
eur5 7 000 1 800
eur6 7 000 1 800
nam3 7 000 1 800
nam6 7 000 en us-central1 et us-east1
3 500 dans us-west1 et us-west2 [1]
1 800
nam7 7 000 1 800
nam8 7 000 1 800
nam9 7 000 1 800
nam10 7 000 1 800
nam11 7 000 1 800
nam12 7 000 1 800
nam-eur-asia1 7 000 1 000
  • [1] : us-west1 et us-west2 ne fournissent que la moitié des performances des RPS, car elles contiennent une instance dupliquée par région au lieu de deux.

Notez que les instructions de lecture sont fournies par région (car les opérations de lecture peuvent être diffusées de n'importe où), tandis que les instructions d'écriture s'appliquent à l'ensemble de la configuration. Les instructions d'écriture supposent que vous écriviez des lignes uniques à raison de 1 Ko de données par ligne.

Déplacer une instance vers une autre configuration

Vous pouvez déplacer votre instance depuis n'importe quelle configuration d'instance vers une autre configuration d'instance, y compris entre des configurations régionales et multirégionales.

Le déplacement de l'instance n'entraîne pas de temps d'arrêt et Cloud Spanner continue de fournir les garanties de transaction habituelles en cas de déplacement, y compris une cohérence forte.

Étapes pour déplacer une instance

  1. Accédez à la page Instances Spanner dans Cloud Console.

    Accéder à la page Instances

  2. Cliquez sur le nom de l'instance que vous souhaitez déplacer.

    Cloud Console affiche la page Présentation de l'instance.

  3. Pour planifier le déplacement vers une nouvelle configuration d'instance, cliquez sur Contacter Google et remplissez le formulaire de demande de migration d'instance en direct (aperçu) de Cloud Spanner.

    • Vous devez disposer de l'autorisation spanner.instances.update pour que la requête soit déplacée vers une nouvelle configuration d'instance.
    • Une fois le formulaire envoyé, Google vous contacte pour planifier la modification de la configuration de l'instance.

Limites liées au déplacement d'une instance

  • Vous ne pouvez déplacer qu'une seule instance d'un projet à la fois.
  • Le déplacement d'une instance ne modifie pas son nom, son ID ni son ID de projet.
  • Vous ne devez pas modifier l'instance pendant la migration. Cela inclut la modification du nombre de nœuds d'instance, la modification des schémas de base de données, la création ou la suppression de bases de données, ou la création ou la suppression de sauvegardes.
  • Les sauvegardes Cloud Spanner sont spécifiques à une configuration d'instance et ne sont pas incluses lorsque vous déplacez une instance. Après avoir déplacé une instance dans une nouvelle configuration d'instance, toutes les sauvegardes de l'ancienne configuration d'instance sont supprimées.
  • Actuellement, vous ne pouvez pas modifier la configuration d'une instance contenant des bases de données compatibles avec la fonctionnalité CMEK.

Considérations sur les performances lors du déplacement d'une instance

Lorsqu'une instance est en cours de déplacement, elle subit des latences de lecture/écriture plus élevées et un taux d'annulation de transaction plus élevé.

La plupart des migrations prennent généralement 12 heures. Certaines migrations peuvent prendre plus de temps en fonction de la taille et des autres caractéristiques de l'instance. Google vous communiquera une estimation du temps de migration spécifique à l'instance à migrer.

Toutes les bases de données de l'instance sont migrées simultanément. Étant donné que les applications clientes peuvent effectuer plusieurs appels séquentiels vers Cloud Spanner, l'augmentation de la latence de l'application peut être supérieure à celle de Cloud Spanner.

Après la migration d'une instance, les performances de l'instance varient en fonction des détails de la configuration de l'instance. Par exemple, les configurations multirégionales ont généralement une latence en écriture plus élevée et une latence de lecture plus faible que les configurations régionales.

Configurer la région principale par défaut

Vous pouvez modifier l'emplacement de la région principale par défaut de votre base de données afin de le rapprocher des clients et de réduire la latence des applications.

Vous pouvez modifier la région principale pour toute instance Cloud Spanner utilisant une configuration multirégionale. Pour savoir comment modifier l'emplacement de la région principale, consultez la section Modifier la région principale d'une base de données. Les seules régions susceptibles de devenir les régions principales par défaut de votre base de données sont les régions de lecture/écriture de votre configuration multirégionale.

La région principale est responsable de la gestion de toutes les écritures de base de données. Par conséquent, si la majorité de votre trafic provient d'une région géographique, vous pouvez le déplacer vers cette région afin de réduire la latence. La mise à jour de la région principale par défaut n'est pas coûteuse et n'implique aucun déplacement de données. La prise en compte de la nouvelle valeur prend quelques minutes.

La modification de la région principale par défaut entraîne une modification du schéma qui utilise une opération de longue durée. Si nécessaire, vous pouvez obtenir l'état de l'opération de longue durée.

Compromis : configurations régionales ou multirégionales

Configuration Disponibilité Latence Coût Localité des données
Régionale 99,99 % Réduit les latences d'écriture dans la région. Coûts réduits ; consultez les tarifs. Active la gouvernance des données géographiques.
Multirégionale 99,999 % Réduit les latences de lecture de plusieurs régions géographiques. Coûts plus élevés ; consultez les tarifs. Distribue les données sur plusieurs régions de la configuration.

Étape suivante