Choisir l'architecture adaptée pour la distribution de données à l'échelle mondiale

Cette solution décrit trois exemples d'architectures permettant la distribution de données entre les régions Google Cloud.

De nombreuses entreprises exploitent des données réparties dans différentes zones géographiques, tout en répondant aux requêtes des clients quasiment en temps réel. Par exemple, une plate-forme côté demande (DSP) pour la publicité numérique peut compter des clients qui s'attendent à des délais de réponse de la base de données inférieurs à 20 millisecondes, indépendamment de leur zone géographique ou de la charge réseau actuelle. L'implémentation de ce type de solution DSP à l'échelle mondiale est impossible si l'architecture réseau dépend d'une base de données centralisée unique, vulnérable aux latences causées par la distance physique et également très affectée par les pics d'utilisation.

Vous pouvez répondre à ces besoins à l'aide d'une architecture distribuée pour le stockage de données. Toutes les architectures ne conviennent pas aux besoins de toutes les entreprises, et chaque architecture présente ses propres forces et faiblesses. Cette solution propose donc diverses alternatives Google Cloud pour vous aider à mettre en œuvre votre stratégie d'entreprise globale et guider votre approche réseau.

Avantages de Google Cloud

Google Cloud fournit une bande passante réseau robuste et stable dans le monde entier. Google Cloud présente également de nombreux autres avantages :

Google Cloud est extrêmement flexible. Vous pouvez l'utiliser pour créer un réseau virtuel mondial, permettant à vos applications de communiquer de manière plus sécurisée entre les régions à l'aide d'adresses IP privées. Par exemple, vous pouvez configurer des instances de machine virtuelle (VM) Compute Engine dans deux régions, telles que us-central1 et asia-east1. Vous pouvez faire en sorte que ces instances de VM utilisent des adresses IP privées pour communiquer directement entre elles en créant un réseau cloud privé virtuel. De cette manière, votre organisation peut contribuer à maintenir des communications sécurisées entre les instances.

Avec une adresse IP Anycast Google Cloud, une seule adresse IP globale est attribuée à un service géré, tel que l'équilibrage de la charge. L'adresse IP Anycast vous permet de créer un seul équilibreur de charge global plutôt que de configurer des équilibreurs de charge pour chaque région. L'équilibreur global achemine les requêtes des clients vers des applications s'exécutant dans les régions les plus proches et s'adapte automatiquement en fonction de la demande.

Trois exemples d'architecture de distribution de données

Cette section décrit trois architectures de déploiement et explique les cas d'utilisation dans lesquels elles s'appliquent. Les architectures et les cas d'utilisation sont les suivants :

  • Déploiement hybride, composé de Google Cloud et de services sur site : vous souhaitez conserver certains services sur site et exploiter les fonctionnalités de Google Cloud. Google Cloud est associé à votre réseau actuel et intégré aux processus actuels de votre entreprise. Tout ou partie des données sur site sont copiées dans Google Cloud ou intégrées à Google Cloud.

  • Déploiement hybride, constitué de Google Cloud et d'autres plates-formes de services cloud : vous souhaitez conserver les opérations actuelles de votre fournisseur de services cloud, mais également inclure certaines fonctionnalités Google Cloud et configurer les deux systèmes pour qu'ils puissent communiquer.

  • Google Cloud utilisant plusieurs régions : vous souhaitez accepter les transferts de données quasi synchrones, éventuellement à l'échelle mondiale. La configuration de Google Cloud dans plusieurs régions permet un transfert de données extrêmement rapide et quasi simultané à travers le monde.

Déploiement hybride : Google Cloud et services sur site

La combinaison de Google Cloud avec des services sur site convient aux cas d'utilisation impliquant des applications qui stockent des données sur site et qui propagent également des données vers Google Cloud.

Par exemple, dans le secteur du commerce, des données principales (parfois appelées données de référence) concernant les nouveaux produits peuvent être insérées dans des bases de données sur site pour un ancien système de gestion de l'inventaire. L'entreprise peut également avoir besoin de propager ces données vers une base de données Google Cloud utilisée pour les boutiques en ligne. À l'aide d'une approche hybride, vous pouvez créer un système utilisant Google Cloud sans affecter le système sur site existant. Dans cette architecture, Google Cloud fonctionne essentiellement en parallèle des structures réseau sur site.

