オンプレミスの Hadoop インフラストラクチャの Google Cloud Platform への移行

このガイドでは、オンプレミスの Apache Hadoop システムを Google Cloud Platform(GCP)に移行する方法について説明します。Hadoop の作業を GCP に移行するだけでなく、作業も調整することで、クラウド コンピューティングに最適化された Hadoop システムのメリットを活かすことができます。また、Hadoop の構成を GCP に変換するうえで理解が必要な基本的なコンセプトについても説明します。

次のように、オンプレミス Hadoop からの移行方法を説明するガイドがいくつかあります。これはその最初のガイドです。

GCP に移行するメリット

GCP を使用すると、オンプレミスの Hadoop ソリューションと比較して時間、コスト、労力を節約できます。一般に、クラウドベースのアプローチのほうがソリューション全体がシンプルになり、管理もしやすくなります。

Hadoop 用の組み込みサポート

GCP には、Hadoop と Spark の管理環境である Cloud Dataproc が用意されています。Cloud Dataproc を使用すると、既存のジョブの大半を最小限の変更で実行できます。使い慣れた Hadoop ツールもそのまま利用できます。

ハードウェアと構成の管理

GCP で Hadoop を実行する場合、物理的なハードウェアの管理に煩わされる必要はありません。クラスタの構成を指定すると、Cloud Dataproc がリソースを割り当てるので、必要なときにいつでもスケーリングできます。

バージョン管理が簡単

Hadoop クラスタを管理するうえで最も複雑な作業は、オープンソースのツールを最新の状態に保ち、連携させることです。Cloud Dataproc では、その作業の多くが Cloud Dataproc のバージョニングによって管理されます。

柔軟なジョブ構成が可能

オンプレミスの Hadoop 環境の多くは、1 つのクラスタを複数の目的で使用しています。GCP に移行すると、クラスタを必要なだけ作成して、それぞれのタスクに割り当てることができます。単一のクラスタでは、依存関係が増えてソフトウェアの構成が多くなると維持管理が複雑になりますが、このような負担は大幅に軽減されます。

移行の計画

オンプレミスの Hadoop ソリューションから GCP に移行する場合、アプローチの変更が必要になります。オンプレミスの一般的な Hadoop システムは、多くのワークロードをサポートするモノリシック クラスタで構成され、たいていは複数のビジネス領域で使用されています。このため、時間の経過とともにシステムは複雑さを増し、モノリシック クラスタ内ですべての作業を行うために調整が必要になります。Hadoop システムを GCP に移行すると、管理作業の煩雑さを軽減できます。しかし、作業負担を軽減し、GCP でコストを抑えながら効率的に処理を行うには、データとジョブの構造を見直す必要があります。

Cloud Dataproc は GCP 上で Hadoop を実行するため、永続的な Cloud Dataproc クラスタを使用してオンプレミスの設定を複製することが最も簡単な移行方法のようにも見えます。しかし、この方法ではいくつかの制限があります。

  • 後で説明するように、Cloud Dataproc を使用して永続的な HDFS クラスタにデータを保存すると、Cloud Storage にデータを保存する場合よりもコストがかかります。HDFS クラスタにデータを保存すると、他の GCP プロダクトでデータに実行できる機能が制限されます。
  • 特定のユースケースでは、オープンソース ベースの一部のツールを関連の GCP サービスで補強または移行することで、より効率的または経済的に処理を行えます。
  • 単一の永続的な Cloud Dataproc クラスタにすべてのジョブを割り当てると、ジョブまたはジョブ領域ごとに異なるクラスタに移行した場合よりも管理が難しくなります。

Hadoop システムを GCP に移行する場合、大規模な永続クラスタを多目的で使用するのではなく、持続時間の短い、小規模なクラスタで特定のジョブを実行するほうが、費用対効果の高い柔軟な処理を行えます。この方法では、データを Cloud Storage に保存して、複数の一時的な処理クラスタに対応します。ジョブを処理するクラスタが必要に応じて割り当てられ、ジョブが完了すると解放されるため、このモデルはエフェメラル モデルといわれます。

