Gestion de bases de données multi-cloud : architectures, cas d'utilisation et bonnes pratiques

Last reviewed 2024-03-06 UTC

Ce document décrit les architectures de déploiement, les cas d'utilisation et les bonnes pratiques de gestion des bases de données multicloud. Il est destiné aux architectes et aux ingénieurs qui conçoivent et mettent en œuvre des applications avec état dans et entre plusieurs clouds.

Les architectures d'applications multicloud qui accèdent aux bases de données dépendent du cas d'utilisation. Aucune architecture d'applications avec état unique ne peut être compatible avec tous les cas d'utilisation multicloud. Par exemple, la meilleure solution de base de données pour un cas d'utilisation temporaire du cloud est différente de la meilleure solution de base de données pour une application qui s'exécute simultanément dans plusieurs environnements cloud.

Pour les clouds publics tels que Google Cloud, il existe différentes technologies de base de données qui répondent à des cas d'utilisation multicloud spécifiques. Pour déployer une application dans plusieurs régions au sein d'un même cloud public, vous pouvez utiliser une base de données multirégionale, cloud public, gérée par le fournisseur, telle que Spanner. Pour déployer une application de sorte qu'elle soit portable sur les clouds publics, une base de données indépendante de la plate-forme peut être un meilleur choix, tel que PostgreSQL.

Ce document présente la définition d'une application de base de données avec état, suivie d'une analyse de cas d'utilisation de bases de données multicloud. Il présente ensuite une classification détaillée du système de base de données pour les architectures de déploiement multicloud basées sur les cas d'utilisation.

Il présente également un arbre de décision pour la sélection des bases de données qui décrit les principaux points de décision pour choisir une technologie de base de données appropriée. Enfin, nous abordons les bonnes pratiques de gestion des bases de données multicloud.

Termes clés et définitions

Cette section fournit une terminologie et définit l'application générique de base de données avec état utilisée dans ce document.

Terminologie

• cloud public Un cloud public fournit une infrastructure mutualisée (généralement mondiale) et des services que les clients peuvent utiliser pour exécuter leurs charges de travail de production. Google Cloud est un cloud public qui fournit de nombreux services gérés, parmi lesquels GKE, GKE Enterprise et les bases de données gérées.
• Cloud hybride Un cloud hybride est une combinaison d'un cloud public avec un ou plusieurs centres de données sur site. Les clients de cloud hybride peuvent combiner leurs services sur site avec des services supplémentaires fournis par un cloud public.
• Multicloud Un multicloud est une combinaison de plusieurs clouds publics et de centres de données sur site. Un cloud hybride est un sous-ensemble du multicloud.
• Emplacement du déploiement Un emplacement d'infrastructure est un emplacement physique pouvant déployer et exécuter des charges de travail, y compris des applications et des bases de données. Par exemple, dans Google Cloud, les emplacements de déploiement sont des zones et des régions. Au niveau abstrait, une région ou une zone cloud publique et un centre de données sur site sont des emplacements de déploiement.

Applications de base de données avec état

Pour définir des cas d'utilisation multicloud, une architecture d'application de base de données générique avec état est utilisée dans ce document, comme illustré dans le schéma suivant.

Le schéma montre les composants suivants :

• base de données Une base de données peut être une instance unique, multi-instance ou une base de données distribuée, déployée sur des nœuds de calcul ou disponible en tant que service géré dans le cloud.
• Services applicatifs Ces services sont combinés en tant qu'application qui met en œuvre la logique métier. Les services d'application peuvent être l'un des suivants :
  • Microservices sur Kubernetes.
  • Processus approximatifs exécutés sur une ou plusieurs machines virtuelles
  • Application monolithique sur une grande machine virtuelle.
  • Code sans serveur dans Cloud Functions ou Cloud Run. Certains services applicatifs peuvent accéder à la base de données. Il est possible de déployer chaque service d'application plusieurs fois. Chaque déploiement d'un service d'application est une instance de ce service.
• Clients d'application. Les clients d'application accèdent aux fonctionnalités fournies par les services d'application. Les clients d'application peuvent être l'un des suivants :
  • Clients déployés, où le code s'exécute sur une machine, un ordinateur portable ou un téléphone mobile.
  • Clients non déployés, où le code client s'exécute dans un navigateur. Les instances de client d'application accèdent toujours à une ou plusieurs instances de service d'application.

Dans le contexte d'une discussion sur les bases de données multicloud, l'abstraction architecturale d'une application avec état se compose d'une base de données, de services d'application et de clients d'application. Dans l'implémentation d'une application, des facteurs tels que l'utilisation des systèmes d'exploitation ou les langages de programmation utilisés peuvent varier. Toutefois, ces facteurs n'affectent pas la gestion des bases de données multicloud.

Files d'attente et fichiers en tant que services de stockage de données

De nombreuses ressources de persistance sont disponibles pour que les services d'applications puissent conserver les données. Ces ressources incluent des bases de données, des files d'attente et des fichiers. Chaque ressource de persistance fournit des modèles de données de stockage et des modèles d'accès spécialisés pour ces modèles. Bien que les files d'attente, les systèmes de messagerie et les systèmes de fichiers soient utilisés par les applications, dans la section suivante, l'accent est mis spécifiquement sur les bases de données.

Bien que les mêmes considérations liées à des facteurs tels que l'emplacement de déploiement, le partage d'état, la réplication synchrone et asynchrone des bases de données multicloud soient applicables aux files d'attente et aux fichiers, ce sujet n'entre pas dans le cadre de ce document.

Mise en réseau

Dans l'architecture d'une application avec état générique (représentée dans le schéma suivant), chaque flèche entre les composants représente une relation de communication via une connexion réseau, par exemple un client d'application accédant à un service d'application.

Une connexion peut se trouver dans une zone ou entre plusieurs zones, régions ou clouds. Des connexions peuvent exister entre n'importe quelle combinaison d'emplacements de déploiement. Dans les environnements multicloud, la mise en réseau entre les clouds est un aspect important à prendre en compte et plusieurs options s'offrent à vous. Pour en savoir plus sur la mise en réseau entre différents clouds, consultez la page Connexion à Google Cloud : vos options de mise en réseau expliquées.

Dans les cas d'utilisation de ce document, nous partons du principe que :

• Une connexion réseau sécurisée existe entre les clouds.
• Les bases de données et leurs composants peuvent communiquer entre eux.

D'un point de vue non fonctionnel, la taille du réseau, c'est-à-dire le débit et la latence, peuvent affecter la latence et le débit de la base de données. D'un point de vue fonctionnel, la mise en réseau n'a généralement aucun effet.

Cas d'utilisation des bases de données multicloud

Cette section présente une sélection des cas d'utilisation les plus courants de gestion de bases de données multicloud. Pour ces cas d'utilisation, il est supposé qu'il existe une connectivité réseau sécurisée entre les clouds et les nœuds de base de données.

Migration d'applications

Dans le contexte de la gestion de bases de données multicloud, la migration d'applications fait référence à la migration d'une application, de tous les services d'application et de la base de données du cloud actuel vers un cloud cible. Il existe de nombreuses raisons pour lesquelles une entreprise peut décider de migrer une application, par exemple pour éviter une situation concurrentielle avec le fournisseur de cloud, moderniser la technologie ou réduire le coût total de possession (TCO).

Dans la migration des applications, l'intention est d'arrêter la production dans le cloud actuel et de continuer la production dans le cloud cible une fois la migration terminée. Les services d'application doivent s'exécuter dans le cloud cible. Pour mettre en œuvre les services, une approche Lift and Shift peut être utilisée. Dans cette approche, le même code est déployé dans le cloud cible. Pour réimplémenter le service, il est possible d'utiliser les technologies cloud modernes disponibles dans le cloud cible.

Du point de vue de la base de données, envisagez les alternatives suivantes pour la migration des applications :

