Faciliter votre migration avec le déploiement du maillage de services Istio

Last reviewed 2023-11-02 UTC

Ce document présente une architecture utilisant un maillage de services Istio et qui doit être migrée depuis un ancien environnement, tel qu'un centre de données sur site exécutant des applications sur des machines virtuelles, vers Google Kubernetes Engine (GKE). L'utilisation d'un maillage de services peut réduire la complexité de la migration et de la refactorisation, car celui-ci dissocie les fonctions réseau des fonctions des services.

Ce document explique la logique de la migration et en décrit les phases générales. Vous pouvez utiliser cette architecture pour effectuer une migration en une seule opération (parfois appelée migration big-bang) ou une migration progressive, fonctionnalité par fonctionnalité. Le document de déploiement associé vous guide tout au long d'un exemple de migration.

Cette architecture et son guide de déploiement sont destinés aux professionnels de l'informatique qui gèrent une infrastructure complexe qu'ils souhaitent migrer et moderniser progressivement, tout en réduisant le plus possible les aspects suivants :

  • Temps d'arrêt
  • Durée de refactorisation
  • Complexité opérationnelle de votre réseau

Les concepts expliqués s'appliquent à tout type de cloud. Par conséquent, le document part du principe que vous maîtrisez les technologies cloud, les conteneurs et les microservices.

Comme indiqué dans la page Migrer vers Google Cloud : premiers pas, il existe plusieurs modèles de migration vers le cloud. L'architecture présentée dans ce document utilise un modèle de refactorisation (parfois appelé migration Move and Improve), dans lequel le modèle est appliqué à chaque fonctionnalité de l'application plutôt qu'à l'application dans son ensemble.

Pendant la migration, l'application utilise une architecture hybride au sein de laquelle certaines fonctionnalités sont disponibles dans Google Cloud et d'autres figurent toujours dans l'ancien environnement. Une fois la migration terminée, l'application complète est hébergée sur Google Cloud.

Architecture

Le schéma suivant montre comment utiliser un maillage de services pour acheminer le trafic vers des microservices s'exécutant dans l'environnement source ou vers Google Cloud :

Architecture utilisant un maillage de services pour acheminer le trafic vers des microservices s'exécutant dans l'ancien environnement ou vers Google Cloud.

L'architecture comprend les composants suivants :

  • Un environnement source, dans le cas présent une instance Compute Engine qui héberge l'exemple de charge de travail à migrer. L'environnement source peut également être une ressource sur site, ou être hébergé sur d'autres plates-formes cloud.

  • Un maillage de services, dans le cas présent Istio Gateway, qui associe différents services. Le maillage de services fournit des fonctionnalités réseau de valeur telles que la détection de services, les communications sécurisées, l'équilibrage de charge, la gestion du trafic et l'observabilité.

    Une mise en œuvre classique d'un maillage de services associe chaque service à un proxy qui fournit ces fonctionnalités. Le proxy de service est communément appelé side-car. Le rôle du side-car est d'augmenter et d'améliorer l'application à laquelle il est rattaché, souvent à l'insu de l'application. Dans le guide de déploiement associé, vous utilisez Envoy comme proxy side-car.

  • Une charge de travail contenant une application composée de microservices. Un microservice est un composant autonome conçu pour accueillir une fonctionnalité d'application. Dans cette architecture, l'application est composée de différents microservices, qui sont imperceptibles au niveau des utilisateurs. Un composant qui gère des avis sur des livres est un exemple de microservice.

    Dans le modèle de microservices, l'application est constituée de l'agrégation de plusieurs microservices, chacun ayant un objectif spécifique. Par exemple, un microservice peut gérer les classements de livres par évaluation, tandis qu'un autre gère les avis de lecture. Ces microservices doivent être faiblement couplés et s'interfacer via des API bien définies. Ils peuvent être écrits dans différents langages et frameworks (comme dans les applications multilangages), et présenter des cycles de vie différents.

  • Un conteneur servant à définir plus précisément les limites de chaque microservice. Comme l'environnement cible de cette architecture est orchestré avec Kubernetes, nous vous recommandons de conteneuriser vos microservices à l'aide des outils suivants :

    • Docker permet d'isoler les programmes du niveau de l'espace utilisateur au niveau du système d'exploitation. Cet outil exécute des packages appelés conteneurs.
    • Kubernetes est la solution d'orchestration par excellence pour les charges de travail conteneurisées. Elle fournit des fonctionnalités telles que la détection de services, l'équilibrage de charge, un système d'autoréparation des pods et des nœuds, ainsi qu'un gestionnaire des secrets et de la configuration.
    • GKE est un environnement Kubernetes géré et prêt pour la production, qui est intégré à Google Cloud.

    Pour obtenir des conseils sur la conteneurisation de ces microservices, consultez les bonnes pratiques pour la création de conteneurs, ainsi que les bonnes pratiques pour exploiter des conteneurs.

