Migrer l'infrastructure Hadoop sur site vers Google Cloud

Last reviewed 2024-08-15 UTC

Ce guide explique comment transférer votre système Apache Hadoop sur site vers Google Cloud. Il décrit un processus de migration qui déplace non seulement votre travail Hadoop vers Google Cloud, mais vous permet également de l'adapter pour profiter des avantages d'un système Hadoop optimisé pour le cloud computing. Il présente également certains concepts fondamentaux que vous devez comprendre pour transférer votre configuration Hadoop vers Google Cloud.

Ce guide est le premier d'une série consacrée au processus de migration depuis un environnement Hadoop sur site :

Avantages de la migration vers Google Cloud

Google Cloud peut vous permettre d'économiser du temps, de l'argent et des efforts de plusieurs façons, par rapport à une solution Hadoop sur site. Dans de nombreux cas, l'adoption d'une approche basée sur le cloud peut simplifier votre solution globale et la rendre plus facile à gérer.

Compatibilité avec Hadoop

Google Cloud inclut Dataproc, qui est un environnement Hadoop et Spark géré. Vous pouvez utiliser Dataproc pour exécuter la plupart de vos tâches existantes avec un minimum de modifications. Vous n'avez donc pas besoin de renoncer aux outils Hadoop que vous connaissez déjà.

Matériel géré et configuration

Lorsque vous exécutez Hadoop sur Google Cloud, vous n'avez plus à vous soucier du matériel physique. Il vous suffit de spécifier la configuration de votre cluster, et Dataproc alloue des ressources à votre place. Vous pouvez faire évoluer votre cluster à tout moment.

Gestion des versions simplifiée

Maintenir les outils Open Source à jour ainsi qu'en bon état de fonctionnement constitue l'un des aspects les plus complexes de la gestion des clusters Hadoop. Lorsque vous utilisez Dataproc, une grande partie de ce travail est gérée pour vous par la gestion des versions de Dataproc.

Configuration flexible de tâche

Une configuration Hadoop sur site classique consiste en un seul cluster qui remplit de nombreuses fonctions. Lorsque vous passez à Google Cloud, vous pouvez vous concentrer sur des tâches individuelles et créer autant de clusters que vous le souhaitez. Cela réduit en grande partie la complexité liée à la maintenance d'un cluster unique avec des dépendances croissantes et des interactions de configuration logicielles.

Planifier votre migration

La migration d'une solution Hadoop sur site vers Google Cloud nécessite un changement d'approche. Un système Hadoop sur site classique consiste en un cluster monolithique compatible avec de nombreuses charges de travail, souvent dans plusieurs secteurs d'activité. En conséquence, le système devient de plus en plus complexe avec le temps et peut obliger les administrateurs à faire des compromis pour que le cluster monolithique fonctionne correctement. Lorsque vous transférez votre système Hadoop vers Google Cloud, vous pouvez en simplifier l'administration. Cependant, pour obtenir cette simplification et le traitement le plus efficace dans Google Cloud à un coût minimal, vous devez repenser la structure de vos données et de vos tâches.

Comme Dataproc exécute Hadoop sur Google Cloud, l'utilisation d'un cluster Dataproc persistant pour répliquer votre configuration sur site peut sembler être la solution la plus simple. Toutefois, cette approche présente les limites suivantes :

  • Conserver vos données dans un cluster HDFS persistant à l'aide de Dataproc est plus onéreux que de les stocker dans Cloud Storage. Nous recommandons la seconde approche, comme expliqué plus loin. La conservation des données dans un cluster HDFS limite également votre capacité à les utiliser avec d'autres produits Google Cloud.
  • L'amélioration ou le remplacement de certains de vos outils Open Source par d'autres services Google Cloud associés peut s'avérer plus efficace ou plus économique dans certains cas d'utilisation.
  • Il est plus difficile de gérer un seul cluster Dataproc persistant pour vos tâches que de passer à des clusters ciblés qui desservent des tâches ou des secteurs d'activité individuels.