次の図は、オンプレミス システムから GCP のエフェメラル モデルへの移行例を示しています。

GCP への移行時にオンプレミス クラスタをどのように再配置できるかを示す図。

この例では、2 つのオンプレミス クラスタで実行されている 4 つのジョブを Cloud Dataproc に移行しています。GCP でジョブを実行するエフェメラル クラスタは、個々のジョブの効率を最大限に高めるように定義されています。最初の 2 つのジョブは同じクラスタを使用し、3 番目と 4 番目のジョブはそれぞれ独自のクラスタで実行されます。ユーザー独自のジョブを移行する場合は、個々のジョブまたはジョブグループに使用されるクラスタをカスタマイズし、それぞれの作業に合わせて最適化できます。Cloud Dataproc では、複数のクラスタを定義してオンラインにし、必要に応じて簡単にスケーリングできます。

この例のデータは、オンプレミスの 2 つの HDFS クラスタから Cloud Storage バケットに移行されています。最初のクラスタのデータは複数のバケットに分割され、2 番目のクラスタは単一のバケットに移行されています。Cloud Storage では、アプリケーションやビジネスのニーズに合わせてデータの構造をカスタマイズできます。

この移行例では GCP への移行の開始から終了までを網羅しています。これは完結した 1 つのステップのように見えますが、GCP への移行を 1 回で完了しようとすることはおすすめできません。この移行は、オンプレミスではできない方法で新しいツールセットを使用するようにソリューションをリファクタリングする、と考えたほうが良い結果が得られます。このようなリファクタリングを行うために、段階的な移行をおすすめしています。

ワークフローを GCP に移行する際に推奨される手順は次のとおりです。

  1. まず、データを移行します。

    • データを Cloud Storage バケットに移行します。
    • 小規模で始めます。バックアップ データやアーカイブ データを使用し、既存の Hadoop システムへの影響を最小限に抑えます。
  2. テストを行います。

    • データのサブセットを使用してテストを行います。ジョブごとに小規模なスケールの概念実証を行います。
    • 新しい方法でデータを操作します。
    • GCP とクラウド コンピューティングのパラダイムに合わせて調整します。
  3. 特別なエフェメラル クラスタを検討します。

    • できるだけ小さなクラスタを使用します。このクラスタを単一のジョブまたは関連するジョブの小規模なグループに割り当てます。
    • ジョブで必要になるたびにクラスタを作成し、処理が完了したらクラスタを削除します。
  4. 適切な場所で GCP ツールを使用します。

エフェメラル モデルへの移行

オンプレミスの Hadoop ワークフローの実行と GCP での実行とで最も大きく異なる点は、モノリシックな永続クラスタから専用のエフェメラル クラスタに変わる点です。クラスタはジョブの実行が必要な時点で作成され、ジョブが完了すると削除されます。ジョブに必要なリソースは、ジョブで使用されるときにのみアクティブになるため、実際の使用量に対してのみ課金されます。この方法では、ジョブごとにクラスタ構成を調整できます。永続的なクラスタの維持や構成を行わないため、リソース使用とクラスタ管理のコストを削減できます。

このセクションでは、既存の Hadoop インフラストラクチャをエフェメラル モデルに移行する方法について説明します。

データと計算処理を分離する

ワークフローの永続ストレージとして Cloud Storage を使用すると、次の利点があります。

  • Hadoop 互換ファイル システム(HCFS)を採用しているため、既存のジョブで簡単に使用できます。
  • 多くの場合、HDFS よりも高速です。
  • HDFS よりもメンテナンスが少なくなります。
  • GCP サービス全体でデータを簡単に使用できます。
  • 永続的な Cloud Dataproc クラスタで HDFS にデータを保存する場合よりも、かなり安価で利用できます。

データを Cloud Storage に永続的に保存し、Cloud Dataproc で管理されているエフェメラルな Hadoop クラスタでジョブを実行できます。

BigQuery や Cloud Bigtable などの別の GCP テクノロジーへのデータ移行が適している場合もありますが、汎用的なデータの大半は Cloud Storage での保存が適しています。別のストレージ オプションの詳細については、このガイドの後半で説明します。