• Migration Lift and Shift de bases de données : si le même moteur de base de données est disponible dans le cloud cible, vous pouvez effectuer une migration Lift and Shift de la base de données pour créer un déploiement identique dans le cloud cible.
• Migration Lift and Move to managed de base de données : une base de données autogérée peut être migrée vers une version gérée du même moteur de base de données si le cloud cible le fournit.
• Modernisation de bases de données : différents clouds offrent des technologies de base de données différentes. Les bases de données gérées par un fournisseur cloud peuvent offrir des avantages tels que des contrats de niveau de service plus stricts, une évolutivité et une reprise après sinistre automatique.

Quelle que soit la stratégie de déploiement, la migration de base de données est un processus qui prend du temps, car il est nécessaire de transférer les données du cloud actuel vers le cloud cible. Bien qu'il soit possible de suivre une approche d'exportation et d'importation qui entraîne des temps d'arrêt, une migration avec des temps d'arrêts minimums ou nuls est préférable. Cette approche minimise les temps d'arrêt des applications et a le moins d'effet sur une entreprise et ses clients. Cependant, cette méthode nécessite généralement une configuration de migration plus complexe, car elle implique un chargement initial, une réplication continue, une surveillance, une validation précise et une synchronisation lors du basculement. Pour gérer les scénarios de remplacement, vous devez mettre en œuvre un mécanisme de réplication inverse afin de synchroniser les modifications dans la base de données source après être passé à la base de données cible.

Reprise après sinistre

La reprise après sinistre désigne la capacité d'une application à continuer à fournir des services aux clients de l'application lors d'une panne régionale. Pour assurer la reprise après sinistre, une application doit être déployée dans au moins deux régions et être prête à être exécutée à tout moment. En production, l'application s'exécute dans la région principale. Toutefois, en cas de panne, une région secondaire devient la région principale. Voici les différents modèles d'aptitude à la reprise après sinistre :