La manière la plus rentable et la plus souple de migrer votre système Hadoop vers Google Cloud consiste à ne plus penser en termes de grands clusters polyvalents et persistants, mais plutôt en termes de petits clusters temporaires, conçus pour exécuter des tâches spécifiques. Vous stockez vos données dans Cloud Storage pour pouvoir gérer plusieurs clusters de traitement temporaires. Ce modèle est souvent appelé modèle éphémère, car les clusters que vous utilisez pour le traitement des tâches sont alloués en fonction des besoins et sont abandonnés une fois les tâches terminées.

Le schéma suivant illustre une migration hypothétique d'un système sur site vers un modèle éphémère sur Google Cloud.

Diagramme illustrant la façon dont les clusters locaux peuvent être réorganisés lors de la migration vers Google Cloud.

Dans cet exemple, quatre tâches exécutées sur deux clusters sur site sont transférées vers Dataproc. Les clusters éphémères utilisés pour exécuter les tâches dans Google Cloud sont conçus pour optimiser l'efficacité de chaque tâche. Les deux premiers jobs utilisent le même cluster, tandis que le troisième et le quatrième s'exécutent chacun sur leur propre cluster. Lorsque vous transférez vos propres tâches, vous pouvez personnaliser et optimiser les clusters pour des tâches individuelles ou pour des groupes de tâches, en fonction de vos besoins. Dataproc vous aide à définir rapidement plusieurs clusters, à les mettre en ligne et à les adapter à vos besoins.

Les données de l'exemple sont transférées à partir de deux clusters HDFS sur site vers des buckets Cloud Storage. Les données du premier cluster sont divisées en plusieurs buckets et le second cluster est transféré vers un seul bucket. Vous pouvez personnaliser la structure de vos données dans Cloud Storage pour répondre aux besoins de vos applications et de votre entreprise.

L'exemple de migration capture les états de début et de fin d'une migration complète vers Google Cloud. Ceci suppose une seule étape, mais vous obtiendrez de meilleurs résultats si vous ne concevez pas le passage à Google Cloud comme une migration unique et complète. Pensez plutôt à la refactorisation de vos solutions pour qu'elles utilisent un nouvel ensemble d'outils d'une manière qui n'était pas possible sur site. Pour que cette refactorisation fonctionne, nous vous recommandons d'effectuer une migration incrémentielle.

Voici les étapes recommandées pour migrer vos workflows vers Google Cloud :

  1. Commencez par transférer vos données.

    • Transférez vos données dans des buckets Cloud Storage.
    • Procédez par étapes. Utilisez des données de sauvegarde ou des données archivées pour minimiser l'impact sur votre système Hadoop existant.

  2. Expérimentez.

    • Utilisez un sous-ensemble de données pour réaliser des tests. Élaborez une démonstration de faisabilité à petite échelle pour chacune de vos tâches.
    • Testez de nouvelles approches permettant de travailler avec vos données.
    • Adaptez-vous à Google Cloud et aux modèles de cloud computing.

  3. Envisagez des clusters spécialisés et éphémères.

    • Utilisez des clusters aussi petits que possible : définissez-les en tâches simples ou en petits groupes de tâches étroitement liées.
    • Créez des clusters dès que vous en avez besoin pour une tâche et supprimez-les lorsque vous avez terminé.

  4. Utilisez les outils Google Cloud chaque fois que cela semble pertinent.

Passer à un modèle éphémère

Le principal changement dans votre approche entre l'exécution d'un workflow Hadoop sur site et l'exécution du même workflow sur Google Cloud est l'abandon des clusters monolithiques et persistants au profit de clusters spécialisés et éphémères. Lorsque vous devez exécuter une tâche, vous activez un cluster, puis vous le supprimez une fois la tâche terminée. Les ressources requises par vos tâches ne sont actives que lorsqu'elles sont utilisées. Vous ne payez donc que ce que vous consommez. Cette approche vous permet d'adapter les configurations de cluster à des tâches individuelles. Comme vous n'avez pas à gérer ni à configurer de cluster persistant, vous réduisez les coûts d'utilisation des ressources et d'administration du cluster.