エフェメラル クラスタでジョブを実行する

Cloud Dataproc を使用すると、クラスタの作成と削除を簡単に行うことができるため、単一のモノリシック クラスタから複数のエフェメラル クラスタに移行できます。このアプローチにはいくつかのメリットがあります。

  • ジョブごとに異なるクラスタ構成を使用できるため、ジョブ間でツールを管理する必要がなくなります。
  • 個々のジョブまたはジョブグループに合わせてクラスタをスケーリングできます。
  • ジョブで使用したリソース量に対してのみ課金されます。
  • クラスタは、使用するタブに新しく構成されます。クラスタを常時維持する必要はありません。
  • 開発、テスト、本番環境用に別々のインフラストラクチャを用意する必要はありません。同じ定義を使用して、必要に応じて必要な数のクラスタを作成できます。

クラスタ内のノード構成は Cloud Dataproc の初期化アクションで定義します。個々のジョブや関連するジョブグループに合わせて異なるクラスタ構成を簡単に維持できます。また、初期化アクションのサンプルも用意されています。このサンプルを使用して、独自の初期化アクションを作成できます。

エフェメラル クラスタのライフタイムを最小にする

エフェメラル クラスタで重要なポイントは、ジョブの存続期間にのみ使用することです。ジョブの実行プロセスは次のようになります。

  1. 適切な構成でクラスタを作成します。

  2. ジョブを実行し、出力を Cloud Storage または別の永続的な場所に送信します。

  3. クラスタを削除します。

  4. 必要に応じてジョブの出力を使用します。

  5. Stackdriver または Cloud Storage でログを確認します。

このプロセスを図にすると、次のようになります。

クラウド内でのエフェメラルなジョブの流れ

必要なときに小規模な永続クラスタを使用

永続クラスタがないとジョブを実行できない場合は、永続クラスタを作成できます。ただし、このオプションはコストが高くなる可能性があり、エフェメラル クラスタでジョブを実行できる場合はおすすめしません。

永続クラスタのコストを最小限に抑えるには、次のような方法があります。

  • 可能な限り小規模なクラスタを作成する。
  • 可能な限り少数のジョブをクラスタに割り当てる。
  • 実行可能な最小ノード数でクラスタを作成し、必要に応じて動的にスケーリングする。

段階的な移行

段階的な移行には多くの利点があります。次のことが可能です。

  • 既存の Hadoop インフラストラクチャの個々のジョブを複雑な環境から解放できます。
  • ジョブを個別に調査し、最適な移行パスを判断できます。
  • 予期しない問題が発生しても、依存するタスクを遅らせることなく、対処できます。
  • 本番環境に影響を与えることなく、複雑なプロセスごとに概念実証を実施できます。
  • 推奨のエフェメラル モデルにワークロードを慎重に移行できます。

移行は Hadoop 環境に固有のものです。すべての移行シナリオに適合する普遍的な計画はありません。クラウド コンピューティングのパラダイムに各要素を柔軟に切り替えられるように、移行計画を作成してください。

標準的な移行手順は次のようになります。

  1. データの一部を GCP に移行します。

  2. 移行したデータでテストを行います。

    1. このデータを使用する既存のジョブを複製します。

    2. このデータを使用する新しいプロトタイプを作成します。

  3. データを追加して、上記の手順を繰り返します。

重要でないデータから移行を始めてください。初期段階では、バックアップ データとアーカイブを使用することをおすすめします。

リスクの低いテストとしてはバックフィルがあります。アーカイブ データでバースト処理を実行します。現在のジョブの前に存在していたデータを埋め戻すジョブを設定します。バーストジョブを開始すると、移行計画の早い段階で GCP のスケーリングを経験することがよくあります。これは、より重要なジョブの移行を行うときに役立ちます。

次の図は、一般的なバックフィル ハイブリッド アーキテクチャを示しています。

クラウドのバックフィルの標準的なアーキテクチャ図。