• Hot Standby (secours à chaud). L'application est déployée dans au moins deux régions (principale et secondaire) et fonctionne entièrement dans toutes les régions. Si la région principale échoue, l'application de la région secondaire peut prendre immédiatement le trafic du client d'application.
• Secours à froid : L'application s'exécute dans la région principale, mais elle est prête pour le démarrage dans une région secondaire (mais pas en cours d'exécution). En cas de défaillance de la région principale, l'application est démarrée dans la région secondaire. Une interruption d'application se produit jusqu'à ce que l'application puisse exécuter et fournir tous les services d'application aux clients de l'application.
• Pas de secours. Dans ce modèle, le code d'application est prêt à être déployé, mais n'a pas encore été déployé dans la région secondaire (et n'utilise donc aucune ressource déployée). Si une région principale subit une panne, le premier déploiement de l'application doit se trouver dans la région secondaire. Ce déploiement place l'application dans le même état qu'un secours à froid, ce qui signifie qu'elle doit être démarrée. Dans cette approche, la panne de l'application est plus longue que celle du cas de secours à froid, car le déploiement de l'application doit d'abord avoir lieu, ce qui implique la création de ressources cloud.

Du point de vue de la base de données, les modèles d'aptitude décrits dans la liste précédente correspondent aux approches de base de données suivantes :

• Base de données synchronisée de manière transactionnelle : Cette base de données correspond au modèle de secours à chaud. Chaque transaction dans la région principale est validée de manière synchrone dans une région secondaire. Lorsque la région secondaire devient la région principale lors d'une panne, la base de données est cohérente et immédiatement disponible. Dans ce modèle, l'objectif de point de récupération (RPO) et l'objectif de temps de récupération (RTO, Recovery Time Objective) sont tous deux nuls.
• Base de données répliquée de manière asynchrone. Cette base de données correspond également au modèle de secours à chaud. Étant donné que la réplication de la base de données de la région principale vers la région secondaire est asynchrone, il est possible que si la région principale échoue, certaines transactions peuvent être répliquées dans la région secondaire. Bien que la base de données de la région secondaire soit prête pour la charge de production, elle ne dispose peut-être pas des données les plus récentes. Pour cette raison, l'application peut entraîner une perte de transactions qui ne peuvent pas être récupérées. En raison de ce risque, cette approche a un RTO de zéro, mais le RPO est supérieur à zéro.
• Base de données inactive. Cette base de données correspond au modèle de secours à froid. La base de données est créée sans données. En cas de défaillance de la région principale, les données doivent être chargées dans la base de données inactive. Pour activer cette action, vous devez effectuer une sauvegarde standard dans la région principale et la transférer vers la région secondaire. La sauvegarde peut être complète ou incrémentielle, en fonction de la compatibilité du moteur de base de données. Dans les deux cas, la base de données est redéfinie sur la dernière sauvegarde et, du point de vue de l'application, de nombreuses transactions peuvent être perdues par rapport à la région principale. Bien que cette approche puisse être rentable, la valeur est atténuée par le risque que toutes les transactions depuis la dernière sauvegarde disponible soient perdues en raison de l'état de la base de données pouvant ne pas être à jour.
• Aucune base de données Ce modèle est équivalent à celui aucun secours. La région secondaire n'a pas de base de données installée. Si la région principale échoue, une base de données doit être créée. Une fois la base de données créée, comme dans le cas de la base de données inactive, elle doit être chargée avec des données avant d'être disponible pour l'application.

Les approches de reprise après sinistre décrites dans ce document s'appliquent également si un cloud principal et un cloud secondaire sont utilisés à la place d'une région principale et secondaire. La principale différence est qu'en raison de l'hétérogénéité du réseau entre les clouds, la latence entre les clouds peut augmenter par rapport à la distance réseau entre les régions d'un cloud. D'autres écarts peuvent provenir de différentes fonctionnalités et paramètres par défaut des bases de données gérées de différents fournisseurs cloud.

La probabilité qu'une configuration cloud entière soit défaillante est inférieure à celle d'une région. Toutefois, il peut être utile pour les entreprises de déployer une application dans deux clouds. Cette approche peut aider à protéger une entreprise contre les défaillances, ou à respecter les réglementations commerciales ou sectorielles.

Une autre approche de reprise après sinistre consiste à disposer d'une région principale et d'une région secondaire, ainsi que d'un cloud principal et d'un cloud secondaire. Cette approche permet aux entreprises de choisir le meilleur processus de reprise après sinistre pour résoudre une situation de défaillance. Pour permettre l'exécution d'une application, vous pouvez utiliser une région secondaire ou un cloud secondaire, en fonction de la gravité de la panne.

Utilisation temporaire du cloud

L'utilisation temporaire du cloud fait référence à une configuration permettant d'augmenter le trafic client des applications sur différents emplacements de déploiement. Une application devient intensive lorsque la demande de capacité augmente et qu'un emplacement de secours fournit de la capacité supplémentaire. Un emplacement principal est compatible avec le trafic standard, tandis qu'un emplacement de secours peut offrir une capacité supplémentaire si le trafic client de l'application augmente au-delà de ce que l'emplacement principal peut accepter. L'emplacement principal et l'emplacement de secours disposent d'instances de service d'application déployées.

L'utilisation temporaire du cloud est mise en œuvre dans plusieurs clouds : un cloud principal et un second de secours. Elle est utilisée dans un contexte de cloud hybride pour augmenter un nombre limité de ressources de calcul dans des centres de données sur site avec des ressources de calcul cloud élastiques dans un cloud public.

Pour la compatibilité avec les bases de données, les options suivantes sont disponibles :

• Déploiement dans l'emplacement principal. Dans ce déploiement, la base de données n'est déployée que dans l'emplacement principal et non dans l'emplacement de secours. Lorsqu'une application devient intensive, l'application dans l'emplacement de secours accède à la base de données de l'emplacement principal.
• Déploiement dans l'emplacement principal et de secours. Ce déploiement est compatible avec l'emplacement principal et l'emplacement de secours. Une instance de base de données est déployée dans les deux emplacements et est accessible par les instances de service d'applications de cet emplacement, en particulier dans le cas d'une utilisation temporaire. Comme pour la reprise après sinistre au sein des clouds et entre clouds, les deux bases de données peuvent être synchronisées de manière transactionnelle ou synchronisées de manière asynchrone. Dans la synchronisation asynchrone, il peut y avoir un délai. Si des mises à jour sont effectuées dans l'emplacement de secours, elles doivent être propagées dans l'emplacement principal. Si des mises à jour simultanées sont possibles dans les deux emplacements, la résolution des conflits doit être mise en œuvre.

L'utilisation temporaire du cloud est un cas d'utilisation courant dans les clouds hybrides permettant d'augmenter la capacité des centres de données sur site. C'est également une approche qui peut être utilisée dans les clouds publics lorsque les données doivent rester dans un pays. Dans les cas où un cloud public ne comporte qu'une seule région dans un pays, il est possible de basculer en utilisation intensive dans une région d'un autre cloud public du même pays. Cette approche garantit que les données restent dans le pays tout en répondant aux contraintes de ressources dans la région des régions du cloud public.

Utilisation de services cloud de pointe

Certaines applications nécessitent des services et produits cloud spécialisés qui ne sont pas disponibles dans un cloud unique. Par exemple, une application peut effectuer un traitement de logique métier des données d'entreprise dans un cloud et des analyses des données d'entreprise dans un autre cloud. Dans ce cas d'utilisation, les parties de traitement de la logique métier et les parties d'analyse de l'application sont déployées sur différents clouds.

Du point de vue de la gestion des données, les cas d'utilisation sont les suivants :

• Données partitionnées. Chaque partie de l'application possède sa propre base de données (partition distincte). Aucune des bases de données n'est connectée directement les unes aux autres. L'application qui gère les données écrit toutes les données qui doivent être disponibles dans les deux bases de données (partitions) deux fois.
• Base de données répliquée de manière asynchrone. Si les données d'un cloud doivent être disponibles dans l'autre, une relation de réplication asynchrone peut être appropriée. Par exemple, si une application d'analyse nécessite le même ensemble de données ou un sous-ensemble de l'ensemble de données d'une application d'entreprise, cette dernière peut être répliquée entre les clouds.
• Base de données synchronisée de manière transactionnelle : Ces types de bases de données vous permettent de rendre les données disponibles pour les deux parties de l'application. Chaque mise à jour de chacune des applications est cohérente sur le plan transactionnel et disponible immédiatement pour les deux bases de données (partitions). Les bases de données synchronisées de manière transactionnelle fonctionnent comme une base de données distribuée unique.

Services distribués

Un service distribué est déployé et exécuté dans au moins deux emplacements de déploiement. Il est possible de déployer toutes les instances de service dans tous les emplacements de déploiement. Il est également possible de déployer certains services dans tous les emplacements et d'autres uniquement dans l'un des emplacements, en fonction de facteurs tels que la disponibilité matérielle ou la charge limitée attendue.

Les données d'une base de données synchronisée de manière transactionnelle sont cohérentes dans tous les emplacements. Par conséquent, une telle base de données est la meilleure option pour déployer des instances de service sur tous les emplacements de déploiement.

Lorsque vous utilisez une base de données répliquée asynchrone, le même élément de données peut être modifié simultanément dans deux emplacements de déploiement. Pour déterminer laquelle des deux modifications en conflit est l'état de cohérence finale, une stratégie de résolution des conflits doit être mise en œuvre. Bien qu'il soit possible de mettre en œuvre une stratégie de résolution des conflits, ce n'est pas toujours simple. Dans certains cas, une intervention manuelle est nécessaire pour restaurer les données dans un état cohérent.

Déménagement et basculement de services distribués

Si une région cloud entière échoue, la reprise après sinistre est lancée. Si un seul service d'une application de base de données avec état échoue (et non la région ou l'application entière), le service doit être récupéré et redémarré.

Une approche initiale pour la reprise après sinistre consiste à redémarrer le service défaillant dans son emplacement de déploiement d'origine (approche de redémarrage sur place). Des technologies telles que Kubernetes redémarrent automatiquement un service en fonction de sa configuration.

Toutefois, si cette approche de redémarrage sur place n'aboutit pas, vous pouvez également redémarrer le service dans un emplacement secondaire. Le service bascule de son emplacement principal vers un emplacement secondaire. Si l'application est déployée en tant qu'ensemble de services distribués, le basculement d'un seul service peut avoir lieu de manière dynamique.

Du point de vue de la base de données, le redémarrage du service à son emplacement de déploiement d'origine ne nécessite pas de déploiement de base de données spécifique. Lorsqu'un service est déplacé vers un autre emplacement de déploiement et qu'il accède à la base de données, les mêmes modèles d'aptitude que ceux décrits précédemment dans la section Services distribués de ce document s'appliquent.

Si un service est déplacé temporairement et si des latences plus élevées sont acceptables pour une entreprise pendant le transfert, le service peut accéder à la base de données entre les emplacements de déploiement. Bien que le service soit déplacé, il continue d'accéder à la base de données de la même manière qu'à partir de son emplacement de déploiement d'origine.

Déploiement dépendant du contexte

En général, un seul déploiement d'applications pour tous les clients d'applications inclut tous ses services et bases de données d'applications. Cependant, il existe des cas d'utilisation exceptionnels. Un déploiement d'application unique ne peut servir qu'à un sous-ensemble de clients (en fonction de critères spécifiques), ce qui signifie que plusieurs déploiements d'applications sont nécessaires. Chaque déploiement sert un sous-ensemble différent de clients, et tous les déploiements ensemble servent tous les clients.

Voici des exemples de cas d'utilisation d'un déploiement dépendant du contexte :

• Lors du déploiement d'une application mutualisée pour laquelle une application est déployée pour tous les petits locataires, une autre application est déployée pour chaque 10 locataires moyens et une application est déployée pour chaque locataire premium.
• Lorsqu'il est nécessaire de séparer les clients, par exemple les clients commerciaux et les clients gouvernementaux.
• Lorsqu'il est nécessaire de séparer les environnements de développement, de préproduction et de production.

Du point de vue de la base de données, il est possible de déployer une base de données pour chaque déploiement d'application dans une stratégie de déploiement un à un. Comme le montre le schéma suivant, cette stratégie illustre une approche simple dans laquelle les données partitionnées sont créées, car chaque déploiement possède son propre ensemble de données.

Le schéma précédent montre les éléments suivants :

• Une configuration comprenant trois déploiements d'une application.
• Chaque ensemble de données possède sa propre base de données.
• Aucune donnée n'est partagée entre les déploiements.

Dans de nombreux cas, un déploiement un à un constitue la stratégie la plus appropriée, mais il existe des alternatives.

Dans le cas d'une architecture mutualisée, les locataires peuvent être déplacés. Un locataire de petite taille peut devenir un locataire de taille moyenne et doit être transféré vers une autre application. Dans ce cas, les déploiements de bases de données distincts nécessitent une migration de base de données. Si une base de données distribuée est déployée et utilisée par tous les déploiements en même temps, toutes les données des locataires résident dans un seul système de base de données. Pour cette raison, le déplacement d'un locataire entre les bases de données ne nécessite pas de migration de base de données. Le schéma suivant illustre un exemple de ce type de base de données :

Le schéma précédent montre les éléments suivants :

• Trois déploiements d'une application.
• Les déploiements partagent tous une seule base de données distribuée.
• Les applications peuvent accéder à toutes les données de chaque déploiement.
• Aucun partitionnement des données n'est mis en œuvre.

Si une entreprise déplace souvent des locataires lors d'opérations de cycle de vie, la réplication de base de données peut être une alternative utile. Dans cette approche, les données des locataires sont répliquées entre les bases de données avant une migration de locataires. Dans ce cas, les bases de données indépendantes sont utilisées pour différents déploiements d'applications et ne sont configurées pour la réplication que juste avant et pendant la migration du locataire. Le schéma suivant illustre une réplication temporaire entre deux déploiements d'applications lors d'une migration de locataires.

Le schéma précédent montre trois déploiements d'une application avec trois bases de données distinctes contenant les données associées à chaque déploiement respectif. Pour migrer des données d'une base de données à une autre, la migration temporaire de la base de données peut être configurée.

Portabilité des applications

La portabilité des applications garantit qu'une application peut être déployée dans différents emplacements de déploiement, en particulier dans des clouds différents. Cette portabilité garantit la migration d'une application à tout moment, sans qu'il soit nécessaire de procéder à une reingénierie spécifique à la migration ni de développer d'autres applications pour préparer la migration.

Pour garantir la portabilité des applications, vous pouvez utiliser l'une des approches suivantes, décrites plus loin dans cette section :

• Portabilité basée sur le système
• Compatibilité avec les API
• Portabilité basée sur les fonctionnalités

La portabilité basée sur le système utilise les mêmes composants techniques que ceux utilisés dans tous les déploiements possibles. Pour garantir la portabilité du système, chaque technologie doit être disponible dans tous les emplacements de déploiement potentiels. Par exemple, si une base de données comme PostgreSQL est candidate, sa disponibilité dans tous les emplacements de déploiement potentiels doit être vérifiée pour la période attendue. Il en va de même pour toutes les autres technologies, par exemple les langages de programmation et les technologies d'infrastructure. Comme le montre le schéma suivant, cette approche établit un ensemble de fonctionnalités communes à tous les emplacements de déploiement basés sur la technologie.

Le schéma précédent illustre un déploiement d'application portable où l'application attend exactement le même système de base de données dans tous les emplacements où elle est déployée. Étant donné que le même système de base de données est utilisé dans chaque emplacement, l'application est portable. L'application peut s'attendre à ce que le même système de base de données soit utilisé tout au long du déploiement. Par conséquent, l'interface et le comportement exact du système de base de données peuvent être supposés.

Dans le contexte des bases de données, dans le système de compatibilité API, le client utilise une bibliothèque d'accès à la base de données spécifique (par exemple, une bibliothèque cliente MySQL) pour s'assurer qu'il peut se connecter à toute implémentation conforme disponible dans un environnement cloud. Le schéma suivant illustre la compatibilité de l'API.

Le schéma précédent montre la portabilité des applications en fonction de l'API du système de base de données plutôt que du système de base de données. Bien que les systèmes de base de données puissent être différents dans chacun des emplacements, l'API est identique et expose les mêmes fonctionnalités. L'application est portable, car elle peut supposer la même API dans chaque emplacement, même si le système de base de données sous-jacent est une technologie de base de données différente.

Pour la portabilité basée sur les fonctionnalités, différentes technologies peuvent fournir les mêmes fonctionnalités dans différents clouds. Par exemple, il peut être possible de limiter l'utilisation des bases de données au modèle relationnel. Étant donné que tout système de base de données relationnelle peut prendre en charge l'application, différents systèmes de base de données sur différentes versions peuvent être utilisés dans différents clouds sans affecter la portabilité de l'application. L'inconvénient de la portabilité basée sur les fonctionnalités est qu'elle ne peut utiliser que les parties du modèle de base de données compatibles avec tous les systèmes de base de données relationnelles. Au lieu d'un système de base de données compatible avec tous les clouds, vous devez utiliser un modèle de base de données. Le schéma suivant montre un exemple d'architecture pour la portabilité basée sur des fonctionnalités.

Comme le montre le schéma précédent, l'API du système de base de données et le système de base de données peuvent être différents à chaque emplacement. Pour assurer la portabilité, l'application ne doit utiliser que les parties de chaque système de base de données et chaque API disponible dans chaque emplacement. Étant donné qu'un seul sous-ensemble de chaque système de base de données est généralement disponible dans chaque emplacement, l'application doit restreindre son utilisation à ce sous-ensemble.

Pour garantir la portabilité de toutes les options de cette section, l'architecture complète doit être déployée en continu sur tous les emplacements cibles. Tous les scénarios de tests unitaires et système doivent être exécutés sur ces déploiements. Il s'agit d'exigences essentielles pour que les modifications des infrastructures et des technologies soient détectées rapidement et traitées.

Prévention de la dépendance des fournisseurs

La prévention des dépendances au fournisseur (verrouillage) permet de limiter le risque de dépendance vis-à-vis d'une technologie et d'un fournisseur spécifiques. En surface, il est semblable à la portabilité des applications. La prévention de la dépendance aux fournisseurs s'applique à toutes les technologies utilisées, et pas seulement aux services cloud. Par exemple, si MySQL est utilisé comme système de base de données et installé sur des machines virtuelles dans les clouds, il n'y a pas de dépendance du point de vue du cloud, mais il existe une dépendance à MySQL. Une application portable entre différents clouds peut dépendre des technologies fournies par différents fournisseurs autre que le cloud.

Pour éviter la dépendance aux fournisseurs, toutes les technologies doivent être remplaçables. Pour cette raison, une abstraction complète et structurée de toutes les fonctionnalités de l'application est nécessaire pour que chaque service d'application puisse être réimplémenté dans une base technologique différente sans affecter la mise en œuvre de l'application. Du point de vue de la base de données, cette abstraction peut être effectuée en séparant l'utilisation d'un modèle de base de données d'un système de gestion de base de données particulier.

Système de gestion de base de données de production existant

Tandis que de nombreuses applications multicloud sont développées avec des systèmes de base de données lors de leur conception, de nombreuses entreprises développent des applications multicloud dans le cadre de leurs efforts de modernisation. Ces applications sont développées en supposant que l'application nouvellement conçue et mise en œuvre accède aux bases de données existantes.

Il existe de nombreuses raisons de ne pas intégrer les bases de données existantes dans un effort de modernisation. Certaines fonctionnalités spécifiques peuvent être utilisées et ne pas être disponibles sur d'autres systèmes de base de données. Une entreprise peut disposer de bases de données avec des processus de gestion complexes et bien établis, ce qui rend le passage à un autre système peu pratique ou peu économique. Une entreprise peut également choisir de moderniser une application dans la première phase et de moderniser la base de données lors de la deuxième phase.

Lorsqu'une entreprise utilise un système de base de données existant, le concepteur de l'application multicloud doit décider s'il s'agit de la seule base de données utilisée ou si un autre système de base de données doit être ajouté pour différents emplacements de déploiement. Par exemple, si une base de données est utilisée sur site et que l'application doit également s'exécuter dans Google Cloud, elle doit déterminer si les services d'application déployés sur Google Cloud accèdent à la base de données sur site. Ou, si une deuxième base de données doit être déployée à la fois dans Google Cloud et pour les services d'application exécutés localement.

Si une deuxième base de données est déployée dans Google Cloud, le cas d'utilisation peut être identique aux cas d'utilisation décrits dans la section Utilisation intensive du cloud ou Services distribués. Dans les deux cas, la même discussion sur la base de données s'applique comme dans ces sections. Cependant, elle est limitée aux fonctionnalités multi-emplacements que la base de données existante sur site peut gérer, par exemple la synchronisation et la réplication.

Modèles de déploiement

Les cas d'utilisation abordés dans ce document soulèvent une question courante du point de vue des bases de données : si les bases de données se trouvent dans plusieurs emplacements de déploiement, quelle est leur relation ?

Les principaux types de relations (modèles de déploiement) décrits dans la section suivante sont les suivants :

• Partitionnement sans dépendance entre bases de données
• Réplication unidirectionnelle asynchrone
• Réplication bidirectionnelle avec résolution de conflit
• Système distribué entièrement actif et synchronisé

Il est possible de mapper chaque cas d'utilisation de ce document à un ou plusieurs des quatre modèles de déploiement.

Dans la discussion suivante, nous partons du principe que les clients accèdent directement aux services de l'application. Selon le cas d'utilisation, un équilibreur de charge peut être nécessaire pour diriger de manière dynamique l'accès client aux applications, comme illustré dans le schéma suivant.

Dans le schéma précédent, un équilibreur de charge cloud dirige les appels des clients vers l'un des emplacements disponibles. L'équilibreur de charge garantit que les règles d'équilibrage de charge sont appliquées et que les clients sont dirigés vers l'emplacement approprié de l'application et de sa base de données.

Partitionnement sans dépendance entre bases de données

Ce modèle de déploiement est le plus simple de tous les modèles abordés dans ce document : chaque emplacement ou cloud possède une base de données et les bases de données contiennent des ensembles de données partitionnés qui ne dépendent pas les uns des autres. Un élément de données est stocké dans une seule base de données. Chaque partition de données se trouve dans sa propre base de données. Un exemple de ce modèle est une application mutualisée dans laquelle un ensemble de données se trouve dans l'une ou l'autre base de données. Le schéma suivant illustre deux applications entièrement partitionnées.

Comme le montre le schéma précédent, une application est déployée à deux emplacements, chacun étant responsable d'une partition de l'ensemble de données complet. Chaque élément de données ne réside que dans l'un des emplacements, ce qui garantit un ensemble de données partitionné sans aucune réplication entre les deux.

Un autre modèle de déploiement pour les bases de données partitionnées est l'ensemble de données entièrement partitionné, mais toujours stocké dans la même base de données. Il n'existe qu'une seule base de données contenant tous les ensembles de données. Bien que les ensembles de données soient stockés dans la même base de données, ils sont complètement séparés (partitionnés) et la modification de l'un n'entraîne pas de modifications dans l'autre. Le schéma suivant montre deux applications qui partagent une même base de données.

Le schéma précédent montre les éléments suivants :

• Deux déploiements d'applications qui partagent une base de données commune, qui se trouve dans le premier emplacement.
• Chaque application peut accéder à toutes les données du déploiement, car l'ensemble de données n'est pas partitionné.

Réplication unidirectionnelle asynchrone

Ce modèle de déploiement comporte une base de données principale qui est répliquée sur une ou plusieurs bases de données secondaires. La base de données secondaire peut être utilisée pour un accès en lecture, mais l'application doit prendre en compte le délai avant réplication possible. Un exemple de ce modèle est celui où la meilleure base de données pour un cas d'utilisation particulier est utilisée comme base de données principale et la base de données secondaire pour l'analyse. Le schéma suivant montre deux applications accédant à des bases de données répliquées de manière unidirectionnelle.

Comme le montre le schéma précédent, l'une des deux bases de données est une réplique de l'autre. La flèche du diagramme indique la direction de la réplication : les données du système de base de données dans l'emplacement 1 sont répliquées dans le système de base de données dans l'emplacement 2.

Réplication bidirectionnelle avec résolution de conflit

Ce modèle de déploiement comporte deux bases de données principales qui sont répliquées de manière asynchrone entre elles. Si les mêmes données sont écrites en même temps dans chaque base de données (par exemple, la même clé primaire), cela peut entraîner un conflit d'écriture. En raison de ce risque, une résolution de conflit doit être en place pour déterminer quel état est le dernier état pendant la réplication. Ce modèle peut être utilisé dans les situations où le risque de conflit d'écriture-écriture est rare. Le schéma suivant illustre deux applications accédant à des bases de données répliquées de manière bidirectionnelle.

Comme le montre le schéma précédent, chaque base de données est répliquée sur l'autre base de données. Les deux réplications sont indépendantes les unes des autres, comme indiqué dans le diagramme par deux flèches bleues distinctes. Les deux réplications étant indépendantes, un conflit peut survenir si, par hasard, le même élément de données est modifié par chacune des applications et répliquée simultanément. Dans ce cas, la résolution des conflits doit avoir lieu.

Système distribué entièrement actif et synchronisé

Ce modèle de déploiement dispose d'une base de données unique avec une configuration active-active (également principale-principale). Dans une configuration en mode actif/actif, la mise à jour des données de toute base de données principale est cohérente de manière transactionnelle et répliquée de manière synchrone. Un exemple de cas d'utilisation pour ce modèle est le calcul distribué. Le schéma suivant montre deux applications qui accèdent à une base de données principale-principale entièrement synchronisée.

Comme le montre le schéma ci-dessus, cet agencement garantit que chaque application accède toujours au dernier état cohérent, sans retard ni risque de conflit. Une modification apportée à une base de données est immédiatement disponible dans l'autre base de données. Toute modification est reflétée dans les deux bases de données lorsqu'un commit de transaction change.

Classification de système de base de données

Les systèmes de gestion de base de données ne sont pas tous compatibles avec les modèles de déploiement décrits dans ce document. Selon le cas d'utilisation, il peut être possible de mettre en œuvre un seul modèle de déploiement ou une combinaison de modèles de déploiement avec un seul sous-ensemble de systèmes de base de données.

Dans la section suivante, les différents systèmes de base de données sont classés et mappés aux quatre modèles de déploiement.

Il est possible de classer les bases de données en fonction de différentes dimensions, telles que le modèle de données, l'architecture interne, le modèle de déploiement et les types de transaction. Dans la section suivante, dans le cadre de la gestion de base de données multicloud, deux dimensions sont utilisées :

• Architecture de déploiement Architecture de la manière dont un système de gestion de base de données est déployé sur des ressources de clouds (par exemple, des moteurs de calcul ou gérés dans le cloud).
• Modèle de distribution Modèle de distribution compatible avec un système de base de données (par exemple, instance unique ou distribution complète).

Ces deux dimensions sont les plus pertinentes dans le contexte des cas d'utilisation multicloud et peuvent prendre en charge les quatre modèles de déploiement dérivés du cas d'utilisation de bases de données multicloud. Une catégorisation populaire est basée sur les modèles de données compatibles avec un système de gestion de base de données. Certains systèmes n'acceptent qu'un seul modèle (par exemple, un modèle de graphique). D'autres systèmes prennent en charge plusieurs modèles de données en même temps (par exemple, les modèles relationnels et de document). Toutefois, dans le contexte de la gestion de bases de données multicloud, cette catégorisation n'est pas pertinente, car les applications multicloud peuvent utiliser n'importe quel modèle de données pour leur déploiement multicloud.

Système de base de données par architecture de déploiement

La gestion de bases de données multicloud inclut les quatre principales classes d'architecture de déploiement suivantes pour les systèmes de gestion de bases de données :

• Bases de données cloud intégrées Les bases de données cloud intégrées sont conçues, construites et optimisées pour fonctionner avec la technologie cloud. Par exemple, certains systèmes de base de données utilisent Kubernetes comme plate-forme d'implémentation et exploiter les fonctionnalités Kubernetes. CockroachDB et YugaByte sont des exemples de ce type de base de données. Ils peuvent être déployés dans n'importe quel cloud compatible avec Kubernetes.
• Bases de données gérées par le fournisseur cloud Les bases de données gérées par le fournisseur cloud sont basées sur une technologie spécifique au fournisseur de cloud et sont un service de base de données géré par un fournisseur cloud spécifique. Spanner, Bigtable et AlloyDB pour PostgreSQL sont des exemples de ce type de base de données. Les bases de données gérées par le fournisseur cloud ne sont disponibles que dans le cloud du fournisseur cloud et ne peuvent pas être installées ni exécutées ailleurs. Cependant, AlloyDB pour PostgreSQL est entièrement compatible avec PostgreSQL.
• Bases de données pré-cloud Les bases de données préexistantes au cloud étaient créées avant le développement de la technologie cloud (parfois pendant un long moment), et étaient généralement exécutées sur du matériel dédié et des machines virtuelles (VM). PostgreSQL, MySQL et SQL Server sont des exemples de ce type de base de données. Ces systèmes peuvent s'exécuter sur n'importe quel cloud compatible avec les VM ou le matériel dédié.
• Bases de données gérées par les partenaires cloud Certains clouds publics ont des partenaires de base de données qui installent et gèrent les bases de données des clients dans le cloud public. Pour cette raison, les clients n'ont pas à gérer ces bases de données eux-mêmes. MongoDB Atlas et MariaDB sont des exemples de ce type de base de données.

Il existe certaines variantes de ces catégories principales. Par exemple, un fournisseur de base de données qui met en œuvre une base de données conçue pour le cloud peut également proposer une installation sur la technologie conçue pour le cloud et une offre gérée pour les clients dans son cloud fourni par le fournisseur. Cette approche équivaut au fournisseur offrant un cloud public qui n'est compatible qu'avec sa base de données en tant que service unique.

Les bases de données préexistantes au cloud peuvent également se trouver dans des conteneurs et être déployées dans un cluster Kubernetes. Toutefois, ces bases de données n'utilisent pas les fonctionnalités spécifiques à Kubernetes, telles que le scaling, le déploiement multiservice ou le déploiement multipod.

Les fournisseurs de base de données peuvent s'associer à plusieurs fournisseurs de cloud public en même temps, proposant leur base de données en tant que base de données cloud gérée par les partenaires dans plusieurs clouds publics.

Système de base de données par modèle de distribution

Différents systèmes de gestion de base de données sont mis en œuvre en fonction des modèles de distribution de l'architecture d'une base de données. Les modèles de bases de données sont les suivants :

• Instance unique. Une seule instance de base de données s'exécute sur une VM ou un conteneur, et sert de système centralisé. Ce système gère tous les accès à la base de données. Comme une instance unique ne peut pas être connectée à une autre instance, le système de base de données n'est pas compatible avec la réplication.
• Plusieurs instances actives/passives. Dans cette architecture commune, plusieurs instances de base de données sont liées. La liaison la plus courante est une relation active-passive dans laquelle une instance est l'instance de base de données active qui prend en charge les deux instances, et écrit et lit. Un ou plusieurs systèmes passifs sont en lecture seule et reçoivent toutes les modifications de bases de données de l'instance principale, de manière synchrone ou asynchrone. Les systèmes passifs peuvent fournir un accès en lecture. On parle également d'instance active/passive comme instance principale-secondaire ou instance répliquée source.
• Multi-instance active-active : Dans cette architecture relativement peu courante, chaque instance est une instance active. Dans ce cas, chaque instance peut exécuter des transactions de lecture et d'écriture et assurer la cohérence des données. Pour cette raison, pour éviter les incohérences de données, toutes les instances sont toujours synchronisées.
• Multi-instance active-active avec résolution de conflits Il s'agit également d'un système relativement rare. Chaque instance est disponible pour l'accès en écriture et en lecture, mais les bases de données sont synchronisées en mode asynchrone. Les mises à jour simultanées du même élément de données sont autorisées, ce qui entraîne un état incohérent. Une règle de résolution des conflits doit décider quel état est le dernier état cohérent.
• Segmentation multi-instances. La segmentation est basée sur la gestion des partitions de données (dissociées). Une instance de base de données distincte gère chaque partition. Cette distribution est évolutive, car davantage de segments peuvent être ajoutés de manière dynamique au fil du temps. Cependant, il est possible que les requêtes croisées entre segments ne soient pas possibles, car cette fonctionnalité n'est pas prise en charge par tous les systèmes.

Tous les modèles de distribution abordés dans cette section peuvent accepter la segmentation et peuvent être un système segmenté. Cependant, tous les systèmes ne sont pas conçus pour fournir une option de segmentation. La segmentation est un concept d'évolutivité qui n'est généralement pas pertinent pour la sélection de l'architecture de bases de données dans des environnements multicloud.

Les modèles de distribution sont différents pour les bases de données cloud et gérées par les partenaires. Étant donné que ces bases de données sont liées à l'architecture d'un fournisseur cloud, ces systèmes mettent en œuvre des architectures basées sur les emplacements de déploiement suivants :

• Système zonal. Un système de base de données géré par une zone est lié à une zone. Lorsque la zone est disponible, le système de base de données l'est également. Cependant, si la zone devient indisponible, il est impossible d'accéder à la base de données.
• Système régional. Une base de données gérée régionale est liée à une région et est accessible lorsqu'au moins une zone est accessible. Toute combinaison de zones peut devenir inaccessible.
• Système interrégional. Un système interrégional est lié à deux régions ou plus et fonctionne correctement lorsqu'au moins une région est disponible.

Un système interrégional peut également prendre en charge un système inter-cloud si la base de données peut être installée dans tous les clouds qu'une entreprise prévoit d'utiliser.

Il existe d'autres alternatives aux architectures de bases de données gérées décrites dans cette section. Un système régional peut partager un disque entre deux zones. Si l'une des deux zones devient inaccessible, le système de base de données peut continuer dans la zone restante. Toutefois, si une panne affecte les deux zones, le système de base de données n'est pas disponible, même si d'autres zones peuvent rester entièrement en ligne.

Mapper des systèmes de base de données avec des modèles de déploiement

Le tableau suivant décrit la relation entre les modèles de déploiement et les architectures de déploiement décrits dans ce document. Les champs d'état indiquent les conditions nécessaires pour former une combinaison, en fonction du modèle et de l'architecture de déploiement.

Architecture de déploiement	Modèle de déploiement
	Partitionnement sans dépendance entre bases de données	Réplication unidirectionnelle asynchrone	Réplication bidirectionnelle avec résolution de conflit	Système distribué entièrement actif et synchronisé
Bases de données cloud intégrées	Possible pour tous les clouds fournissant la technologie cloud intégrée utilisée par les systèmes de base de données. Si la même base de données n'est pas disponible, différents systèmes de base de données peuvent être utilisés.	Base de données cloud fournissant une réplication.	Base de données cloud fournissant une réplication bidirectionnelle	Base de données cloud fournissant une synchronisation principale-principale.
Bases de données gérées par le fournisseur cloud	Les systèmes de base de données peuvent être différents dans différents clouds.	L'instance dupliquée ne doit pas nécessairement être la base de données gérée par le fournisseur cloud (consultez la section Rôle de la technologie de migration de base de données dans les modèles de déploiement).	Uniquement dans un cloud, et non sur plusieurs clouds, si la base de données fournit une réplication bidirectionnelle.	Uniquement dans un cloud, et non sur plusieurs clouds, si la base de données fournit une synchronisation principale/principale.
Bases de données pré-cloud	Les systèmes de base de données peuvent être identiques ou différents dans différents clouds.	La réplication est possible sur plusieurs clouds.	Le système de base de données fournit une réplication bidirectionnelle et une résolution des conflits.	Le système de base de données fournit une synchronisation principale-principale.
Bases de données gérées par les partenaires cloud	Les systèmes de base de données peuvent être différents dans différents clouds. Si le partenaire fournit un système de base de données géré dans tous les clouds requis, la même base de données peut être utilisée.	L'instance dupliquée ne doit pas nécessairement être la base de données gérée par le fournisseur cloud. Si le partenaire fournit un système de base de données géré dans tous les clouds requis, la même base de données peut être utilisée.	Le système de base de données fournit une réplication bidirectionnelle et une résolution des conflits.	Le système de base de données fournit une synchronisation principale-principale.

Si un système de base de données ne fournit pas de réplication intégrée, il est possible d'utiliser la technologie de réplication de base de données. Pour en savoir plus, consultez la section Rôle de la technologie de migration de base de données dans les modèles de déploiement.

Le tableau suivant associe les modèles de déploiement aux modèles de distribution. Les champs d'état indiquent les conditions pour lesquelles la combinaison est possible en fonction d'un modèle de déploiement et d'un modèle de distribution.

Modèle de distribution	Modèle de déploiement
	Partitionnement sans dépendance entre bases de données	Réplication unidirectionnelle asynchrone	Réplication bidirectionnelle avec résolution de conflit	Système distribué entièrement actif et synchronisé
Instance unique	Possible avec le même système de base de données ou un système différent dans les clouds concernés.	Non applicable	Non applicable	Non applicable
Multi-instance active-passive	Possible avec le même système de base de données ou un système différent dans les clouds concernés.	La réplication est possible entre les différents clouds.	La réplication est possible entre les différents clouds.	Non applicable
Multi-instance active-active	Possible avec le même système de base de données ou un système différent dans les clouds concernés.	Non applicable	Non applicable	La synchronisation est possible entre les différents clouds.
Multi-instance active-active avec résolution de conflits	Possible avec le même système de base de données ou un système différent dans les clouds concernés.	Non applicable	Non applicable	Applicable si la réplication bidirectionnelle est possible sur les différents clouds.

Certaines implémentations de modèles de distribution qui ajoutent des abstractions supplémentaires basées sur la technologie de base de données sous-jacente ne disposent pas d'un tel modèle de distribution. Par exemple, Postgres-BDR. un système actif-actif. Ces systèmes sont inclus dans le tableau précédent dans la catégorie correspondante. Du point de vue du multicloud, la mise en œuvre d'un modèle de distribution n'est pas pertinente.

Migration et réplication de base de données

Selon le cas d'utilisation, une entreprise peut avoir besoin de migrer une base de données d'un emplacement de déploiement à un autre. Pour le traitement en aval, il peut également être nécessaire de répliquer les données d'une base de données vers un autre emplacement. Dans la section suivante, la migration et la réplication de base de données sont décrites plus en détail.

Migrer des bases de données

La migration de base de données est utilisée lorsqu'une base de données est déplacée d'un emplacement de déploiement à un autre. Par exemple, une base de données s'exécutant dans un centre de données sur site est migrée pour s'exécuter dans le cloud. Une fois la migration terminée, la base de données est arrêtée dans le centre de données sur site.

Les principales approches de la migration de base de données sont les suivantes :

• Migration Lift and Shift La VM et les disques exécutant les instances de base de données sont copiés tels quels dans l'environnement cible. Une fois qu'elles sont copiées, elles démarrent et la migration est terminée.
• Exporter et importer, sauvegarder et restaurer : Ces approches utilisent toutes deux les fonctionnalités du système de base de données pour externaliser une base de données et la recréer à l'emplacement cible. L'exportation/importation est généralement basée sur un format ASCII, tandis que la sauvegarde et la restauration est basée sur un format binaire.
• Migration sans temps d'arrêt. Dans cette approche, une base de données est migrée pendant que les systèmes d'application accèdent au système source. Après un chargement initial, les modifications sont transmises de la source à la base de données cible à l'aide des technologies de capture de données modifiées (CDC, Change Data Capture). L'application subit un temps d'arrêt entre le moment où elle est arrêtée sur le système de base de données source et celui où il est redémarré sur le système de base de données cible une fois la migration terminée.

La migration de base de données devient pertinente dans les cas d'utilisation multicloud lorsqu'une base de données est déplacée d'un cloud à un autre ou d'un type de moteur de base de données à un autre.

La migration de base de données est un processus multiforme. Pour en savoir plus, consultez les pages Migration de bases de données : concepts et principes (partie 1) et Migration de bases de données : concepts et principes (partie 2).

Les technologies de base de données intégrées peuvent être utilisées pour effectuer la migration de bases de données, par exemple les protocoles d'exportation/importation, de sauvegarde/restauration ou de réplication intégrée. Lorsque les systèmes de base de données source et cible sont différents, les technologies de migration constituent la meilleure option pour la migration de base de données. Database Migration Service, Striim et Debezium sont des exemples de technologies de migration de bases de données.

Réplication de base de données

La réplication de base de données est semblable à la migration de base de données. Cependant, lors de la réplication de la base de données, le système de base de données source reste en place pendant que chaque modification est transmise à la base de données cible.

La réplication de base de données est un processus continu qui envoie les modifications de la base de données source vers la base de données cible. Lorsque ce processus est asynchrone, les modifications arrivent à la base de données cible après un court délai. Si le processus est synchrone, les modifications apportées au système source sont apportées au système cible en même temps et aux mêmes transactions.

Outre la réplication d'une base de données source vers une base de données cible, une pratique courante consiste à répliquer les données d'une base de données source vers un système d'analyse cible.

Comme pour la migration de bases de données, si les protocoles de réplication sont intégrés, vous pouvez utiliser la technologie intégrée de base de données pour la réplication de base de données. S'il n'existe pas de protocoles de réplication intégrés, il est possible d'utiliser une technologie de réplication telle que Striim ou Debezium. .

Le rôle de la technologie de migration de base de données dans les modèles de déploiement

La technologie de base de données intégrée permettant d'activer la réplication n'est généralement pas disponible lorsque différents systèmes de base de données sont utilisés dans les modèles de déploiement, par exemple la réplication asynchrone (hétérogène). À la place, la technologie de migration de base de données peut être déployée pour permettre ce type de réplication. Certains de ces systèmes de migration mettent également en œuvre la réplication bidirectionnelle.

Si la technologie de migration ou de réplication de base de données est disponible pour les systèmes de base de données utilisés dans les combinaisons marquées "Non applicable" dans le Tableau 1 ou le Tableau 2 de la section Mapper des systèmes de base de données à des modèles de déploiement elle peut alors être utilisée pour la réplication de base de données. Le schéma suivant illustre une approche de réplication de base de données à l'aide d'une technologie de migration.

Dans le schéma précédent, la base de données de l'emplacement 1 est répliquée dans la base de données de l'emplacement 2. Au lieu d'une réplication directe du système de base de données, un serveur de migration est déployé pour mettre en œuvre la réplication. Cette approche est utilisée pour les systèmes de base de données n'ayant pas intégré la fonctionnalité de réplication de base de données et nécessitant un système distinct du système de base de données pour mettre en œuvre la réplication.

Sélection de bases de données multicloud

Les cas d'utilisation de bases de données multicloud combinées à la catégorisation du système de base de données vous aident à choisir les bases de données les mieux adaptées à un cas d'utilisation donné. Par exemple, pour mettre en œuvre le cas d'utilisation de la portabilité des applications, il existe deux options. La première option consiste à s'assurer que le même moteur de base de données est disponible dans tous les clouds. Cette approche garantit la portabilité du système. La deuxième option consiste à s'assurer que le même modèle de données et la même interface de requête sont disponibles pour tous les clouds. Bien que les systèmes de base de données puissent être différents, la portabilité est fournie sur une interface fonctionnelle.

Les arbres de décision des sections suivantes présentent les critères de décision pour les cas d'utilisation de bases de données multicloud de ce document. Les arbres de décision suggèrent la base de données la plus adaptée à chaque cas d'utilisation.

Bonnes pratiques pour un système de base de données existant

Si un système de base de données est en production, il convient de décider de le conserver ou de le remplacer. Le schéma suivant illustre les questions à poser dans votre processus de décision :

Les questions et les réponses de l'arbre de décision sont les suivantes :

• Un système de base de données est-il en production ?
  • Si aucun système de base de données n'est en production, sélectionnez un système de base de données (passez à la décision sur la gestion des bases de données multicloud).
  • Si un système de base de données est en production, évaluez s'il doit être conservé.
• Si un système de base de données est en production, évaluez s'il doit être conservé.
  • Si le système de base de données doit être conservé, la décision est prise et le processus de décision est terminé.
  • Si le système de base de données doit être modifié ou si la décision est encore en cours, sélectionnez un système de base de données (passez à la section Décision concernant la gestion des bases de données multicloud).

Décision concernant la gestion de bases de données multicloud

L'arbre de décision suivant concerne un cas d'utilisation avec une exigence de base de données multi-emplacement (y compris un déploiement de base de données multicloud). Il utilise le modèle de déploiement comme base pour les critères de prise de décision.

Les questions et les réponses de l'arbre de décision sont les suivantes :

• Les données sont-elles partitionnées dans différentes bases de données sans aucune dépendance entre les bases de données ?
  • Si oui, il est possible de sélectionner des systèmes identiques ou différents pour chaque emplacement.
  • Si ce n'est pas le cas, passez à la question suivante.
• La réplication asynchrone unidirectionnelle est-elle nécessaire ?
  • Si oui, évaluez si un système de réplication de base de données est acceptable.
    • Si oui, sélectionnez des systèmes de base de données (les mêmes ou différents) compatibles avec le système de réplication.
    • Si ce n'est pas le cas, sélectionnez un système de base de données pouvant mettre en œuvre un modèle de distribution actif/passif.
    • Si ce n'est pas le cas, passez à la question suivante.
• Sélectionnez un système de base de données avec des instances synchronisées.
  • La résolution des conflits est-elle acceptable ?
    • Si oui, sélectionnez un système de base de données à réplication bidirectionnelle ou un système de base de données actif-actif.
    • Si ce n'est pas le cas, sélectionnez un système actif-actif.

Si plusieurs cas d'utilisation multicloud sont mis en œuvre, une entreprise doit décider si elle souhaite utiliser un système de base de données pour prendre en charge tous les cas d'utilisation, ou plusieurs systèmes de base de données.

Si une entreprise souhaite utiliser un seul système de base de données pour gérer tous les cas d'utilisation, le système offrant la meilleure synchronisation est le meilleur choix. Par exemple, si une réplication unidirectionnelle est requise, ainsi que des instances synchronisées, il est préférable de choisir les instances synchronisées.

La hiérarchie de la qualité de synchronisation est (de zéro à meilleure) : réplication partitionnée, unidirectionnelle, réplication bidirectionnelle et réplication entièrement synchronisée.

Bonnes pratiques de déploiement

Cette section présente les bonnes pratiques à suivre lorsque vous choisissez une base de données pour la migration ou le développement d'applications multicloud.

Système de gestion de base de données existant

Il peut être judicieux de conserver une base de données et de ne pas modifier le système de base de données, sauf si nécessaire dans un cas d'utilisation spécifique. Pour une entreprise disposant d'un système de gestion de base de données établi et disposant de processus de développement, d'exploitation et de maintenance efficaces, il est préférable d'éviter d'apporter des modifications.

Pour un cas d'utilisation temporaire du cloud ne nécessitant pas de système de base de données dans le cloud, il n'est peut-être pas nécessaire de changer de base de données. Un autre cas d'utilisation est la réplication asynchrone vers un autre emplacement de déploiement dans le même cloud ou vers un autre cloud. Pour ces cas d'utilisation, une bonne approche consiste à mettre en œuvre un benchmark et à vérifier que la communication inter-sites et la communication entre zones et la latence répondent aux exigences de l'application lors de l'accès à la base de données.

Système de base de données en tant que service Kubernetes

Si une entreprise envisage d'exécuter un système de base de données dans Kubernetes en tant que service basé sur des StatefulSets, les facteurs suivants doivent être pris en compte :

• Si la base de données fournit le modèle de base de données requis par l'application.
• Facteurs non fonctionnels qui déterminent la manière dont l'opérationnalisation est mise en œuvre dans un système de base de données en tant que service Kubernetes, par exemple le processus de scaling (scaling à la hausse ou à la baisse), comment la sauvegarde et la restauration sont gérées, et la façon dont la surveillance est mise à disposition par le système. Pour les aider à comprendre les exigences d'un système de base de données basé sur Kubernetes, les entreprises doivent utiliser leurs expériences avec celles-ci comme point de comparaison.
• Haute disponibilité et reprise après sinistre Pour assurer une haute disponibilité, le système doit continuer à fonctionner en cas de défaillance d'une zone d'une région. La base de données doit pouvoir basculer rapidement d'une zone à une autre. Dans le scénario idéal, la base de données comporte une instance en cours d'exécution dans chaque zone qui est entièrement synchronisée pour un RTO et un RPO de zéro.
• La reprise après sinistre pour remédier à la défaillance d'une région (ou d'un cloud). Dans un scénario idéal, la base de données continue de fonctionner dans une deuxième région avec un RPO et un RTO de zéro. Dans un scénario moins idéal, il se peut que la base de données de la région secondaire ne soit pas complètement à jour avec toutes les transactions de la base de données principale.