Cette section explique comment transférer votre infrastructure Hadoop existante vers un modèle éphémère.

Séparer les données du calcul

L'utilisation de Cloud Storage en tant que solution de stockage persistante pour vos workflows présente les avantages suivants :

  • La gestion des autorisations d'accès est plus simple.
  • Il s'agit d'un système de fichiers compatible Hadoop (HCFS), donc facile à utiliser avec vos tâches existantes.
  • Il est plus rapide que HDFS dans de nombreux cas.
  • Il nécessite moins de maintenance que HDFS.
  • Il est plus facile de migrer des données qu'avec HDFS.
  • Il vous permet d'utiliser facilement vos données avec l'ensemble des produits Google Cloud.
  • Il s'avère beaucoup moins coûteux qu'un HDFS sur un cluster Dataproc persistant pour conserver vos données.

Vos données étant stockées de manière persistante dans Cloud Storage, vous pouvez exécuter vos tâches sur des clusters Hadoop éphémères gérés par Dataproc.

Dans certains cas, il peut être plus judicieux de transférer des données vers une autre technologie Google Cloud, telle que BigQuery ou Bigtable. Toutefois, la plupart des données à usage général devraient persister dans Cloud Storage. De plus amples détails sur ces autres options de stockage sont fournis plus loin dans ce guide.

Exécuter des tâches sur des clusters éphémères

Dataproc facilite la création et la suppression de clusters. Au lieu d'utiliser un cluster monolithique, profitez-en pour multiplier les clusters éphémères. Cette approche présente plusieurs avantages :

  • Vous pouvez éviter les points de défaillance uniques et augmenter la fiabilité de votre pipeline de données. Lorsqu'un cluster partagé de longue durée rencontre un état d'erreur, l'ensemble du pipeline de données peut être bloqué. La réparation d'un cluster de longue durée avec état peut prendre beaucoup de temps, ce qui entraîne des violations des objectifs de niveau de service (SLO). En revanche, un cluster éphémère sans état posant problème peut facilement être supprimé, puis recréé avec de nouvelles tentatives d'exécution des jobs.
  • Vous pouvez obtenir des performances de job plus prévisibles et éviter les conflits de SLO en éliminant les conflits de ressources entre les jobs.
  • Vous pouvez optimiser les configurations de cluster et les règles d'autoscaling pour des jobs individuels.
  • Vous pouvez obtenir les derniers correctifs de sécurité, correctifs de bugs et optimisations lorsque vous créez un cluster éphémère pour un job.
  • Vous pouvez éviter les problèmes courants liés aux clusters de longue durée, tels que les disques remplis par les journaux et les fichiers temporaires, ou le cluster ne parvenant pas à effectuer un scaling à la hausse en raison d'une indisponibilité dans la zone.
  • Vous n'avez pas besoin de gérer les clusters au fil du temps, car les clusters éphémères sont configurés chaque fois que vous les utilisez. Le fait de ne pas avoir à gérer les clusters élimine la charge administrative liée à la gestion des outils entre les jobs.
  • Vous n'avez pas besoin de gérer une infrastructure séparée pour le développement, les tests et la production. Vous pouvez utiliser les mêmes définitions pour créer autant de versions différentes d'un cluster que nécessaire.
  • Vous pouvez résoudre les problèmes plus rapidement avec le cluster à job unique isolé.
  • Vous ne payez les ressources que lorsque vos tâches les utilisent.

Les actions d'initialisation Dataproc vous permettent de définir la configuration des nœuds d'un cluster. Cela permet de simplifier la gestion des différentes configurations de cluster dont vous avez besoin pour traiter étroitement des tâches individuelles et des groupes de tâches associés. Pour commencer, vous pouvez utiliser les exemples d'action d'initialisation fournis. Ces exemples montrent comment créer vos propres actions d'initialisation.

Minimiser la durée de vie des clusters éphémères