Procédez comme suit pour effectuer une migration à l'aide d'un maillage de services :

  • Évaluer l'ancien environnement : collectez des informations et établissez un ensemble d'exigences pour l'environnement cible, ainsi qu'une référence pour les tests et la validation.
  • Poser les bases dans l'environnement cible : provisionnez votre environnement cible et appliquez une méthodologie d'infrastructure en tant que code pour rendre votre infrastructure auditable, reproductible et provisionnable automatiquement.
  • Déployer des services et commencer à acheminer le trafic vers l'environnement cible : déployez simultanément toutes les instances de microservices en une seule opération, ou bien effectuez un déploiement progressif pour déployer un microservice à la fois.
  • Arrêter le routage du trafic vers l'ancien environnement : configurez des règles de routage pour ne plus acheminer le trafic que vers les services qui sont exécutés dans l'environnement cible.
  • Supprimer l'ancien environnement : mettez à jour vos enregistrements DNS pour qu'ils pointent vers l'équilibreur de charge que vous avez configuré pendant la phase de provisionnement de l'environnement cible.

Ce document décrit certaines considérations de conception pour ce type de migration, et le guide de déploiement associé décrit dans le détail les étapes à suivre pour finaliser la migration.

Considérations de conception

Cette section fournit des conseils pour vous aider à développer une architecture répondant à vos exigences spécifiques en termes de fiabilité, d'efficacité opérationnelle, de coût et d'optimisation des performances.

Fiabilité

Les sections suivantes décrivent les considérations relatives à la fiabilité de votre migration.

Utiliser une stratégie de migration progressive

Bien que cette architecture puisse être utilisée pour une migration en une seule opération, nous vous recommandons d'adopter une stratégie de migration progressive. Effectuer une migration en une seule opération est un exercice difficile, en raison des défis et des risques inhérents à la migration d'une ou plusieurs applications simultanément. Si vous avez des contraintes de temps et de budget, le fait de vous concentrer sur une migration en une seule opération laisse peu de capacités pour travailler sur les nouvelles fonctionnalités des applications.

En revanche, une migration progressive fonctionnalité par fonctionnalité est plus simple globalement puisque la charge de travail à migrer est réduite : l'encombrement d'une seule fonctionnalité est nettement moins important qu'une application entière. Une migration progressive vous permet de répartir le risque sur des événements de migration de moindre ampleur, plutôt que sur une seule opération aux enjeux élevés. Une migration progressive permet également à l'équipe en charge de planifier, de concevoir et de développer plusieurs stratégies de migration afin de s'adapter à différents types de fonctionnalités.

Pour savoir comment choisir les fonctionnalités à migrer en premier et comment migrer des fonctionnalités avec état, consultez la section Choisir les applications à migrer en premier de la page "Migrer vers Google Cloud : évaluer et découvrir vos charges de travail".

Utiliser une suite de tests de conformité

Pour faciliter votre migration, nous vous recommandons d'utiliser une suite de tests de conformité. Une suite de tests de conformité est une série de tests que vous exécutez sur un environnement pour vérifier s'il répond à un ensemble de conditions spécifiques. Si les conditions sont remplies, alors l'environnement est valide. Vous pouvez ainsi valider la réponse à une demande de test ou vérifier si les dépendances de l'application sont bien installées.

Commencez par une validation manuelle à l'aide des outils de surveillance, de traçage et de visualisation du maillage de services. Vous pouvez ensuite mettre en œuvre la suite de tests et la faire évoluer progressivement, comme suit :

  • Test de charge : l'envoi automatique du trafic de test à l'environnement et l'évaluation des résultats obtenus permettent de faire évoluer la suite de tests de façon progressive.
  • Outil de test de conformité : vous pouvez concevoir et développer une suite de tests à l'aide d'un outil dédié.

Exécutez la suite de tests de conformité sur l'ancien environnement pour disposer de références, ainsi que sur l'environnement cible pendant et après la migration.

