Modèles d'architecture hybride et multicloud

Cet article constitue la deuxième partie d'une série traitant des déploiements hybrides et multicloud, des modèles d'architecture et des topologies de réseau. Dans cette partie, nous abordons les modèles courants d'architecture hybride et multicloud. L'article décrit les scénarios auxquels ces modèles sont les plus adaptés et présente les bonnes pratiques pour leur mise en œuvre à l'aide de Google Cloud.

La série comprend les éléments suivants :

Chaque entreprise dispose d'un portefeuille unique de charges de travail d'application qui imposent des exigences et des contraintes à l'architecture d'une configuration hybride ou multicloud. Bien que vous deviez concevoir et adapter votre architecture pour répondre à ces contraintes et exigences, vous pouvez aussi vous appuyer sur certains modèles courants.

Les modèles entrent dans deux catégories :

  • Modèles qui reposent sur un déploiement distribué d'applications. Ces modèles ont pour but d'exécuter une application dans l'environnement informatique qui lui convient le mieux, en misant sur les différentes propriétés et caractéristiques des environnements informatiques.

  • Modèles basés sur des déploiements redondants d'applications. Dans ces modèles, vous déployez les mêmes applications dans plusieurs environnements informatiques dans le but d'accroître la capacité ou la résilience.

Modèles de déploiement distribué

Lorsque vous migrez d'un environnement informatique classique vers une configuration hybride ou multicloud, tenez compte des contraintes imposées par les applications existantes. Vous devez aussi tirer parti des fonctionnalités uniques offertes par chaque environnement informatique. Ces modèles distribués visent à établir un équilibre judicieux entre ces deux objectifs.

Hybride par tranche

La plupart des applications appartiennent à l'une de deux catégories : applications d'interface ou applications de backend.

  • Les applications d'interface sont directement exposées aux utilisateurs finaux ou aux appareils. Par conséquent, ces applications sont souvent sensibles aux performances et peuvent être soumises à des mises à jour fréquentes à mesure que de nouvelles fonctionnalités et améliorations sont développées. Comme elles reposent habituellement sur des applications backend pour stocker et gérer les données, les applications d'interface sont souvent sans état ou ne gèrent que de petits volumes de données.

  • Les applications backend sont généralement dédiées à la gestion des données. Pour ce type d'applications, la gestion des données à grands volumes et leur sécurisation posent d'importants défis. Les applications backend ont tendance à être mises à jour moins souvent que les applications d'interface.

Le concept de modèle hybride par tranche consiste à procéder d'abord au déploiement d'applications d'interface existantes dans le cloud public. Dans ce modèle, vous réutilisez des applications backend existantes qui restent dans leur environnement informatique privé. Vous procédez à la migration des applications d'interface au cas par cas.

Le schéma suivant montre un modèle hybride par tranche.

Modèle hybride par tranche.

Au fil du temps, le nombre d'applications que vous déployez dans le cloud augmente, au point que vous pourriez également envisager de transférer les applications backend dans le cloud public.

Avantages

Le fait de se concentrer d'abord sur les applications d'interface présente plusieurs avantages :

  • Les applications d'interface dépendent des backends et parfois d'autres interfaces, mais les backends ne dépendent jamais des interfaces. Par conséquent, l'isolement et la migration d'applications d'interface ont tendance à être moins complexes que la migration d'applications backend, qui peuvent avoir des dépendances complexes.

  • Étant donné que les applications d'interface sont souvent sans état ou qu'elles ne gèrent pas les données elles-mêmes, elles ont tendance à être plus faciles à migrer.

Le déploiement d'applications d'interface existantes ou nouvellement développées dans le cloud public présente plusieurs avantages clés :

  • De nombreuses applications d'interface sont soumises à des modifications fréquentes. Lorsque ces applications sont exécutées dans le cloud public, la configuration d'un processus d'intégration continue/de déploiement continu (CI/CD), que vous pouvez utiliser pour déployer les mises à jour de manière efficace et automatisée, est simplifiée.

  • Les interfaces sensibles aux performances et les interfaces soumises à des modifications fréquentes peuvent grandement bénéficier des fonctionnalités d'équilibrage de charge, de déploiement multirégional et d'autoscaling offertes par un déploiement dans le cloud.

  • Qu'elles mettent en œuvre des interfaces utilisateur ou des API, ou qu'elles gèrent l'ingestion de données IoT (Internet des objets), les applications d'interface peuvent bénéficier des fonctionnalités des services cloud comme Firebase, Cloud CDN ou Cloud IoT.

Si vos backends gèrent des données soumises à des restrictions réglementaires ou juridictionnelles, vous souhaiterez probablement les conserver dans un environnement informatique privé de manière permanente ou au moins jusqu'à ce que vous trouviez un moyen de respecter les restrictions imposées.