L'intérêt des clusters éphémères réside dans leur utilisation proportionnelle à la durée de vie des tâches. Au moment d'exécuter un job, suivez ce processus :

  1. Créez un cluster correctement configuré.

  2. Exécutez votre tâche en envoyant la sortie vers Cloud Storage ou un autre emplacement persistant.

  3. Supprimez le cluster.

  4. Utilisez la sortie de votre job en fonction de vos besoins.

  5. Affichez les journaux dans Cloud Logging ou Cloud Storage.

Ce processus est représenté dans le schéma suivant :

Schéma d'un flux de tâches éphémères dans le cloud

Utiliser de petits clusters persistants uniquement en cas de nécessité absolue

Si vous ne pouvez pas travailler sans cluster persistant, créez-en un. Cette option peut s'avérer coûteuse et n'est pas recommandée s'il existe un moyen d'effectuer votre tâche sur des clusters éphémères.

Vous pouvez réduire le coût d'un cluster persistant :

  • en créant un cluster aussi petit que possible ;
  • en limitant votre travail sur ce cluster au plus petit nombre possible de tâches ;
  • en adaptant le cluster au nombre minimum de nœuds viables, en les ajoutant de manière plus dynamique pour répondre à la demande.

Effectuer une migration incrémentielle

La migration incrémentielle présente de nombreux avantages. Vous pouvez :

  • isoler les tâches individuelles de votre infrastructure Hadoop existante de la complexité inhérente à un environnement mature ;
  • examiner chaque tâche séparément pour évaluer ses besoins et déterminer le meilleur chemin d'accès pour la migration ;
  • résoudre les problèmes inattendus dès leur apparition sans retarder les tâches dépendantes ;
  • réaliser une démonstration de faisabilité pour chaque processus complexe sans affecter votre environnement de production ;
  • déplacer vos charges de travail vers le modèle éphémère recommandé de manière délibérée et réfléchie.

Votre migration étant propre à votre environnement Hadoop, il n'existe aucun plan universel à tous les scénarios de migration. Préparez un plan qui vous permettra d'adapter chaque élément au paradigme du cloud computing.

Voici une séquence de migration incrémentielle classique :

  1. Transférez une partie de vos données vers Google Cloud.

  2. Faites des tests avec ces données :

    1. Répliquez vos tâches existantes qui utilisent ces données.

    2. Créez des prototypes compatibles avec les données.

  3. Répétez l'opération avec des données supplémentaires.

Commencez avec les données les moins critiques possible. Au début, il peut être judicieux d'utiliser des données de sauvegarde et d'archive.

Un type de tâche à faible risque pouvant faire office de test de démarrage consiste à effectuer un remplissage en exécutant un traitement en rafale sur des données archivées. Vous pouvez configurer des tâches qui remplissent les éléments manquants dans le traitement des données qui existaient avant que vos tâches actuelles n'aient été configurées. En commençant par les tâches d'utilisation intensive, vous bénéficiez souvent d'une expérience du scaling sur Google Cloud tout au début de votre plan de migration. Cela peut s'avérer utile avant de vous attaquer à des tâches plus critiques.

Le schéma ci-dessous montre un exemple d'architecture hybride de remplissage.

Schéma d'une architecture classique pour le remplissage dans le cloud

L'exemple comprend deux composants principaux. Tout d'abord, les tâches planifiées exécutées sur le cluster sur site, qui transfèrent les données vers Cloud Storage via une passerelle Internet. Ensuite, les tâches de remplissage, qui sont exécutées sur des clusters éphémères Dataproc. Outre le remplissage, vous pouvez utiliser des clusters éphémères dans Google Cloud pour expérimenter et créer des démonstrations de faisabilité pour vos futurs travaux.

Planifier en tenant compte de la migration terminée

Jusqu'ici, ce guide part du principe que votre objectif est de transférer l'intégralité de votre système Hadoop sur site vers Google Cloud. Un système Hadoop exécuté entièrement sur Google Cloud est plus facile à gérer qu'un système fonctionnant à la fois dans le cloud et sur site. Toutefois, une approche hybride est souvent nécessaire pour répondre à vos besoins commerciaux ou technologiques.