Vos suites de tests doivent se concentrer sur les aspects suivants à valider pendant la migration :

  • Provisionnement : provisionnez les ressources dont vous avez besoin dans votre environnement avant de les configurer.
  • Configuration : après avoir provisionné les ressources dans l'environnement, vous devez les configurer en fonction des besoins de votre application. La suite de tests de configuration vous permet d'être certain que l'environnement est prêt à héberger votre application.
  • Logique métier : après avoir validé le provisionnement et la configuration de l'environnement, validez la logique métier de votre application. Par exemple, vous pouvez valider les réponses aux requêtes.

Chef InSpec, RSpec et Serverspec sont des outils permettant de développer des suites de tests de conformité automatiques. Ils fonctionnent sur n'importe quelle plate-forme et sont extensibles, vous permettant ainsi de mettre en œuvre vos propres contrôles, à partir des contrôles intégrés.

Lorsque vous provisionnez votre environnement cible, vous pouvez utiliser la suite de tests de conformité pour le valider. Vous devrez peut-être mettre à jour la suite de tests pour tenir compte des éventuelles différences entre l'ancien environnement et l'environnement cible, par exemple au niveau des ressources matérielles et de la topologie réseau. Gardez à l'esprit que vous passez d'un environnement sur site, dont vous avez le contrôle total, à un environnement cloud public, dans lequel vous n'avez généralement pas accès à l'intégralité de la pile.

Avant d'acheminer le trafic depuis la couche d'équilibrage de charge de l'ancien environnement vers l'environnement cible, nous vous recommandons d'exécuter la suite de tests de conformité concernant la logique métier sur les microservices qui sont exposés par l'environnement cible. La suite de tests peut vous aider à vérifier que les microservices fonctionnent comme prévu. Par exemple, vous pouvez valider les réponses renvoyées par les services exposés par le maillage de services. Vous pouvez conserver la route d'origine comme option de secours au cas où vous devriez annuler les modifications et revenir à l'ancien environnement. En acheminant une petite partie du trafic de production vers des instances de microservices exécutés dans l'environnement cible, vous accumulez progressivement du "capital confiance" envers l'environnement cible, et pouvez augmenter au fil du temps le trafic total.

Interdire les requêtes entre environnements

Au cours de la phase de tests de conformité, nous vous recommandons d'affiner les règles de routage afin d'interdire les requêtes entre environnements. Ainsi, lorsqu'une requête client appelle un environnement, ancien ou cible, cette requête va rester cantonnée à cet environnement. Le fait d'interdire les requêtes entre environnements permet de garantir que les tests valident correctement l'environnement cible. Si vous n'interdisez pas ce genre de requêtes, un test peut signaler à votre insu la réussite de l'environnement source, au lieu de l'environnement cible.

Supprimer l'ancien environnement

Avant de supprimer l'ancien environnement, vérifiez que toutes les conditions suivantes sont remplies :

  • Aucun trafic n'est acheminé vers des instances de microservices s'exécutant dans l'ancien environnement.
  • Aucun trafic ne passe par les interfaces de l'ancien environnement.
  • L'environnement cible a été entièrement validé.

Lorsque ces conditions sont remplies, vous pouvez mettre à jour vos enregistrements DNS pour qu'ils pointent vers l'équilibreur de charge que vous avez configuré pendant la phase de provisionnement de l'environnement cible. Ne supprimez pas l'ancien environnement, sauf si vous êtes sûr que l'environnement cible a été validé. Ne limitez pas la validation à la seule logique métier, mais prenez en compte d'autres conditions non fonctionnelles telles que les performances et l'évolutivité.

Efficacité opérationnelle

Les sections suivantes décrivent les considérations relatives à l'efficacité opérationnelle de votre migration.

Évaluer l'ancien environnement

Avant de concevoir ou de mettre en œuvre un plan de migration, vous devez évaluer l'ancien environnement pour collecter des informations et établir un ensemble d'exigences pour l'environnement cible, ainsi qu'une base de référence pour les tests et la validation. Vous commencez par créer un catalogue de toutes les fonctionnalités de l'application à migrer. Pour chaque fonctionnalité, vous devez être en mesure de répondre à cette série de questions (liste non exhaustive) :

  • Quelles sont les conditions en matière d'environnement d'exécution et de performances ?
  • Existe-t-il des dépendances sur d'autres fonctionnalités ?
  • S'agit-il d'une fonctionnalité stratégique ?
  • Cette fonctionnalité est-elle sans état ou avec état ?
  • Quel est le volume d'opérations de refactorisation exigé pour migrer la fonctionnalité ?
  • Cette fonctionnalité peut-elle tolérer un intervalle de basculement ?

Pour en savoir plus, consultez la page Migrer vers Google Cloud : évaluer et découvrir vos charges de travail.

Ressources sans état et ressources avec état