Vous pouvez également appliquer le modèle hybride par tranche dans l'ordre inverse, bien que cela soit moins courant, en déployant des backends dans le cloud tout en conservant les interfaces dans des environnements informatiques privés. Cette approche est particulièrement adaptée à une interface lourde et monolithique. Dans ce cas, il pourrait être plus facile d'extraire les fonctionnalités de backend par itération et de déployer ces nouveaux backends dans le cloud.

Bonnes pratiques

Lorsque vous appliquez le modèle hybride par tranche, tenez compte des pratiques suivantes :

  • Utilisez une topologie de sortie contrôlée ou maillée. Comme la plupart des interactions utilisateur impliquent des systèmes connectés à travers plusieurs environnements informatiques, une connectivité rapide et à faible latence entre ces systèmes est importante. Il est donc crucial de concevoir des systèmes offrant une haute disponibilité, une faible latence et des débits appropriés.

  • Pour minimiser la latence des communications entre les environnements, choisissez une région GCP et un emplacement d'interconnexion géographiquement proches de votre environnement informatique privé.

  • Dans une configuration hybride par tranche, vous avez généralement de plus grands volumes de données entrant dans Google Cloud (entrée) que de volumes sortant de l'environnement Google Cloud en direction de l'environnement informatique privé (sortie). Néanmoins, sachez que le trafic quittant Google Cloud est soumis à des frais de sortie. L’utilisation d’interconnexions dédiées ou d'appairages directs peut vous aider à réduire ces frais.

  • Assurez-vous que la communication entre les environnements est unidirectionnelle. Les applications d'interface exécutées dans le cloud public sont autorisées à communiquer avec les backends exécutés dans des environnements informatiques privés, mais pas l'inverse.

  • Les données échangées entre les environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en utilisant des tunnels de réseau privé virtuel (VPN), le protocole TLS (Transport Layer Security) ou les deux.

  • Nous vous recommandons de déployer une passerelle API en tant que façade pour les services backend existants, en particulier lorsque les protocoles, les API et les mécanismes d'authentification sont incohérents entre les différents backends. En plus de servir de couche d'unification, une passerelle API peut servir de goulot d'étranglement. Avec cette passerelle, vous pouvez mettre en place des mesures de sécurité et d'audit supplémentaires qui s'appliquent à toutes les communications entre environnements.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

Pour les charges de travail individuelles, tenez compte de ces bonnes pratiques supplémentaires :

  • Bien que l'accent soit mis sur les applications d'interface dans ce modèle, n'oubliez pas pour autant la nécessité de moderniser les applications backend. Si le rythme de développement des backends est nettement plus lent que celui des interfaces, cette différence peut entraîner une complexité supplémentaire dans les projets.

  • Pour permettre les migrations de type "transformer et déplacer", utilisez Kubernetes en tant que couche d'exécution commune entre Google Cloud et les environnements informatiques privés. Avec Kubernetes, vous pouvez moderniser une charge de travail et procéder à la migration vers Google Cloud à différents moments, ce qui peut être crucial lorsqu'une charge de travail dépend fortement d'une autre et ne peut pas être migrée individuellement.

  • Évitez qu'une communication bidirectionnelle soit requise entre les environnements. Pour cela, envisagez également de déployer tout système CI/CD dans le cloud public.

  • Dans un scénario hybride par tranche, utilisez des outils et processus CI/CD cohérents dans tous les environnements pour accroître l'efficacité opérationnelle. Cette pratique n'est pas obligatoire.

  • Lorsque vous exécutez des charges de travail d'interface avec Kubernetes, utilisez des services sans sélecteur pour rendre détectables tous les services ou passerelles d'API exécutés dans l'environnement informatique privé. Grâce à des domaines Kubernetes simulés, vous pouvez procéder à une intégration avec des systèmes de découverte de services externes basés sur DNS, tels que Consul.

Multicloud partitionné

Le modèle multicloud partitionné associe plusieurs environnements de cloud public, exploités par différents fournisseurs, de manière à vous donner la flexibilité de déployer une application dans un environnement informatique optimal. Le schéma suivant illustre un modèle multicloud partitionné classique.

Modèle multicloud partitionné.

Vous pouvez conserver la possibilité de déplacer les charges de travail d'un environnement cloud public à un autre selon les besoins. Dans ce cas, la portabilité des charges de travail devient une exigence clé. Lorsque vous déployez des charges de travail dans plusieurs environnements informatiques et que vous souhaitez conserver la possibilité de les déplacer, vous devez éliminer les différences qui existent entre les environnements.

Google Cloud fournit un ensemble complet de services vous permettant de déployer vos charges de travail de différentes manières. Néanmoins, dans certaines situations, il pourrait être judicieux de combiner Google Cloud avec un autre fournisseur cloud et de partitionner les charges de travail dans différents environnements cloud. Voici quelques exemples :

  • Pour éviter de dépendre d'un seul fournisseur, vous répartissez vos applications entre plusieurs fournisseurs cloud.

  • Pour des raisons réglementaires, vous fournissez des services à un certain segment de votre base d'utilisateurs et diffusez des données depuis un pays où Google Cloud n'est pas encore présent.

  • Vous déployez des applications auprès de plusieurs fournisseurs cloud, d'une manière qui vous permet de choisir parmi les meilleurs services offerts par les différents fournisseurs.