Créer une solution hybride

Voici des raisons qui pourraient justifier l'utilisation d'une solution hybride :

  • Vous êtes en train de développer des systèmes cloud natifs. Par conséquent, les systèmes existants qui en dépendent doivent continuer à fonctionner sur site jusqu'à ce que vous ayez terminé.
  • Vous avez des exigences commerciales liées à la conservation de vos données sur site.
  • Vous devez partager des données avec d'autres systèmes fonctionnant sur site, et ces systèmes ne peuvent pas interagir avec Google Cloud, en raison de restrictions techniques ou commerciales.

Une solution hybride classique comporte quatre parties principales :

  1. Un cluster Hadoop sur site

  2. Une connexion du cluster sur site à Google Cloud

  3. Un stockage centralisé des données dans Google Cloud

  4. Des composants cloud natifs qui traitent des données dans Google Cloud

Un problème inhérent aux solutions cloud hybrides consiste à savoir comment synchroniser vos systèmes. Comment vous assurer que les modifications que vous apportez aux données à un endroit sont reflétées ailleurs ? Vous pouvez simplifier la synchronisation en établissant des distinctions claires sur la manière dont vos données sont utilisées dans différents environnements.

Par exemple, vous pouvez avoir une solution hybride où seules vos données archivées sont stockées dans Google Cloud. Vous pouvez configurer des tâches planifiées pour transférer vos données du cluster sur site vers Google Cloud lorsque les données atteignent un certain âge. Vous pouvez ensuite configurer toutes les tâches qui fonctionnent sur les données archivées dans Google Cloud, afin de ne jamais avoir à synchroniser les modifications sur vos clusters locaux.

Une autre façon de diviser votre système consiste à déplacer toutes les données et tâches d'un projet ou d'un groupe de travail spécifique vers Google Cloud, tout en conservant d'autres tâches sur site. Vous pouvez ensuite vous concentrer sur vos tâches au lieu de créer des systèmes complexes de synchronisation de données.

Vous pouvez rencontrer des problèmes de sécurité ou de logistique qui compliquent la façon dont vous connectez votre cluster sur site à Google Cloud. Une solution consiste à utiliser un cloud privé virtuel connecté à votre réseau sur site à l'aide de Cloud VPN.

Le schéma suivant illustre un exemple de configuration cloud hybride :

Schéma d'une architecture Hadoop cloud hybride classique

Cet exemple de configuration utilise Cloud VPN pour connecter un VPC Google Cloud à un cluster sur site. Le système utilise Dataproc dans le VPC pour gérer les clusters persistants qui traitent les données provenant du système sur site. Cela peut impliquer la synchronisation des données entre les systèmes. Ces clusters Dataproc persistants transfèrent également les données provenant du système sur site vers les services de stockage appropriés dans Google Cloud. À titre d'illustration, l'exemple utilise Cloud Storage, BigQuery et Bigtable pour le stockage. Il s'agit des destinations les plus courantes pour les données traitées par les charges de travail Hadoop dans Google Cloud.

L'autre moitié de l'exemple de solution montre plusieurs clusters éphémères créés en fonction des besoins dans le cloud public. Ces clusters peuvent être utilisés pour de nombreuses tâches, y compris la collecte et la transformation de nouvelles données. Les résultats de ces tâches sont stockés dans les mêmes services de stockage que ceux utilisés par les clusters exécutés dans le VPC.

Créer une solution cloud native

À l'inverse, une solution cloud native est plus simple. Comme vous exécutez toutes vos jobs dans Google Cloud à l'aide de données stockées dans Cloud Storage, vous évitez la complexité de la synchronisation des données. Toutefois, vous devez vous assurer que vos différents jobs utilisent les mêmes données.

Le schéma suivant montre un exemple de système cloud natif :

Schéma d'une architecture Hadoop cloud native classique