この例は 2 つの主要部分から構成されています。まず、オンプレミス クラスタで実行されているスケジュール ジョブが、インターネット ゲートウェイ経由で Cloud Storage にデータを push します。次に、バックフィル ジョブが Cloud Dataproc のエフェメラル クラスタで実行されます。GCP のエフェメラル クラスタは、バックフィルだけでなく、今後の作業のテストや概念実証の作成にも使用できます。

完全な移行を前提にした計画

このガイドでは、Hadoop システム全体をオンプレミスから GCP に移行することを前提に説明を進めてきました。GCP で Hadoop システム全体を実行したほうが、クラウドとオンプレミスを併用しているシステムよりも管理が容易になります。しかし、ビジネスニーズや技術的な制約のため、ハイブリッド アプローチが必要になることも少なくありません。

ハイブリッド ソリューションの設計

ハイブリッド ソリューションは次のような場合に必要になります。

  • クラウド ネイティブのシステムを開発中で、開発が完了するまで既存のシステムをオンプレミスで実行しなければならない場合。
  • ビジネス要件で、データをオンプレミスに保管することが必要な場合。
  • オンプレミスで実行されている他のシステムとデータを共有する必要があり、技術的またはビジネス上の制約のため、これらのシステムが GCP にアクセスできない場合。

標準的なハイブリッド ソリューションは次の 4 つの部分から構成されます。

  1. オンプレミスの Hadoop クラスタ。

  2. オンプレミス クラスタから GCP への接続。

  3. GCP で一元管理されているデータ ストレージ。

  4. GCP でデータを処理するクラウド ネイティブ コンポーネント。

ハイブリッド クラウド ソリューションでは、システムの同期を維持することが重要な課題となります。データに対する変更が他の場所に反映されていることを、どのように確認すればよいでしょうか。各環境でデータがどのように使用されているかを明確に把握することで、同期を簡単に行うことができます。

たとえば、アーカイブされたデータだけを GCP に保存するハイブリッド ソリューションを作成するとします。この場合、指定した期間が経過するとオンプレミス クラスタから GCP にデータを移動するようにジョブ スケジュールを設定します。次に、オンプレミス クラスタに対する変更の同期を不要にするため、アーカイブされたデータを処理するすべてのジョブを GCP で設定します。

また、特定のプロジェクトまたは作業グループのすべてのデータを GCP に移動し、他の作業をオンプレミスに残すこともできます。この場合、複雑なデータ同期システムを作成する必要はなく、ジョブに集中できます。

セキュリティやロジスティクスの点で、オンプレミス クラスタを GCP に接続する方法が問題になる場合があります。この解決策として、Cloud VPN を介してオンプレミス ネットワークに Virtual Private Cloud を接続して使用する方法があります。

次の図は、ハイブリッド クラウドの設定例を示しています。

標準的なハイブリッド クラウド Hadoop のアーキテクチャ図。

この例のセットアップでは、Cloud VPN を使用して GCP VPC をオンプレミス クラスタに接続しています。このシステムは、VPC 内で Cloud Dataproc を使用して、オンプレミス システムからのデータを処理する永続クラスタを管理しています。この方法では、システム間のデータ同期が必要な場合もあります。また、Cloud Dataproc の永続クラスタは、オンプレミス システムから GCP 内のストレージ サービスへのデータ転送も行います。この例では、ストレージとして Cloud Storage、BigQuery、Cloud Bigtable を使用していますが、これらは GCP の Hadoop ワークロードで処理されるデータの保存先としてよく利用されています。

サンプル ソリューションの残りの半分では、複数のエフェメラル クラスタが使用されています。これらは、必要に応じてパブリック クラウドで作成されます。これらのクラスタは、新しいデータの収集や変換など、多くのタスクで使用されます。これらのジョブの結果は、VPC で実行されているクラスタと同じストレージ サービスに保存されます。

クラウド ネイティブ ソリューションの設計

一方、クラウド ネイティブ ソリューションは簡単です。Cloud Storage に保存されたデータを使用して、すべてのジョブを GCP で実行するため、データ同期の複雑さはなくなります。ただし、異なるジョブで同じデータを使用する方法については注意が必要です。