Avantages

Voici quelques avantages clés du modèle multicloud partitionné :

  • Vous évitez toute dépendance vis-à-vis d'un fournisseur. Ce modèle permet de réduire les risques stratégiques et vous offre la possibilité de modifier votre plan ou votre partenariat ultérieurement.

  • Lorsque vous conservez la portabilité des charges de travail, vous pouvez optimiser vos opérations en déplaçant les charges de travail entre différents environnements informatiques.

Bonnes pratiques

  • Comparez les avantages stratégiques d'une configuration multicloud partitionnée et la complexité supplémentaire qu'elle apporte. Parvenir à une portabilité des charges de travail et à une cohérence des outils entre plusieurs environnements cloud demande plus de travail en termes de développement, de tests et d'opérations.

  • N'utilisez un environnement multicloud que pour les charges de travail critiques ou si, pour des raisons juridiques ou réglementaires, un environnement de cloud public ne peut pas accepter les charges de travail à lui seul.

  • Minimisez les dépendances entre les systèmes exécutés dans différents environnements de cloud public, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances et réduire la disponibilité globale.

  • Pour éliminer les différences entre les environnements, envisagez d'utiliser des conteneurs et Kubernetes.

  • Assurez-vous que les processus CI/CD et les outils de déploiement et de surveillance sont cohérents sur l'ensemble des environnements de cloud.

  • Utilisez la topologie maillée ou contrôlée.

  • Les données échangées entre différents environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées par le biais de tunnels VPN, du protocole TLS ou des deux.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

  • Lorsque vous vous servez de Kubernetes, pensez à utiliser ExternalDNS pour rendre les services détectables par nom DNS dans les environnements informatiques.

  • Bien que vous puissiez utiliser les équilibreurs de charge Anycast Google Cloud basés sur IP pour équilibrer les requêtes entre plusieurs régions Google Cloud, ils ne permettent pas de répartir les requêtes d'utilisateurs entre plusieurs clouds. Pour cela, vous devez utiliser l'interrogation à répétition alternée ou Geo DNS. Par exemple, vous pouvez utiliser NS1, Oracle® ou Akamai.

Analyse hybride et multicloud

Dans les systèmes d'entreprise, la plupart des charges de travail appartiennent aux catégories suivantes :

  • Les charges de travail transactionnelles incluent des applications interactives telles que des applications de vente, de traitement financier, de planification des ressources d'entreprise ou de communication.

  • Les charges de travail analytiques incluent des applications qui transforment, analysent, affinent ou visualisent des données pour faciliter les processus de prise de décision.

Bien que les systèmes analytiques obtiennent leurs données à partir de systèmes transactionnels en interrogeant des API ou en accédant à des bases de données, dans la plupart des entreprises, les systèmes analytiques et transactionnels ont tendance à être séparés et faiblement couplés. Le concept de modèle analytique hybride et multicloud consiste à miser sur cette division préexistante en exécutant les deux types de charges de travail dans deuxenvironnements informatiques différents. Les données brutes sont d'abord extraites des charges de travail exécutées dans l'environnement informatique privé, puis chargées dans Google Cloud, où elles sont utilisées à des fins de traitement analytique. Certains résultats peuvent ensuite être renvoyés aux systèmes transactionnels.

Modèle analytique hybride et multicloud.

Avantages