Si vous décidez de mettre en œuvre un déploiement hybride Google Cloud/sur site, vous devez prendre en compte les problématiques suivantes :

  • Si les données se trouvent à la fois sur site et dans Google Cloud, vous devez choisir celles à traiter en tant que données primaires, ainsi que leur emplacement. Par exemple, vous pouvez définir les données Google Cloud en tant que données principales. Dans ce cas, Google Cloud se comporte comme un concentrateur de données connectant un ou plusieurs environnements sur site qui échangent des données entre eux. Une fois les données ajoutées ou mises à jour dans l'environnement Google Cloud, elles sont transmises aux systèmes sur site. Sinon, vous pouvez décider que les systèmes sur site contiendront les données principales et répercuteront régulièrement les changements dans Google Cloud.
  • Si vous développez une application pour cet environnement hybride, n'oubliez pas que les services gérés ne sont disponibles que pour les ressources Google Cloud. Les applications exécutées à la fois sur site et dans l'environnement Google Cloud risquent de ne pas pouvoir compter sur des services gérés tels que la sauvegarde automatique, la redondance et le scaling.
  • Pour continuer à assurer la portabilité des données et la cohérence des opérations administratives, il peut être plus simple d'héberger des datastores multiplates-formes, tels que MySQL, sur des machines virtuelles à la fois dans votre déploiement sur site et dans Google Cloud.

Exemple d'architecture hybride

Le schéma suivant illustre un exemple d'architecture hybride avec Google Cloud et des systèmes sur site.

Architecture d'un système hybride.

Dans l'exemple d'architecture :

  • Les données sont échangées entre les serveurs de fichiers sur site et Cloud Storage. Cette opération peut impliquer la sauvegarde de fichiers locaux dans Google Cloud, le traitement par lot de fichiers en tant qu'entrée ou le téléchargement de fichiers depuis Google Cloud vers des réseaux sur site.
  • Les applications personnalisées dans les centres de données locaux utilisent les API REST pour accéder aux applications sur App Engine afin de récupérer ou d'envoyer des données. Les requêtes REST sont généralement synchrones et bloquent les clients jusqu'à ce que les résultats soient renvoyés. Dans cette architecture, App Engine fournit l'autoscaling pour augmenter la capacité en fonction des requêtes, ce qui permet de maintenir une latence faible pour ces appels synchrones.
  • Les applications personnalisées envoient des messages directement à Pub/Sub pour les stocker dans une file d'attente répliquée en vue d'un traitement ultérieur. Après avoir reçu les messages, Pub/Sub renvoie immédiatement l'état et ne bloque pas les clients. Les messages peuvent être récupérés et traités de manière asynchrone à l'aide de Cloud Functions, Dataflow, d'applications s'exécutant sur Compute Engine et d'autres méthodes. Les applications clientes dans des environnements sur site peuvent également récupérer des messages.
  • Les données stockées dans des bases de données sur site sont exportées (éventuellement sous forme de fichiers CSV) et importées dans Google Cloud pour le chargement par lot dans des bases de données gérées par Cloud SQL.
  • La synchronisation des données entre les systèmes sur site et Google Cloud s'effectue à l'aide d'une base de données Firebase. Les applications reçoivent les notifications associées aux clés de la base de données. Ainsi, dès que des valeurs sont mises à jour, les applications en sont informées en temps réel et les reçoivent sous leur forme la plus récente. Les applications qui interagissent avec Firebase peuvent se trouver sur site, sur Google Cloud ou les deux.

Déploiement hybride : Google Cloud et autres fournisseurs cloud

Vous pouvez associer Google Cloud à d'autres fournisseurs cloud pour distribuer vos données plus efficacement et exploiter plusieurs mécanismes de prévention de défaillance ou des fonctionnalités spécifiques à Google Cloud. Cette architecture est un bon choix lorsque des services de production sont déjà en cours d'exécution sur d'autres fournisseurs cloud, mais que vous souhaitez exploiter des fonctionnalités Google Cloud. Par exemple, vous pouvez utiliser BigQuery pour analyser les données d'application, ainsi que les journaux et les métriques de surveillance.

Cette architecture est semblable à l'architecture hybride sur site et Google Cloud décrite plus haut. Lors de la mise en œuvre d'un déploiement hybride Google Cloud/autres fournisseurs cloud, vous devez prendre en compte les problématiques suivantes :

  • Vous pouvez utiliser des bibliothèques clientes multicloud Open Source telles que jclouds et libcloud pour faciliter l'intégration d'API entre Google Cloud et d'autres services cloud.
  • Google Cloud propose des solutions de transfert de données à partir d'Amazon Web Services (AWS), telles que le service de transfert de stockage, ainsi que Cloud Monitoring et Cloud Logging. Vous pouvez exporter les journaux vers BigQuery afin de procéder à une analyse plus approfondie.
  • Pub/Sub est un service global. Vos applications n'ont pas besoin de savoir dans quelle région se trouvent les files d'attente Pub/Sub. Vous pouvez publier des messages ou vous abonner à des sujets disponibles dans le monde entier. Avec Google Cloud, les applications clientes doivent prendre en compte un seul ensemble d'adresses IP et de ports. Pour d'autres fournisseurs cloud, les files d'attente peuvent être spécifiques à une région. Si tel est le cas, lorsque vous déployez des applications dans plusieurs régions, les applications clientes doivent prendre en compte les points de terminaison de chaque région. Le suivi des points de terminaison peut se révéler fastidieux, en particulier si vous ajoutez des services issus de nouvelles régions.