L'architecture utilise un maillage de services, car elle dissocie les fonctions des services (mode de mise en œuvre de la logique métier) des fonctions réseau (quand et comment acheminer le trafic vers les fonctions de service). Dans le document de déploiement associé, vous utilisez Istio comme maillage de services.

Dans l'ancien environnement, la plupart des appels de service n'impliquent pas le réseau, car ils se déroulent sur une plate-forme monolithique. Dans une architecture de microservices, les communications entre les services passent par le réseau, et les services doivent gérer cette spécificité. Un maillage de services élimine les fonctions devant gérer les communications réseau, de sorte que vous n'avez pas à les implémenter dans chaque application. Un maillage de services réduit également la complexité opérationnelle du réseau, car il fournit des fonctionnalités de sécurisation des canaux de communication, d'équilibrage de charge, de gestion du trafic et d'observabilité qui ne nécessitent aucune configuration.

Le déploiement et la configuration d'un maillage de services vous permettent d'acheminer le trafic de manière dynamique vers l'ancien environnement ou l'environnement cible. Vous n'avez pas besoin de modifier la configuration de l'application pour effectuer la migration, car la gestion du trafic est transparente pour les services intégrés au maillage.

Si cette approche est parfaitement adaptée aux fonctionnalités sans état, la migration des éléments avec état qui sont sensibles à la latence ou étroitement associées à d'autres fonctionnalités nécessitent des opérations de planification et de refactorisation supplémentaires.

  • Fonctionnalités avec état : lorsque vous migrez des fonctionnalités avec état, vous devez également migrer les données, afin de réduire le plus possible les temps d'arrêt et de limiter les problèmes de synchronisation et d'intégrité pendant la migration. Pour en savoir plus sur les stratégies de migration de données, consultez la section Évaluer les approches de migration des données de la page "Migration vers Google Cloud : transférer vos ensembles de données volumineux".
  • Fonctionnalités sensibles à la latence : si une fonctionnalité requiert une faible latence pour communiquer avec d'autres fonctionnalités, vous devrez peut-être déployer des composants supplémentaires pendant le processus de migration. Les proxys pouvant précharger les données ou mettre en cache les couches sont couramment utilisés pour atténuer cette sensibilité.
  • Fonctionnalités étroitement associées à d'autres fonctionnalités : si deux fonctionnalités ou plus sont étroitement liées, vous devrez peut-être procéder à leur migration en même temps. Bien que cette approche soit plus facile que transférer une application entière, elle peut s'avérer plus complexe que migrer une seule fonctionnalité.

Enregistrer des services avec le maillage de services

Étant donné que votre ancien environnement n'est pas directement intégré au maillage de services, lorsque vous configurez votre migration, vous devez enregistrer manuellement auprès du maillage de services tous les services exécutés dans l'ancien environnement. Si votre environnement s'exécute déjà dans Kubernetes, vous pouvez automatiser cet enregistrement à l'aide de l'intégration assurée par les API de maillage de services.

Après avoir enregistré l'ancien environnement, vous utilisez le maillage de services pour exposer les microservices exécutés dans l'ancien environnement. Vous pouvez ensuite acheminer progressivement le trafic vers les microservices à partir des interfaces de l'ancien environnement vers celles de l'environnement cible.

Les clients ne perçoivent aucune interruption de service, car ils accèdent aux interfaces des deux environnements via une couche d'équilibrage de charge. Le routage du trafic à l'intérieur du maillage de services est transparent pour les clients. Ils ne sauront donc pas que la configuration de routage a été modifiée.

Optimisation des coûts

Cette architecture utilise les composants facturables suivants de Google Cloud :

Lorsque vous déployez l'architecture, vous pouvez utiliser le simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

Optimisation des performances

Dans cette architecture, le trafic est presque équitablement réparti entre les services exécutés dans Compute Engine et ceux exécutés dans GKE. Le maillage de services équilibre le trafic entre les instances d'un service qu'il sélectionne, qu'elles soient exécutées dans le cluster GKE ou dans les instances Compute Engine. Si vous souhaitez que tout le trafic passe par le maillage de services, vous devez reconfigurer les charges de travail exécutées dans Compute Engine pour qu'elles pointent vers les services du maillage de services, au lieu de s'y connecter directement. Vous pouvez configurer la règle d'équilibrage de charge pour les révisions de chaque service à l'aide de la ressource DestinationRule.

Déploiement

Pour déployer cette architecture, consultez la page Exécuter votre migration avec le déploiement du maillage de services Istio.

Étapes suivantes