L'exemple de système comporte des clusters persistants et des clusters éphémères. Les deux types de clusters partagent des ressources et des outils cloud, y compris le stockage et la surveillance. Dataproc se sert d'images de machine standardisées pour définir les configurations logicielles sur les VM d'un cluster. Vous pouvez utiliser ces images prédéfinies comme base pour la configuration de VM dont vous avez besoin. L'exemple montre la plupart des clusters persistants exécutés sur la version 1.1, avec un cluster exécuté sur la version 1.2. Vous pouvez créer des clusters avec des instances de VM personnalisées aussi souvent que nécessaire. Cela vous permet d'isoler les environnements de test et de développement des données de production et des tâches critiques.

Les clusters éphémères de l'exemple exécutent diverses tâches. Ici, Apache Airflow est exécuté sur Compute Engine pour organiser votre travail avec des clusters éphémères.

Utiliser les services Google Cloud

Cette section aborde d'autres éléments à prendre en compte lors de la migration de Hadoop vers Google Cloud.

Remplacement d'outils Open Source par les services Google Cloud

Google Cloud propose de nombreux produits que vous pouvez utiliser avec votre système Hadoop. L'utilisation d'un produit Google Cloud peut souvent présenter des avantages par rapport à l'exécution du produit Open Source équivalent dans Google Cloud. Découvrez les produits et services Google Cloud pour explorer toutes les options offertes par la plate-forme.

Utiliser les régions et les zones

Vous devez mesurer l'impact des zones géographiques et des régions avant de configurer vos données et vos jobs. De nombreux services Google Cloud nécessitent que vous spécifiiez des régions ou des zones auxquelles attribuer des ressources. La latence peut augmenter lorsque les requêtes proviennent d'une région différente de celle dans laquelle les ressources sont stockées. En outre, si les ressources du service et vos données persistantes se trouvent dans des régions différentes, certains appels aux services Google Cloud peuvent copier toutes les données requises d'une zone à une autre avant leur traitement. Cela peut avoir de graves conséquences sur les performances.

Configurer l'authentification et les autorisations

Votre contrôle sur les autorisations des services Google Cloud sera probablement moins précis que celui auquel vous êtes habitué dans votre environnement Hadoop. Assurez-vous de bien comprendre le fonctionnement de la gestion des accès dans Google Cloud avant de commencer la migration.

La gestion de l'authentification et des accès (IAM) gère l'accès aux ressources cloud. Ce service se base sur des comptes et des rôles. Les comptes identifient un utilisateur ou une requête (authentification), et les rôles attribués à un compte déterminent le niveau d'accès (autorisation). La plupart des services Google Cloud disposent de leurs propres rôles pour vous aider à affiner les autorisations. Dans le cadre du processus de planification de votre migration, vous devez obtenir plus de détails sur l'interaction d'IAM avec Cloud Storage et Dataproc. Documentez-vous sur les modèles d'autorisations de chaque service Google Cloud supplémentaire chaque fois que vous en ajoutez un à votre système, et réfléchissez à la définition des rôles applicables aux services que vous utilisez.

Surveiller les tâches avec Cloud Logging

Les tâches Google Cloud transmettent leurs journaux à Cloud Logging, où ceux-ci sont facilement accessibles. Vous pouvez obtenir les journaux des manières suivantes :

Gérer vos nœuds périphériques avec Compute Engine

Vous pouvez utiliser Compute Engine pour accéder à un nœud périphérique d'un cluster Dataproc Hadoop. Comme pour la plupart des produits Google Cloud, vous disposez de plusieurs options de gestion : via la console Web, la ligne de commande et les API Web.

Utiliser les services de big data de Google Cloud

Cloud Storage est le principal moyen de stocker des données non structurées dans Google Cloud, mais ce n'est pas la seule option de stockage. Certaines de vos données pourraient être plus adaptées à des produits conçus explicitement pour le big data.

Vous pouvez utiliser Bigtable pour stocker un volume important de données éparses. Bigtable est une API compatible HBase avec une faible latence et une évolutivité élevée pour s'adapter à vos tâches.

Pour l'entreposage de données, vous pouvez utiliser BigQuery.

Étapes suivantes