Exemple d'architecture pour Google Cloud associé à un autre fournisseur cloud

Le schéma suivant illustre une architecture hybride intégrant GCP et d'autres fournisseurs cloud.

Architecture d'un système intégrant Google Cloud et un autre fournisseur cloud.

Dans l'exemple d'architecture :

  • Les messages sont échangés entre Pub/Sub et d'autres clouds publics. Pub/Sub fournit un point de terminaison global et peut servir de concentrateur de messages entre les différents clouds, car les applications n'ont pas besoin de savoir dans quelle région se trouvent les files d'attente de messages.
  • Des instances de l'agent Cloud Monitoring sont installées sur des machines virtuelles d'autres clouds publics afin de collecter des métriques concernant l'utilisation du processeur et de la mémoire, les informations de traitement, etc. Cloud Monitoring surveille l'utilisation des ressources dans les environnements cloud hybrides.
  • Les applications personnalisées qui s'exécutent sur des machines virtuelles dans d'autres environnements cloud utilisent les API REST pour appeler des applications hébergées sur App Engine afin d'envoyer ou de récupérer des données.
  • Le service de transfert de stockage permet de transférer directement des fichiers depuis Amazon S3, à la demande ou de façon régulière. Les fichiers transférés peuvent être traités sur Compute Engine afin de les charger dans Cloud SQL.

Déploiement hybride : Google Cloud multirégional

Une architecture basée sur Google Cloud dans plusieurs régions est adaptée lorsque votre application doit desservir les utilisateurs dans le monde entier et synchroniser les données entre les régions avec un temps de latence minimal. Par exemple, un jeu vidéo connecté à Internet doit fonctionner dans le monde entier en proposant une synchronisation en temps quasi réel entre les joueurs.

Cette architecture exploite la puissance des services gérés par Google Cloud pour réduire les tâches administratives et simplifier la conception du système. Google Cloud vous permet de vous concentrer sur vos applications sans perdre de temps avec la conception de l'infrastructure. Vous devez prendre en compte les problématiques suivantes lors de la mise en œuvre d'un déploiement hybride Google Cloud avec plusieurs régions :

  • Vous pouvez facilement déployer des services de traitement de données multirégionales, car les éditeurs de messages et les services d'abonnement peuvent s'exécuter dans n'importe quelle région. Pub/Sub peut échanger des messages entre les applications qui s'exécutent dans différentes régions sans que vous ayez besoin de spécifier leur emplacement d'exécution. Dans cette architecture, les messages Pub/Sub restent dans Google Cloud et ne sont pas envoyés sur Internet, ce qui permet de réduire le temps de latence.
  • Les applications sur des instances Compute Engine peuvent communiquer directement entre les régions à l'aide d'adresses IP privées au sein d'un réseau VPC Google Cloud.
  • Vous pouvez créer des applications personnalisées faiblement couplées à l'aide des API REST. Comme l'architecture est entièrement intégrée à l'environnement Google Cloud, vous pouvez utiliser App Engine pour gérer des applications dont vous attendez un minimum de tâches administratives.
  • Après avoir réparti les données entre les régions, vous pouvez utiliser Dataflow ou Dataproc pour traiter des charges de travail ETL ou analytiques.

Exemple d'architecture Google Cloud multirégionale

Le schéma suivant illustre l'architecture d'un déploiement Google Cloud multirégional.

Architecture d'un système impliquant plusieurs régions Google Cloud.

Dans l'exemple d'architecture :

  • Comme pour l'architecture cloud hybride, Cloud Monitoring surveille toutes les ressources de calcul et affiche une vue consolidée de leur utilisation à l'échelle mondiale. Les journaux et les métriques collectés sont exportés vers BigQuery afin de procéder à une analyse plus approfondie.
  • Comme pour l'architecture cloud hybride, Pub/Sub sert de concentrateur de messages. Pub/Sub permet aux services d'être faiblement couplés et indépendants de l'emplacement d'exécution de l'application.
  • Les applications personnalisées qui s'exécutent sur App Engine ou Compute Engine échangent directement des messages avec d'autres applications personnalisées à l'aide des API REST. Il s'agit d'une architecture plus étroitement couplée que l'architecture hybride, ce qui permet de rendre la latence plus prévisible.
  • Le service de transfert de stockage permet de synchroniser les buckets Cloud Storage. Vous pouvez également utiliser l'outil gsutil pour les transferts à la demande entre les buckets de plusieurs régions.

Étapes suivantes

Pour en savoir plus sur la gestion des données sur Google Cloud, accédez aux liens suivants :