Pour déterminer le meilleur moyen d'exécuter une base de données dans Kubernetes, une évaluation complète de la base de données est une bonne approche, en particulier lorsque le système doit être comparable à un système en production en dehors de Kubernetes.

Système de base de données indépendant de Kubernetes

Il n'est pas toujours nécessaire qu'une application mise en œuvre en tant que services dans Kubernetes exécute la base de données dans Kubernetes en même temps. Un système de base de données doit être exécuté en dehors de Kubernetes pour de nombreuses raisons, par exemple, des processus établis, des connaissances sur les produits au sein d'une entreprise ou une indisponibilité. Les base de données de fournisseurs cloud et les bases de données cloud gérées par les partenaires entrent dans cette catégorie.

Il est tout aussi possible et faisable d'exécuter une base de données sur un moteur de calcul. Lorsque vous sélectionnez un système de base de données, il est recommandé d'effectuer une évaluation complète de la base de données pour vous assurer que toutes les exigences d'une application sont remplies.

Du point de vue de la conception de l'application, le regroupement de connexions est un aspect important à prendre en compte. Un service d'application accédant à une base de données peut utiliser un pool de connexions en interne. L'utilisation d'un pool de connexions est bénéfique pour l'efficacité et réduit la latence. Les requêtes sont prises à partir du pool sans qu'il soit nécessaire de les lancer, et il n'y a aucune attente de création de connexions. Si cette application est mise à l'échelle en ajoutant des instances de service d'application, chaque instance crée un pool de connexions. Si les bonnes pratiques sont appliquées, chaque pool crée préalablement un ensemble minimal de connexions. Chaque fois qu'une autre instance de service d'application est créée pour le scaling d'une application, des connexions sont ajoutées à la base de données. Du point de vue de la conception, les bases de données ne pouvant pas accepter de connexions illimitées, vous devez gérer l'ajout de connexions pour éviter toute surcharge.