L'exécution de charges de travail analytiques dans le cloud présente plusieurs avantages essentiels :

  • Les charges de travail analytiques doivent souvent traiter des quantités importantes de données et peuvent être exécutées en rafale. Elles sont donc particulièrement bien adaptées au déploiement dans un environnement de cloud public. En procédant au scaling des ressources de calcul de manière dynamique, vous pouvez traiter rapidement des ensembles de données volumineux tout en évitant les investissements initiaux et tout surprovisionnement de matériel informatique.

  • Google Cloud fournit un ensemble complet de services permettant de gérer les données tout au long de leur cycle de vie, de l'acquisition initiale à la visualisation finale, en passant par le traitement et l'analyse.

  • Cloud Storage est parfaitement adapté à la construction d'un lac de données.

  • Le trafic entrant (transfert de données de l'environnement informatique privé vers Google Cloud) est gratuit.

Bonnes pratiques

Pour mettre en œuvre le modèle d'analyse hybride/multicloud, tenez compte des bonnes pratiques suivantes :

  • Utilisez la topologie de transfert pour permettre l'ingestion de données. Si les résultats analytiques doivent être renvoyés aux systèmes transactionnels, combinez les topologies de transfert et de sortie contrôlée.

  • Servez-vous des files d'attente Pub/Sub ou des buckets Cloud Storage pour transférer des données à Google Cloud à partir de systèmes transactionnels exécutés dans votre environnement informatique privé. Ces files d'attente ou buckets peuvent ensuite servir de sources pour les pipelines de traitement de données et les charges de travail.

  • Lorsque vous avez des charges de travail Hadoop ou Spark existantes, il peut être utile de migrer les tâches vers Dataproc et de migrer les données HDFS existantes vers Cloud Storage.

  • Lorsque vous effectuez un premier transfert de données de votre environnement informatique privé vers Google Cloud, choisissez la méthode de transfert la mieux adaptée à la taille de votre ensemble de données et à la bande passante disponible.

  • Utilisez des outils et des processus cohérents dans tous les environnements. Dans un scénario d'analyse hybride, cette pratique peut contribuer à accroître l'efficacité opérationnelle, bien qu'elle ne constitue pas une condition préalable.

Hybride de périphérie

Pour exécuter des charges de travail dans le cloud, les clients doivent disposer d'une connectivité Internet rapide et fiable. Compte tenu des réseaux actuels, cette exigence pose rarement un défi pour les projets d'adoption du cloud. Il existe cependant des scénarios dans lesquels vous ne pouvez pas compter sur une connectivité continue :

  • Les navires et autres véhicules peuvent n'être connectés que de manière intermittente ou n'avoir accès qu'aux liaisons satellite à latence élevée.

  • Les usines ou les centrales peuvent être connectées à Internet. Ces installations peuvent cependant avoir des exigences de fiabilité dépassant les garanties de disponibilité offertes par la liaison.

  • Les magasins ou les supermarchés peuvent n'être connectés que de manière occasionnelle ou utiliser des liens n'offrant pas la fiabilité ou le débit nécessaires pour traiter des transactions critiques.

Le modèle hybride de périphérie résout ces problèmes en exécutant les charges de travail urgentes et stratégiques localement, à la périphérie du réseau, tout en utilisant le cloud pour tous les autres types de charges de travail. Dans une configuration hybride de périphérie, le lien Internet est un composant non critique utilisé à des fins de gestion et de synchronisation ou de chargement de données, souvent de manière asynchrone, mais n'intervenant pas dans des transactions urgentes ou critiques.

Modèle hybride de périphérie.

Avantages

Le fait d'exécuter certaines charges de travail à la périphérie et d'autres dans le cloud offre plusieurs avantages :

  • L'exécution de charges de travail urgentes et stratégiques à la périphérie permet de garantir une faible latence et une autosuffisance. Si la connexion Internet échoue ou est temporairement indisponible, vous pouvez toujours exécuter toutes les transactions importantes. Dans le même temps, vous pouvez profiter de l'utilisation du cloud pour une part importante de votre charge de travail globale.

  • Vous pouvez réutiliser des investissements informatiques et de stockage existants.

  • Au fil du temps, vous pouvez réduire progressivement la part de charges de travail exécutées en périphérie, soit en retravaillant certaines applications, soit en dotant certains emplacements de périphérie de liens Internet plus fiables.

  • Le trafic entrant (transfert de données de la périphérie vers Google Cloud) est gratuit.

Bonnes pratiques

Tenez compte des recommandations suivantes lorsque vous mettez en œuvre le modèle hybride de périphérie :

  • Si la communication est unidirectionnelle, utilisez la topologie d'entrée contrôlée. Dans le cas d'une communication bidirectionnelle, tenez compte des topologies d'entrée et de sortie contrôlées.

  • Minimisez les dépendances entre les systèmes exécutés en périphérie et ceux exécutés dans l'environnement cloud. Chaque dépendance peut compromettre les avantages en termes de fiabilité et de latence d'une configuration hybride en périphérie.

  • Pour gérer et exploiter efficacement plusieurs emplacements périphériques, établissez un plan de contrôle centralisé dans le cloud.

  • Assurez-vous que les processus CI/CD ainsi que les outils de déploiement et de surveillance sont cohérents dans les environnements cloud et périphériques.

  • Songez à utiliser des conteneurs et Kubernetes pour éliminer les différences entre les divers emplacements périphériques, ainsi qu'entre les emplacements périphériques et le cloud. Étant donné que Kubernetes fournit une couche d'exécution commune, vous pouvez développer, exécuter et utiliser des charges de travail de manière cohérente dans tous les environnements informatiques et déplacer des charges de travail entre la périphérie et le cloud.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

  • Les données échangées entre environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en utilisant des tunnels VPN, le protocole TLS ou les deux.

Modèles de déploiement redondant

Les sections suivantes explorent les modèles courants qui reposent sur un déploiement redondant d'applications dans plusieurs environnements informatiques. Dans ces modèles, vous déployez les mêmes applications dans plusieurs environnements informatiques dans le but d'accroître la capacité ou la résilience.

Environnement hybride

Le concept de modèle d'environnement hybride consiste à conserver l'environnement de production d'une charge de travail dans le centre de données existant, tout en utilisant le cloud public pour d'autres environnements non productifs.

En évaluant les charges de travail à migrer, vous remarquerez peut-être des cas où l'exécution d'une application spécifique dans le cloud public pose certains défis :

  • Des contraintes juridictionnelles ou réglementaires peuvent nécessiter que vous conserviez des données dans un pays spécifique.
  • Des conditions de licence tierces peuvent vous empêcher d'utiliser certains logiciels dans un environnement cloud.
  • Une application peut nécessiter un accès à des périphériques matériels disponibles seulement en local, comme lors du déplacement de charges de travail.

Dans de tels cas, vous devez tenir compte non seulement de l'environnement de production, mais également de tous les environnements impliqués dans le cycle de vie d'une application, y compris les systèmes de développement, de test et de préproduction. Les restrictions pouvant rendre difficile la migration vers le cloud s'appliquent souvent à l'environnement de production et à ses données, mais pas aux autres environnements.

Le schéma suivant illustre un modèle d'environnement hybride typique.

Modèle d'environnement hybride.

Le fait de faire fonctionner des systèmes de développement et de test dans des environnements différents de ceux des systèmes de production peut sembler risqué et aller à l'encontre des bonnes pratiques existantes ou des tentatives visant à minimiser les différences entre de tels environnements. Bien que ces préoccupations soient justifiées, elles ne s'appliquent pas si vous faites une distinction entre les étapes des processus de développement et de test :

  • Même si les processus de développement, de test et de déploiement diffèrent d'une application à l'autre, ils impliquent généralement des variantes des étapes suivantes :

    • Développement : créer une version finale
    • Tests fonctionnels ou tests d'acceptation utilisateur : vérifier que la version finale répond aux exigences fonctionnelles
    • Tests de performance et de fiabilité : vérifier que la version finale répond aux exigences non fonctionnelles
    • Tests de préproduction ou de déploiement : vérifier que la procédure de déploiement fonctionne
    • Production

L'exécution de plusieurs de ces étapes dans un seul environnement est rarement pratique. Chaque étape nécessite donc généralement un ou plusieurs environnements dédiés.

Pour que les résultats de test soient significatifs et s'appliquent au déploiement de production, les environnements que vous utilisez tout au long du cycle de vie d'une application doivent tous respecter les règles suivantes, dans la mesure du possible :

  • Tous les environnements sont équivalents du point de vue fonctionnel. En d'autres termes, l'architecture, les API ainsi que les versions des systèmes d'exploitation et des bibliothèques sont équivalentes, et les systèmes se comportent de la même manière dans tous les environnements. Cette équivalence permet d'éviter des situations où les applications fonctionneraient dans un environnement mais échoueraient dans un autre, ou dans lesquelles les défaillances ne seraient pas reproductibles.

  • Les environnements utilisés pour les tests de performance et de fiabilité, la préproduction et la production sont équivalents d'un point de vue non fonctionnel. Autrement dit, leurs performances, leur échelle et leur configuration, ainsi que la manière dont ils sont utilisés et gérés, sont identiques ou ne diffèrent que de manière peu significative. Les tests de performance et de préproduction deviendraient autrement dénués de sens.

Il est essentiel que les environnements utilisés pour le développement et les tests fonctionnels diffèrent des autres environnements du point de vue non fonctionnel. Cette situation s'accorde bien avec le modèle d'environnement hybride :

  • Parvenez à une équivalence fonctionnelle entre tous les environnements en utilisant Kubernetes en tant que couche d'exécution commune pour garantir la portabilité des charges de travail et éliminer les différences entre les environnements informatiques.

  • Exécutez les environnements des tests de production, préproduction, performance et fiabilité dans l'environnement informatique privé, en veillant à avoir une équivalence des points de vue fonctionnel et non fonctionnel.

  • Exécutez les environnements de développement et de tests fonctionnels dans le cloud public. Ces environnements sont équivalents aux environnements restants du point de vue fonctionnel, mais peuvent différer les uns des autres sur certains aspects non fonctionnels, tels que les performances.

Avantages

L'exécution de charges de travail de développement et de tests fonctionnels dans le cloud public présente plusieurs avantages :

  • Vous pouvez automatiquement créer et détruire des environnements selon vos besoins. Par exemple, vous pouvez configurer un environnement complet pour chaque requête commit ou pull, autoriser l'exécution des tests, puis le détruire.

  • Les environnements de développement et de test sont souvent utilisés de manière intermittente. Vous pouvez réduire vos coûts en arrêtant les instances de machine virtuelle (VM) pendant les périodes d'inactivité ou en ne provisionnant des environnements qu'à la demande.

  • En exécutant ces environnements dans le cloud public, vous pourrez vous familiariser avec le cloud et les outils associés, et les utiliser avec une confiance accrue, ce qui pourrait faciliter la migration d'autres charges de travail.

Bonnes pratiques

Pour mettre correctement en œuvre le modèle d'environnement, tenez compte des recommandations suivantes :

  • Utilisez la topologie en miroir pour empêcher les systèmes de différents environnements de communiquer entre eux. Comme les systèmes n'ont pas besoin de communiquer entre différents environnements, vous n'avez pas besoin d'établir une identité commune.

  • Utilisez à la fois des conteneurs et Kubernetes pour rendre les charges de travail portables et pour éliminer les différences qui existent entre les environnements, mais tenez compte des limites en termes de portabilité des charges de travail.

  • Assurez-vous que les processus CI/CD sont cohérents dans tous les environnements informatiques et que le même ensemble de fichiers binaires, de paquets ou de conteneurs est déployé dans les différents environnements.

  • Pour déployer, configurer et utiliser des charges de travail, mettez en place une chaîne d'outils commune qui fonctionne dans plusieurs environnements informatiques. L'utilisation de Kubernetes vous donnera cette cohérence, à l'exception de quelques différences mineures dans la manière dont vous vous connectez ou vous vous authentifiez auprès des clusters exécutés dans différents environnements informatiques.

  • Avec Kubernetes, utilisez un système de CI tel que Jenkins pour mettre en œuvre un pipeline de déploiement qui assure le déploiement sur les clusters et fonctionne dans différents environnements. Vous pouvez également exécuter Jenkins lui-même sur Google Kubernetes Engine (GKE).

  • Utilisez les mêmes outils pour la journalisation et la surveillance dans les environnements Google Cloud et cloud existants. Songez à utiliser des systèmes de surveillance Open Source tels que Prometheus. Si différentes équipes gèrent les charges de travail de test et de production, il peut être acceptable dans ce cas d'utiliser des outils distincts, même si le fait d'utiliser les mêmes outils pourrait entraîner une simplicité accrue et réduire le besoin de formation.

  • Lorsque vous choisissez des services de base de données, de stockage et de messagerie, utilisez des produits ayant un équivalent géré sur Google Cloud. Le recours à des services gérés permet de réduire les tâches administratives liées à la maintenance des environnements de développement et de test.

Le tableau suivant présente les produits Google Cloud compatibles avec les produits OSS courants.

Produit OSS Compatible avec les produits Google Cloud
Apache HBase Cloud Bigtable
Apache Beam Dataflow
Apache Hadoop Dataproc
MySQL, PostgreSQL Cloud SQL
Redis Memorystore
Système de fichiers réseau (NFS) Filestore
JMS, Kafka Pub/Sub

Continuité d'activité hybride et multicloud

Idéalement, les systèmes critiques sont configurés de manière à être résilients en cas de sinistre. En répliquant les systèmes et les données sur plusieurs régions géographiques et en évitant les points de défaillance uniques, vous pouvez minimiser les risques de catastrophe naturelle affectant les infrastructures locales. Cependant, cette approche ne résout pas le risque de pannes causées par une erreur humaine ou des défauts logiciels. Par conséquent, il est essentiel de disposer également d'un plan de reprise après sinistre (DR) vous permettant de restaurer vos systèmes dans des délais acceptables et avec une perte de données minimale si d'autres types de sinistres se produisent.

Un élément clé de la planification de reprise après sinistre consiste à sauvegarder fréquemment les données dans des emplacements géographiques différents afin de réduire l'objectif de point de reprise (RPO, Recovery Point Objective). Par ailleurs, le maintien de systèmes de secours à froid, tièdes ou à chaud dans un deuxième emplacement peut aider à réduire l'objectif de délai de reprise (RTO, Recovery Time Objective).

Lorsque vous exécutez des systèmes critiques dans un centre de données central, une solution pour la reprise après sinistre consiste à gérer les systèmes de secours dans un deuxième centre de données situé dans une autre région. Toutefois, une approche plus économique consiste à utiliser un environnement informatique basé sur un cloud public à des fins de basculement, ce qui correspond au concept de modèle de continuité d'activité hybride.

Modèle de continuité d'activité hybride.

Une variante moins courante (et rarement requise) de ce modèle est le modèle de continuité d'activité multicloud, dans lequel l'environnement de production utilise un fournisseur cloud et l'environnement de reprise après sinistre utilise un fournisseur cloud différent. En déployant des copies de charges de travail auprès de plusieurs fournisseurs cloud, vous pouvez obtenir une disponibilité supérieure à celle proposée par un déploiement multirégion.

Avantages

L'utilisation du cloud public pour la continuité des activités offre de nombreux avantages :

  • Comme Google Cloud propose un choix de plus d'une dizaine de régions, vous pouvez sauvegarder ou répliquer des données sur un site différent du même continent, ou même sur un site d'un autre continent.

  • Les instances de VM arrêtées n'engendrent que des coûts de stockage et sont nettement moins chères que les instances de VM en cours d'exécution. Vous pouvez ainsi réduire les coûts liés à la maintenance des systèmes de secours manuels.

  • Le modèle de tarification à l'utilisation de Google Cloud garantit que vous ne payez que pour le stockage et la capacité de calcul que vous utilisez réellement, et vous pouvez agrandir ou réduire votre environnement de reprise après sinistre (DR) selon vos besoins.

Bonnes pratiques

Lorsque vous utilisez le modèle de continuité d'activité, tenez compte des bonnes pratiques suivantes :

  • Créez un plan de reprise après sinistre qui documente votre infrastructure, ainsi que les procédures de basculement et de récupération.

  • En fonction de votre RPO et de votre RTO, décidez si la sauvegarde des données sur Google Cloud est suffisante ou si vous devez gérer des systèmes de secours à froid, tièdes ou à chaud. Reportez-vous au Guide de planification de la reprise après sinistre pour connaître les scénarios courants et obtenir des conseils pour les mettre en œuvre dans Google Cloud.

  • Lorsque vous n'effectuez que des sauvegardes de données, utilisez la topologie de transfert. Sinon, envisagez la topologie en miroir.

  • Réduisez les dépendances entre les systèmes exécutés dans des environnements différents, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances et réduire la disponibilité globale.

  • Si vous répliquez des données de manière bidirectionnelle sur plusieurs environnements, vous pouvez être exposé au problème de Split-Brain. Si la communication entre les deux environnements est interrompue, les systèmes peuvent en effet conclure chacun de leur côté que l'autre environnement n'est plus disponible. Ils peuvent également en déduire qu'ils disposent d'un accès exclusif aux données, ce qui conduit à terme à des modifications contradictoires. Un moyen d'éviter ce fractionnement consiste à ajouter un troisième environnement informatique. Cette approche permet en effet à un système qui s'appuie sur la réplication de données de vérifier la présence d'un quorum avant de conclure que la modification des données ne présente aucun risque. Vous pouvez également autoriser le rapprochement des modifications de données en conflit après la restauration de la connectivité.

  • Assurez-vous que les systèmes CI/CD et les dépôts d'artefacts ne se transforment pas en point de défaillance unique. Lorsqu'un environnement est indisponible, vous devez toujours pouvoir déployer de nouvelles versions ou appliquer des modifications de configuration.

  • Les données échangées entre différents environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées par le biais de tunnels VPN, du protocole TLS ou des deux.

  • Lorsque vous utilisez des systèmes de secours, assurez-vous que les charges de travail sont portables afin que les systèmes restent cohérents dans tous les environnements. Songez à utiliser des conteneurs et Kubernetes.

  • Intégrez le déploiement de systèmes de secours dans votre processus CI/CD. Cette intégration permet de garantir la cohérence des versions et des configurations d'applications dans tous les environnements.

  • Lorsque vous utilisez des systèmes de secours automatiques, utilisez des équilibreurs de charge pour créer un basculement automatique, mais gardez à l'esprit que les équilibreurs de charge peuvent eux aussi échouer. Par précaution, configurez votre DNS de façon à pouvoir rediriger les utilisateurs vers des systèmes de secours en cas de sinistre. Utilisez une valeur TTL relativement courte pour vous assurer que les modifications DNS sont propagées rapidement, et utilisez la garantie de disponibilité à 100 % offerte par Cloud DNS dans le cadre d'un contrat de niveau de service.

  • Pour la reprise après sinistre, envisagez des solutions partenaires telles que Actifio et Commvault.

Utilisation temporaire du cloud

Les applications Internet, en particulier celles qui ciblent les utilisateurs, peuvent connaître des fluctuations d'utilisation extrêmes. Bien que la plupart des applications d'entreprise ne soient pas confrontées à ce problème, de nombreuses entreprises doivent faire face à un type de charges de travail intensives différent : les tâches par lots ou CI/CD.

Bien que vous puissiez gérer des charges de travail intensives dans un environnement informatique classique basé sur un centre de données en approvisionnant des ressources en quantité excessive, cette approche n'est pas rentable. Avec les tâches par lots, vous pouvez optimiser leur utilisation en différant leur exécution sur des périodes plus longues, bien qu'il ne soit pas pratique de retarder les tâches si elles sont urgentes.

Le concept de modèle d'utilisation temporaire du cloud consiste à utiliser un environnement informatique privé pour la charge de base et à se connecter temporairement au cloud en cas de besoins de capacité accrus.

Modèle d'utilisation temporaire du cloud.

La portabilité des charges de travail est une condition essentielle pour les scénarios d'utilisation temporaire du cloud. Lorsque vous autorisez le déploiement de charges de travail dans plusieurs environnements, vous devez supprimer les différences qui existent entre ces environnements.

Le modèle d'utilisation temporaire du cloud s'applique aussi bien aux charges de travail interactives et par lots. Toutefois, lorsque vous traitez des charges de travail interactives, vous devez déterminer comment répartir les requêtes entre les différents environnements :

  • Vous pouvez acheminer les requêtes entrantes des utilisateurs vers un équilibreur de charge exécuté dans le centre de données existant, puis faire en sorte que l'équilibreur de charge répartisse les requêtes entre les ressources locales et cloud. Cette approche nécessite que l'équilibreur de charge ou un autre système en cours d'exécution dans le centre de données existant procède également au suivi des ressources allouées dans le cloud et qu'il initie une augmentation ou une diminution automatique des ressources.

    Acheminer les requêtes entrantes des utilisateurs vers un équilibreur de charge exécuté dans le centre de données existant, puis faire en sorte que l'équilibreur de charge répartisse les requêtes entre les ressources locales et cloud.

    D'un côté, cette approche vous permet de mettre toutes les ressources cloud hors service en période de faible activité. D'un autre, la mise en place de mécanismes capables de procéder au suivi des ressources pourrait aller au-delà des capacités des solutions d'équilibrage de charge disponibles dans le commerce et augmenter in fine la complexité globale.

  • Sinon, vous pouvez commencer par acheminer les requêtes vers Google Cloud pour les répartir ensuite entre les différents environnements. Étant donné que les équilibreurs de charge Google Cloud ne prennent en charge l'équilibrage et l'autoscaling qu'entre les ressources Google Cloud, vous devez associer un équilibreur de charge Google Cloud à des mécanismes d'équilibrage de charge personnalisés supplémentaires pour faciliter la distribution des requêtes. Encore une fois, cette approche crée un surcroît de complexité.

    L'équilibrage des charges à l'aide d'un DNS à répétition alternée n'est pas pratique si vous avez l'intention de fermer toutes les ressources dans Google Cloud pendant les périodes de faible demande. Comme les mises à jour DNS ont tendance à se propager lentement, l'utilisation de DNS pour l'équilibrage de la charge comporte le risque que les utilisateurs soient routés vers Google Cloud lorsqu'aucune ressource n'est disponible pour traiter leurs requêtes.

Face à ces défis, l'utilisation temporaire du cloud se prête généralement mieux aux charges de travail par lots qu'aux charges de travail interactives.

Avantages

Les principaux avantages de ce modèle d'architecture sont les suivants :

  • L'utilisation temporaire du cloud vous permet de réutiliser des centres de données et environnements informatiques privés existants. Cette réutilisation peut être permanente ou temporaire jusqu'à ce que le remplacement des équipements existants soit nécessaire. Vous pourrez alors envisager une migration complète vers le cloud.

  • Vous pourrez peut-être augmenter l'utilisation et la rentabilité de vos environnements informatiques privés, car vous n'aurez plus besoin de conserver une capacité excédentaire pour répondre aux pics de requêtes.

  • L'utilisation temporaire du cloud permet d'exécuter les tâches par lots en temps voulu sans qu'il soit nécessaire de surprovisionner des ressources de calcul.

Bonnes pratiques

Lorsque vous mettez en œuvre le modèle d'utilisation temporaire du cloud, tenez compte des bonnes pratiques suivantes :

  • Utilisez la topologie maillée pour vous assurer que les charges de travail exécutées dans le cloud peuvent accéder aux ressources de la même manière que les charges de travail exécutées dans d'autres environnements informatiques. Si les charges de travail le permettent, n'autorisez l'accès que du cloud vers l'autre environnement informatique, et non l'inverse.

  • Pour minimiser la latence des communications entre les environnements, choisissez une région Google Cloud et un emplacement d'interconnexion géographiquement proches de votre environnement informatique privé.

  • Lorsque vous utilisez le modèle d'utilisation temporaire du cloud pour des charges de travail par lots seulement, réduisez la surface d'attaque de sécurité en gardant toutes les ressources Google Cloud privées et en interdisant tout accès direct à ces ressources depuis Internet.

  • Pour les tâches qui ne durent pas plus de 24 heures et ne sont pas urgentes, privilégiez les instances de VM préemptives, qui reviennent nettement moins cher que les instances de VM classiques. Notez qu'en ce cas, vous devez respecter une condition préalable : si la VM sur laquelle une tâche est en cours d'exécution est préemptée, le système doit pouvoir la redémarrer automatiquement.

  • Assurez la portabilité des charges de travail à l'aide de conteneurs. Pour les charges de travail par lots nécessitant beaucoup de ressources, vous pouvez déployer directement ces conteneurs sur des VM Compute Engine et utiliser un groupe d'instances géré pour adapter le nombre de VM. Dans le cas de charges de travail interactives ou de charges de travail diverses nécessitant moins de ressources, vous pouvez également vous servir de Google Kubernetes Engine (GKE) en combinaison avec l'autoscaling de clusters pour déployer ces conteneurs. Notez cependant que GKE nécessite au moins un nœud par zone pour être exécuté en permanence.

  • Surveillez tout trafic envoyé depuis Google Cloud vers un environnement informatique différent. Ce trafic est soumis à des frais de sortie.

  • Les données échangées entre différents environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées par le biais de tunnels VPN, du protocole TLS ou des deux.

  • Pour les charges de travail nécessitant beaucoup de stockage, envisagez l'intégration à une solution de stockage hybride comme Cloudian, ClearSky, Avere vFXT, Egnyte ou SwiftStack.

  • Utilisez le modèle d'utilisation temporaire du cloud pour mettre à l'échelle un système CI de manière dynamique. Si vous vous servez de Jenkins, vous pouvez gérer les instances Jenkins sur Compute Engine et procéder à leur autoscaling à l'aide du plug-in Google Compute Engine.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

Étapes suivantes