このガイドでは、オンプレミスの Apache Hadoop システムを Google Cloud に移行する方法の概要を説明します。ここでは、Hadoop の作業を Google Cloud に移行するだけでなく、クラウド コンピューティング用に最適化された Hadoop システムの利点を活用するように作業を改善できます。また、Hadoop の構成を Google Cloud に変換するために必要な基本のコンセプトについても説明します。
これは、オンプレミス Hadoop からの移行方法を説明するいくつかのガイドのうちの最初のものです。
- このガイドでは、移行プロセスの概要と計画のポイントについて説明します。
- オンプレミスから Google Cloud への HDFS データの移行では、データを段階的に Google Cloud に移動するための追加のコンテキストを提供します。
- HBase から Bigtable へのデータの移行
- オンプレミスから Dataproc への Hadoop ジョブの移行では、Dataproc や他の Google Cloud プロダクトでジョブを実行するプロセスについて説明します。
Google Cloud への移行のメリット
Google Cloud を使用すると、オンプレミスの Hadoop ソリューションと比較して時間、コスト、労力を節約できます。一般に、クラウドベースのアプローチのほうがソリューション全体がシンプルになり、管理もしやすくなります。
Hadoop 用の組み込みサポート
Google Cloud には、Hadoop と Spark のマネージド環境である Dataproc が含まれています。Dataproc を使用すると、ほとんどの既存のジョブを実行する際の変更を最小限にとどめることができ、使い慣れた Hadoop ツールを引き続きご利用いただけます。
ハードウェアと構成の管理
Google Cloud で Hadoop を実行する場合、物理ハードウェアについてご心配いただく必要はありません。クラスタの構成を指定すると、Dataproc によってリソースが割り当てられます。必要なときにいつでもクラスタをスケーリングできます。
バージョン管理が簡単
Hadoop クラスタを管理するうえで最も複雑な作業は、オープンソースのツールを最新の状態に保ち、連携させることです。Dataproc を使用する場合、その作業の多くが Dataproc のバージョニングによって管理されます。
柔軟なジョブ構成が可能
オンプレミスの Hadoop 環境の多くは、1 つのクラスタを複数の目的で使用しています。Google Cloud に移行すると、個々のタスクに集中し、必要な数のクラスタを作成できます。単一のクラスタでは、依存関係が増えてソフトウェアの構成が多くなると維持管理が複雑になりますが、このような負担は大幅に軽減されます。
移行の計画
オンプレミスの Hadoop ソリューションから Google Cloud への移行には、アプローチの変更が必要です。オンプレミスの一般的な Hadoop システムは、多くのワークロードをサポートするモノリシック クラスタで構成され、たいていは複数のビジネス領域で使用されています。このため、時間の経過とともにシステムは複雑さを増し、モノリシック クラスタ内ですべての作業を行うために調整が必要になります。Hadoop システムを Google Cloud に移行すると、管理の複雑さを軽減できます。ただしその簡素化を実現し、Google Cloud で、最小の費用で最も効率的に処理するには、データとジョブを構造化する方法を再検討する必要があります。
Dataproc は Google Cloud で Hadoop を実行するため、永続的な Dataproc クラスタを使用してオンプレミスの設定を複製するのが最も簡単なソリューションです。しかし、この方法ではいくつかの制限があります。
- 後で説明するように、Dataproc を使用してデータを永続 HDFS クラスタに保持すると、Cloud Storage にデータを保存するよりもコストがかかります。データを HDFS クラスタに保持すると、他の Google Cloud プロダクトでのデータの使用も制限されます。
- 特定のユースケースでは、一部のオープンソース ベースのツールを他の関連する Google Cloud サービスで拡張する、または置き換えるほうが、より効率的もしくは経済的な場合があります。
- 単一の永続的な Dataproc クラスタにすべてのジョブを割り当てると、ジョブまたはジョブ領域ごとに異なるクラスタに移行した場合よりも管理が難しくなります。
Hadoop システムを Google Cloud に移行するための最も費用対効果が高く柔軟な方法は、大規模で多目的かつ永続的なクラスタの観点から考えるのではなく、特定のジョブを実行するように設計された、小規模な短期間のクラスタについて考えることです。この方法では、データを Cloud Storage に保存して、複数の一時的な処理クラスタに対応します。ジョブを処理するクラスタが必要に応じて割り当てられ、ジョブが完了すると解放されるため、このモデルはエフェメラル モデルといわれます。
次の図は、オンプレミス システムから Google Cloud 上のエフェメラル モデルへの仮想移行を示しています。
この例では、2 つのオンプレミス クラスタで実行されている 4 つのジョブを Dataproc に移行しています。Google Cloud でジョブを実行するために使用されるエフェメラル クラスタは、個々のジョブの効率を最大化するために定義されています。最初の 2 つのジョブは同じクラスタを使用し、3 番目と 4 番目のジョブはそれぞれ独自のクラスタで実行されます。ユーザー独自のジョブを移行する場合は、個々のジョブまたはジョブグループに使用されるクラスタをカスタマイズし、それぞれの作業に合わせて最適化できます。Dataproc では、複数のクラスタを定義してオンラインにし、必要に応じて簡単にスケーリングできます。
この例のデータでは、オンプレミスの 2 つの HDFS クラスタから Cloud Storage バケットに移行されています。最初のクラスタのデータは複数のバケットに分割され、2 番目のクラスタは単一のバケットに移行されています。Cloud Storage では、アプリケーションやビジネスのニーズに合わせてデータの構造をカスタマイズできます。
この移行例では、Google Cloud への完全な移行についての開始の状態と終了の状態を表示しています。これは 1 つのステップを意味しますが、Google Cloud への移行が 1 回限りの完全な移行とは考えないほうが、最適な結果を得ることができます。この移行は、オンプレミスではできない方法で新しいツールセットを使用するようにソリューションをリファクタリングする、と考えたほうが良い結果が得られます。このようなリファクタリングを行うために、段階的な移行をおすすめしています。
Google Cloud への移行に推奨される順序
ワークフローを Google Cloud に移行する場合の推奨手順は次のとおりです。
まず、データを移行します。
- データを Cloud Storage バケットに移行します。
- 小規模で始めます。バックアップ データやアーカイブ データを使用し、既存の Hadoop システムへの影響を最小限に抑えます。
テストを行います。
- データのサブセットを使用してテストを行います。ジョブごとに小規模なスケールの概念実証を行います。
- 新しい方法でデータを操作します。
- Google Cloud とクラウド コンピューティングのパラダイムに沿って調整します。
特別なエフェメラル クラスタを検討します。
- できるだけ小さなクラスタを使用します。このクラスタを単一のジョブまたは関連するジョブの小規模なグループに割り当てます。
- ジョブで必要になるたびにクラスタを作成し、処理が完了したらクラスタを削除します。
必要に応じて Google Cloud ツールを使用します。
エフェメラル モデルへの移行
オンプレミスの Hadoop ワークフローと Google Cloud で同じワークフローを実行する方法の最大の違いは、モノリシックな永続クラスタから特殊なエフェメラル クラスタへの移行です。クラスタはジョブの実行が必要になったときにスピンアップされ、ジョブが完了すると削除されます。ジョブに必要なリソースは、ジョブで使用されるときにのみアクティブになるため、実際の使用量に対してのみ課金されます。この方法では、ジョブごとにクラスタ構成を調整できます。永続的なクラスタの維持や構成を行わないため、リソース使用とクラスタ管理のコストを削減できます。
このセクションでは、既存の Hadoop インフラストラクチャをエフェメラル モデルに移行する方法について説明します。
データと計算処理を分離する
ワークフローの永続ストレージとして Cloud Storage を使用すると、次の利点があります。
- アクセス権限の管理が簡単になります。
- Hadoop 互換ファイル システム（HCFS）を採用しているため、既存のジョブで簡単に使用できます。
- 多くの場合、HDFS よりも高速です。
- HDFS よりもメンテナンスが少なくなります。
- HDFS よりもデータの移行が簡単です。
- Google Cloud プロダクト全体でデータを簡単に使用できます。
- 永続 Dataproc クラスタのデータを HDFS に保持するよりも、かなり低コストです。
データを Cloud Storage に永続的に保存すると、Dataproc で管理されるエフェメラル Hadoop クラスタでジョブを実行できます。
場合によっては、データを別の Google Cloud テクノロジー（BigQuery や Bigtable など）に移行するほうが合理的なことがあります。汎用的なデータの大半は Cloud Storage での保存が適しています。別のストレージ オプションの詳細については、このガイドの後半で説明します。
エフェメラル クラスタでジョブを実行する
Dataproc を使用すると、クラスタを簡単に作成および削除できるため、1 つのモノリシック クラスタの使用から多数のエフェメラル クラスタの使用に移行できます。このアプローチにはいくつかのメリットがあります。
- 単一障害点を回避し、データ パイプラインの信頼性を向上させることができます。長時間実行されている共有クラスタがエラー状態になると、データ パイプライン全体がブロックされる可能性があります。長時間実行されているステートフル クラスタの修復には時間がかかる場合があり、サービスレベル目標（SLO）違反が発生します。一方、問題のあるステートレス エフェメラル クラスタは、簡単に削除してジョブの再試行により再作成できます。
- ジョブ間のリソースの競合を排除することで、ジョブのパフォーマンスを予測しやすくなり、SLO 違反を回避できます。
- 個々のジョブのクラスタ構成と自動スケーリング ポリシーを最適化できます。
- ジョブのエフェメラル クラスタを作成すると、最新のセキュリティ パッチとバグの修正を取得し、最適化できます。
- ディスクがログや一時ファイルでいっぱいになる、クラスタがゾーンの容量不足によりスケールアップに失敗するなど、長時間実行されているクラスタでよく発生する問題を回避できます。
- エフェメラル クラスタは使用するたびに構成されるため、クラスタを常時維持する必要はありません。クラスタを維持する必要がないため、ジョブ間でツールを管理する負担がなくなります。
- 開発、テスト、本番環境用に別々のインフラストラクチャを用意する必要はありません。同じ定義を使用して、必要に応じて必要な種類のクラスタを作成できます。
- 分離された単一ジョブクラスタを使用して、問題をより迅速にトラブルシューティングできます。
- ジョブで使用したリソース量に対してのみ課金されます。
Dataproc の初期化アクションを使用して、クラスタ内のノードの構成を定義できます。個々のジョブや関連するジョブグループに合わせて異なるクラスタ構成を簡単に維持できます。また、初期化アクションのサンプルも用意されています。このサンプルを使用して、独自の初期化アクションを作成できます。
エフェメラル クラスタのライフタイムを最小にする
エフェメラル クラスタで重要なポイントは、ジョブの存続期間にのみ使用することです。 ジョブの実行プロセスは次のようになります。
適切な構成でクラスタを作成します。
ジョブを実行し、出力を Cloud Storage または別の永続的な場所に送信します。
クラスタを削除します。
必要に応じてジョブの出力を使用します。
Cloud Logging または Cloud Storage でログを表示します。
このプロセスを図にすると、次のようになります。
必要なときに小規模な永続クラスタを使用
永続クラスタがないとジョブを実行できない場合は、永続クラスタを作成できます。ただし、このオプションはコストが高くなる可能性があり、エフェメラル クラスタでジョブを実行できる場合はおすすめしません。
永続クラスタのコストを最小限に抑えるには、次のような方法があります。
- 可能な限り小規模なクラスタを作成する。
- 可能な限り少数のジョブをクラスタに割り当てる。
- 実行可能な最小ノード数でクラスタを作成し、必要に応じて動的にスケーリングする。
段階的な移行
段階的な移行には多くの利点があります。次のことが可能です。
- 既存の Hadoop インフラストラクチャの個々のジョブを複雑な環境から解放できます。
- ジョブを個別に調査し、最適な移行パスを判断できます。
- 予期しない問題が発生しても、依存するタスクを遅らせることなく、対処できます。
- 本番環境に影響を与えることなく、複雑なプロセスごとに概念実証を実施できます。
- 推奨のエフェメラル モデルにワークロードを慎重に移行できます。
移行は Hadoop 環境に固有のものです。すべての移行シナリオに適合する普遍的な計画はありません。クラウド コンピューティングのパラダイムに各要素を柔軟に切り替えられるように、移行計画を作成してください。
標準的な移行手順は次のようになります。
データの一部を Google Cloud に移動します。
移行したデータでテストを行います。
このデータを使用する既存のジョブを複製します。
このデータを使用する新しいプロトタイプを作成します。
データを追加して、上記の手順を繰り返します。
重要でないデータから移行を始めてください。初期段階では、バックアップ データとアーカイブを使用することをおすすめします。
リスクの低いテストとしてはバックフィルがあります。アーカイブ データでバースト処理を実行します。現在のジョブの前に存在していたデータを埋め戻すジョブを設定します。 バーストジョブから始めると、多くの場合、移行計画の早い段階で Google Cloud でのスケーリングを体験できます。これは、より重要なジョブの移行を行うときに役立ちます。
次の図は、一般的なバックフィル ハイブリッド アーキテクチャを示しています。
この例は 2 つの部分から構成されています。まず、オンプレミス クラスタで実行されているスケジュールされたジョブが、インターネット ゲートウェイ経由で Cloud Storage にデータを push します。次に、バックフィル ジョブはエフェメラル Dataproc クラスタで実行されます。バックフィルに加えて、Google Cloud のエフェメラル クラスタを試験運用版として使用して、概念実証を作成できます。
完全な移行を前提にした計画
これまでのところでは、このガイドでは、Hadoop システム全体をオンプレミスから Google Cloud に移行することが目標であると想定しています。完全に Google Cloud で実行されている Hadoop システムは、クラウドとオンプレミスの両方で動作するシステムよりも管理が簡単です。しかし、ビジネスニーズや技術的な制約のため、ハイブリッド アプローチが必要になることも少なくありません。
ハイブリッド ソリューションの設計
ハイブリッド ソリューションは次のような場合に必要になります。
- クラウド ネイティブのシステムを開発中で、開発が完了するまで既存のシステムをオンプレミスで実行しなければならない場合。
- ビジネス要件で、データをオンプレミスに保管することが必要な場合。
- オンプレミスで実行される他のシステムとデータを共有する必要があり、それらのシステムは技術的またはビジネス上の制限により Google Cloud とやり取りできない場合。
標準的なハイブリッド ソリューションは次の 4 つの部分から構成されます。
オンプレミスの Hadoop クラスタ。
オンプレミス クラスタから Google Cloud への接続。
Google Cloud で一元化されたデータ ストレージ。
Google Cloud のデータを処理するクラウドネイティブなコンポーネント。
ハイブリッド クラウド ソリューションでは、システムの同期を維持することが重要な課題となります。データに対する変更が他の場所に反映されていることを、どのように確認すればよいでしょうか。別の環境でデータがどのように使用されているかを把握することで、同期を簡単に行うことができます。
たとえば、アーカイブ データのみを Google Cloud に保存するハイブリッド ソリューションがあるとします。データが指定された時点に達したときに、オンプレミス クラスタから Google Cloud にデータを移動するようにスケジュールされたジョブを設定できます。その後、Google Cloud でアーカイブされたデータを処理するすべてのジョブを設定すれば、オンプレミス クラスタへの変更を同期する必要がなくなります。
システムを分割するもう 1 つの方法は、他の作業をオンプレミスに維持しながら、特定のプロジェクトまたは作業グループのすべてのデータと作業を Google Cloud に移行することです。この場合、複雑なデータ同期システムを作成する必要はなく、ジョブに集中できます。
セキュリティやロジスティクスの点で、オンプレミス クラスタを Google Cloud に接続する方法が問題になる場合があります。その解決策の一つは、Cloud VPN を使用してオンプレミス ネットワークに接続された Virtual Private Cloud を使用することです。
次の図は、ハイブリッド クラウドの設定例を示しています。
この設定例では、Cloud VPN を使用して Google Cloud VPC をオンプレミス クラスタに接続しています。システムは、VPC 内の Dataproc を使用して、オンプレミス システムからのデータを処理する永続クラスタを管理します。この方法では、システム間のデータ同期が必要な場合もあります。これらの永続 Dataproc クラスタも、オンプレミス システムからのデータを Google Cloud の適切なストレージ サービスに転送します。この例では、Cloud Storage、BigQuery、Bigtable をストレージとして使用しています。これらは、Google Cloud の Hadoop ワークロードによって処理されるデータの最も一般的な宛先です。
サンプル ソリューションの残りの半分では、複数のエフェメラル クラスタが使用されています。これらは、必要に応じてパブリック クラウドで作成されます。これらのクラスタは、新しいデータの収集や変換など、多くのタスクで使用されます。これらのジョブの結果は、VPC で実行されているクラスタと同じストレージ サービスに保存されます。
クラウド ネイティブ ソリューションの設計
一方、クラウド ネイティブなソリューションは簡単です。Cloud Storage に保存されているデータを使用して Google Cloud ですべてのジョブを実行するため、データ同期の複雑さを完全に回避できますが、異なるジョブが同じデータを使用する方法については注意が必要です。
次の図は、クラウド ネイティブなシステムの例を示しています。
このシステムでは、いくつかの永続クラスタとエフェメラル クラスタを使用しています。どちらのクラスタも、ストレージやモニタリング サービスなどクラウドツールとリソースを共有しています。Dataproc は、標準化されたマシンイメージを使用して、クラスタ内の VM のソフトウェア構成を定義します。これらの定義済みイメージは、必要な VM 構成のベースとして使用できます。この例では、永続クラスタの大半がバージョン 1.1 で実行され、1 つのクラスタがバージョン 1.2 で実行されています。必要であれば、新しいクラスタを作成し、VM インスタンスをカスタマイズできます。これにより、重要な本番環境のデータやジョブからテスト環境と開発環境を分離できます。
この例のエフェメラル クラスタでは、さまざまなジョブが実行されます。この例では、Compute Engine で実行されている Apache Airflow を使用して、エフェメラル クラスタによる作業をスケジュール設定する方法を示しています。
Google Cloud サービスとの連携
このセクションでは、Hadoop を Google Cloud に移行する際のその他の考慮事項について説明します。
オープンソース ツールを Google Cloud サービスに置き換える
Google Cloud には、Hadoop システムで使用できるさまざまなプロダクトが用意されています。Google Cloud プロダクトを使用すると、同等のオープンソース プロダクトを Google Cloud で実行するよりも多くのメリットが得られます。プラットフォームが提供するさまざまな機能について、Google Cloud のプロダクトとサービスの詳細をご確認ください。
リージョンとゾーンの使用
データとジョブを構成する際は事前に、地域とリージョンの影響を理解しておく必要があります。多くの Google Cloud サービスでは、リソースを割り当てるリージョンまたはゾーンを指定する必要があります。リソースが格納されているリージョンと異なるリージョンからリクエストが送信されると、リクエストのレイテンシが長くなる可能性があります。また、サービスのリソースと永続データが異なるリージョンにある場合、Google Cloud サービスの呼び出しによっては、必要なデータがゾーン間でコピーされることがあります。これは、パフォーマンスに深刻な影響を与える可能性があります。
認証と権限の構成
Google Cloud サービスでの権限の制御は、オンプレミスの Hadoop 環境に慣れている場合よりもきめが荒くなる可能性があります。移行を開始する前に、Google Cloud でのアクセス管理の仕組みを理解しておいてください。
Identity and Access Management（IAM）は、クラウド リソースへのアクセスを管理します。これは、アカウントとロールに基づいてアクセスを制御します。アカウントによってユーザーまたはリクエストを識別（認証）し、アカウントに付与されたロールにより、アクセスレベルを決定（認可）します。ほとんどの Google Cloud サービスには、権限の微調整に役立つ独自のロールセットが用意されています。移行についての計画作成の一環として、IAM が Cloud Storage および Dataproc と連携する仕組みについて確認する必要があります。システムに追加する各 Google Cloud サービスの権限モデルについて学習し、使用するサービス全体で機能するロールをどう定義するかを検討してください。
Cloud Logging によるジョブのモニタリング
Google Cloud ジョブは Cloud Logging にログを送信します。このログには簡単にアクセスできます。これらのログは次の方法で取得できます。
- Google Cloud コンソールのログ エクスプローラを使用したブラウザベースのグラフィカル インターフェース。
- Google Cloud CLI を使用した、ローカルのターミナル ウィンドウ。
- Cloud Logging API 用の Cloud クライアント ライブラリを使用した、スクリプトまたはアプリケーション。
- Cloud Logging REST API の呼び出し。
Compute Engine でのエッジノードの管理
Compute Engine を使用して、Dataproc Hadoop クラスタ内のエッジノードにアクセスできます。ほとんどの Google Cloud プロダクトと同様に、ウェブベースのコンソール、コマンドライン、ウェブ API など、複数の管理オプションがあります。
Google Cloud ビッグデータ サービスの使用
Cloud Storage は、Google Cloud に非構造化データを保存するための主要な方法ですが、他にもストレージ オプションはあります。データによっては、ビッグデータ用に設計されたストレージが適している場合もあります。
Bigtable を使用すると、大量のスパースデータを格納できます。Bigtable は、ジョブに応じて低レイテンシと高度なスケーラビリティを実現できる HBase 準拠の API です。
データ ウェアハウスには BigQuery を使用できます。
次のステップ
Hadoop 移行ガイドの他のパートを確認する。
Dataproc のドキュメントを確認する。
Google Cloud の概要を確認する。
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。