Meilleur système de base de données ou la portabilité du système de base de données

Lors de la sélection de systèmes de base de données, il est fréquent que les entreprises choisissent le meilleur système de base de données pour répondre aux exigences d'une application. Dans un environnement multicloud, vous pouvez sélectionner la meilleure base de données dans chaque cloud et les connecter les unes aux autres en fonction du cas d'utilisation. Si ces systèmes sont différents, une réplication (bidirectionnelle ou bidirectionnelle) nécessite un effort considérable. Cette approche peut être justifiée si l'avantage d'utiliser le meilleur système l'emporte sur les efforts nécessaires à sa mise en œuvre.

Cependant, une bonne pratique consiste à envisager et à évaluer simultanément une approche pour un système de base de données disponible dans tous les clouds requis. Bien qu'une telle base de données puisse ne pas être aussi idéale que la meilleure option, il peut être beaucoup plus facile de mettre en œuvre, utiliser et gérer un tel système.

Une évaluation simultanée d'un système de base de données démontre les avantages et les inconvénients des deux systèmes de base de données, offrant ainsi une base solide pour la sélection.

Réplication du système de base de données intégrée ou externe

Pour les cas d'utilisation nécessitant un système de base de données dans tous les emplacements de déploiement (zones, régions ou clouds), la réplication est une fonctionnalité importante. La réplication peut être asynchrone, bidirectionnelle ou entièrement synchronisée (active-active). Les systèmes de base de données ne sont pas tous compatibles avec toutes ces formes de réplication.

Pour les systèmes qui ne sont pas compatibles avec la réplication dans le cadre de la réplication d'implémentation de système, des systèmes tels que Striim peut être utilisé pour compléter l'architecture (comme indiquédans la migration de bases de données).

Une bonne pratique consiste à évaluer d'autres systèmes de gestion de bases de données afin de déterminer les avantages et les inconvénients d'un système intégrant une réplication ou d'un système nécessitant une technologie de réplication.

Une troisième classe de technologie joue également un rôle dans ce cas. Cette classe fournit des modules complémentaires aux systèmes de base de données existants pour assurer la réplication. MariaDB Galera Cluster en est un exemple. Si le processus d'évaluation le permet, il est recommandé d'évaluer ces systèmes.

Étapes suivantes

• Découvrez les modèles et pratiques hybrides et multicloud.
• Découvrez les modèles pour la connexion des autres fournisseurs de services cloud avec Google Cloud.
• Découvrez les architectures de surveillance et de journalisation pour les déploiements hybrides et multicloud sur Google Cloud.
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.

Contributeurs

Auteur : Alex Cârciu | Architecte de solutions