次の図は、クラウド ネイティブ システムの例を示しています。

標準的なクラウド ネイティブ Hadoop のアーキテクチャ図。

このシステムでは、いくつかの永続クラスタとエフェメラル クラスタを使用しています。どちらのクラスタも、ストレージやモニタリング サービスなどクラウドツールとリソースを共有しています。Cloud Dataproc は、標準化されたマシンイメージを使用して、クラスタ内の VM のソフトウェア構成を定義します。これらの定義済みイメージは、必要な VM 構成のベースとして使用できます。この例では、永続クラスタの大半がバージョン 1.1 で実行され、1 つのクラスタがバージョン 1.2 で実行されています。必要であれば、新しいクラスタを作成し、VM インスタンスをカスタマイズできます。これにより、重要な本番環境のデータやジョブからテスト環境と開発環境を分離できます。

この例のエフェメラル クラスタでは、さまざまなジョブが実行されます。この例では、Compute Engine で実行されている Apache Airflow を使用して、エフェメラル クラスタによる作業をスケジュール設定する方法を示しています。

GCP サービスの使用

このセクションでは、Hadoop から GCP に移行する場合のその他の考慮事項について説明します。

オープンソース ツールを GCP サービスに置き換える

GCP には、Hadoop システムで使用できる多くのプロダクトが用意されています。多くの場合、GCP では、類似の機能のオープンソース プロダクトを実行するのではなく GCP のプロダクトを使用したほうがメリットが得られます。このプラットフォームが提供するさまざまなプロダクトについては、GCP のプロダクトとサービスの詳細をご覧ください。

リージョンとゾーンの使用

データとジョブを構成する際は事前に、地域とリージョンの影響を理解しておく必要があります。GCP サービスの多くは、リソースを割り当てるリージョンまたはゾーンを指定する必要があります。リソースが格納されているリージョンと異なるリージョンからリクエストが送信されると、リクエストのレイテンシが長くなる可能性があります。また、サービスのリソースと永続データが異なるリージョンに存在していると、GCP サービスを呼び出したときに、必要なデータのすべてがゾーン間でコピーされてから処理が実行される場合があります。これは、パフォーマンスに深刻な影響を与える可能性があります。

認証と権限の構成

GCP サービスでの権限管理は、オンプレミスの Hadoop 環境よりも制限されている可能性があります。移行を開始する前に、GCP でのアクセス管理がどのように機能するのかを確認してください。

クラウド リソースへのアクセスは、Cloud Identity and Access Management(Cloud IAM)で管理します。これは、アカウントと役割に基づいてアクセスを制御します。アカウントによってユーザーまたはリクエストを識別(認証)し、アカウントに付与された役割により、アクセスレベルを決定(承認)します。ほとんどの GCP サービスでは、権限を微調整できるように独自の一連の役割が用意されています。移行を計画するときは、Cloud IAM と Cloud StorageCloud Dataproc との関係を確認してください。GCP サービスをシステムに追加するときに、それぞれの GCP サービスの権限モデルとサービス全体で機能する役割の定義方法を確認してください。

Stackdriver Logging によるジョブのモニタリング

GCP ジョブは Logging にログを送信します。このログには簡単にアクセスできます。これらのログは次の方法で取得できます。

Compute Engine でのエッジノードの管理

Compute Engine を使用すると、Cloud Dataproc Hadoop クラスタのエッジノードにアクセスできます。他の GCP プロダクトと同様に、ウェブベースのコンソール、コマンドライン、Web API など、さまざまな管理オプションがあります。

GCP ビッグデータ サービスの使用

GCP では、Cloud Storage に非構造化データを格納しますが、他の選択肢もあります。データによっては、ビッグデータ用に設計されたストレージが適している場合もあります。

Cloud Bigtable を使用すると、大量のデータを保存できます。Cloud Bigtable は、低レイテンシとジョブに応じた高度なスケーラビリティを実現できる HBase 準拠の API です。

データ ウェアハウスには BigQuery を使用できます。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Hadoop から GCP への移行