このガイドでは、Dataproc を使用して Apache Hadoop ジョブを Google Cloud に移行する方法について説明します。
これは、オンプレミス Hadoop からの移行方法を説明する 3 つのガイドのうちの 3 番目です。
- オンプレミスの Hadoop インフラストラクチャの Google Cloud への移行では、移行プロセスの概要を示し、特に大規模な永続的クラスタからエフェメラル モデルへの移行について詳しく説明しています。
- オンプレミスから Google Cloud への HDFS データの移行では、データを Cloud Storage や他の Google Cloud プロダクトに移行するプロセスを説明しています。
- このガイドでは、Hadoop ジョブを Dataproc に移行する方法に重点を置いて説明します。
Google Cloud での Hadoop ジョブの実行
Dataproc を使用すると、Google Cloud でほとんどの Hadoop ジョブを実行できます。次のリストは、基本的な手順をまとめたものです。
Cloud Storage に保存された永続データを指すようにジョブを更新します。
ジョブを実行する Dataproc クラスタを作成します。この種の一時的な 1 回限りのクラスタは、エフェメラル クラスタと呼ばれます。
エフェメラル クラスタにジョブを送信します。
必要に応じて、ジョブのログのモニタリングを Cloud Logging または Cloud Storage を使用して行います。デフォルトでは、クラスタの作成時に指定したステージング バケットを使用して、ログが Cloud Storage にキャプチャされます。
Cloud Storage でジョブの出力を確認します。
ジョブが完了したら、クラスタを削除します。
サポートされているジョブ
Dataproc は Hadoop を実行するため、多くの種類のジョブが自動的にサポートされます。Dataproc を使用してクラスタを作成すると、次のテクノロジーがデフォルトで構成されます。
- Hadoop
- Spark
- Hive
- Pig
Dataproc には、さまざまなマシンイメージのバージョンが用意されており、さまざまなバージョンのオープンソース ソフトウェアがプリインストールされています。イメージにあらかじめ構成されたソフトウェアだけで、多くのジョブを実行できます。一部のジョブでは、他のパッケージをインストールする必要があります。Dataproc には、初期化アクションと呼ばれるメカニズムが用意されています。このメカニズムを使用すると、クラスタのノードで実行されているソフトウェアをカスタマイズできます。初期化アクションを使用して、作成されたすべてのノードで実行されるスクリプトを作成できます。
データ ロケーション（URI）の更新
Dataproc クラスタノードにあらかじめインストールされている Cloud Storage コネクタを使用すると、Cloud Storage を Hadoop 互換ファイル システム（HCFS）としてジョブを実行できます。データを Cloud Storage に格納すると、このコネクタを利用できます。その場合、ジョブに加える変更は、URI の更新、つまり hdfs:// を gs:// に置き換えるだけです。
移行の一環としてデータを再編成する場合は、新しいデータ編成で作業するためにジョブを簡単に更新できるように、すべての移行元と移行先のパスをメモします。
HDFS のデータをクラウドの永続クラスタに格納することは可能ですが、これはおすすめしません。データの移行については、データ移行ガイドをご覧ください。
ジョブを実行するクラスタの構成
Google Cloud でジョブを実行するための推奨アプローチでは、必要なときにエフェメラル クラスタを作成し、ジョブの終了時にそれらを削除します。このアプローチでは、クラスタの構成方法が非常に柔軟です。ジョブごとに異なる構成を使用することも、ジョブのグループに対応する複数の標準的なクラスタ構成を作成することもできます。
クラウドを作成するための基本的な手順については、Dataproc のドキュメントをご覧ください。このセクションの残りの部分では、作業の進め方を決定する際に有用な、クラスタ構成における重要性の高い考慮事項のいくつかについて説明します。
クラスタのサイズ変更
新しいクラスタを定義するために最初に行う必要があるのは、使用する仮想ハードウェアを決定することです。各ジョブには特定のニーズと特異性があるため、完全なクラスタ構成を計算するのが難しい場合があります。さまざまな構成を試して、ジョブに適した構成を見つけてください。
クラスタを設定するときには、少なくとも次のことを判断する必要があります。
- 使用するノード数。
- プライマリ（マスター）ノードに使用する仮想マシンのタイプ。
- ワーカーノードに使用する仮想マシンのタイプ。
ノードタイプは、仮想 CPU の数と使用可能なメモリの量によって定義されます。この定義は、Compute Engine のマシンタイプに対応しています。通常は、移行元のオンプレミス ノードの構成に対応するノードタイプを見つけることができます。この同等性をもとに、オンプレミス クラスタに類似したクラスタを設定できます。この場合の最善の方法は、構成を調整し、ジョブの実行に対する影響を監視することです。ジョブ構成の最適化を開始すると、システム内で追加のジョブにアプローチする方法がわかり始めます。
必要に応じてクラスタを拡張できるので、最初から完全な仕様を定義する必要はありません。
プライマリ ディスク オプションの選択
ワーカーノードで使用するプライマリ ディスクのサイズを指定できます。クラスタに対する適切なオプションは、実行するジョブの種類によって異なります。ジョブでプライマリ ディスクの使用に対する要求が異常な場合を除き、デフォルト値を使用して結果を評価します。
ジョブでディスク領域を大量に使用し、個々のノードでの実行速度が遅い場合は、プライマリ ディスク領域を追加できます。特にディスク領域を大量に使用するジョブや、個々の読み書き操作が大量であるジョブの場合、ローカル SSD を追加することで操作性を向上させることができます。ローカル実行に必要な領域のすべてを確保するのに十分な SSD を追加します。ローカル実行ディレクトリは、追加した多数の SSD にまたがっています。
プリエンプティブル ワーカー ノードの使用
プリエンプティブル ワーカー ノードをクラスタに追加することで、低コストでジョブの処理能力を向上させることができます。これらのノードでは、プリエンプティブ仮想マシンを使用します。
プリエンプティブル ノードの使用を選択する前に、プリエンプティブル ノードの本質的な信頼性を考慮してください。Dataproc はプリエンプションをスムーズに処理しようとしますが、ノードが多すぎるとジョブが失敗する可能性があります。フォールト トレラントであるか、まれに失敗してもビジネスに支障をきたさないような優先度の低いジョブに対しては、プリエンプティブル ノードのみを使用してください。
プリエンプティブル ワーカー ノードを使用する場合は、通常ノードとプリエンプティブル ノードの比率を考慮してください。最良の結果を得るための普遍公式はありませんが、一般的に、標準ノードよりも優先ノードを多く使用すればするほど、ジョブで作業を完了するためのノードが不足する可能性が高くなります。さまざまな比率で試し、結果を分析することで、ジョブの通常ノードに対するプリエンプティブル ノードの最適な比率を判断できます。
SSD はプリエンプティブル ワーカー ノードでは使用できません。専用ノードで SSD を使用する場合、使用するプリエンプティブル ワーカー ノードは専用ノードの他のすべての側面と一致しますが、使用可能な SSD はありません。
ジョブの実行
Dataproc では、ジョブを起動するために使用できるインターフェースが複数提供されています。これらのインターフェースはすべてプロダクト ドキュメントに記載されています。このセクションでは、Google Cloud で Hadoop ジョブを実行する際に考慮すべきオプションと操作について説明します。
ジョブの出力の取得
Dataproc で実行するジョブには、通常、いくつかのタイプの出力があります。たとえば、Cloud Storage バケット内のファイルや、BigQuery などの Cloud プロダクトに、さまざまな出力を直接書き込むことができます。Dataproc ではログとコンソールの出力を収集し、ジョブを実行するクラスタに関連付けられた Cloud Storage ステージング バケットに格納します。
再実行可能なジョブの使用
ジョブを送信するときに、問題が発生した場合に自動的に再起動するように設定できます。このオプションは、変動が大きいリソースや状況に依存するジョブに役立ちます。たとえば、信頼できない可能性のあるチャネル（公共のインターネットなど）を介してデータをストリーミングするジョブは、タイムアウト エラーや同様のネットワークに関するのために、偶発的な障害が非常に起こりやすくなります。ジョブが失敗しても、少し時間が経過した後で正常に実行される状況が容易に想像できる場合は、ジョブを再実行可能として実行します。
クラスタのスケーリング
Dataproc を使用すると、ジョブの実行中も含め、いつでもクラスタのノードを簡単に追加または削除できます。Dataproc のドキュメントには、クラスタを拡張するための詳しい手順が記載されています。スケーリングには、ノードを正常にデコミッションするオプションが含まれます。このオプションを使用すると、削除されるノードに対して進行中の処理を完了するための時間が与えられます。
時系列でジョブを管理
個々のジョブを処理することは、通常は複雑ではありませんが、1 つの Hadoop システムに含まれるジョブが数十あるいは数百に達することもあります。時間の経過とともに、ログ、出力ファイル、および各ジョブに関連するその他の情報の数が増加し、個々の情報を見つけることが困難になります。将来的にジョブを管理しやすくするためにできることはいくつかあります。
- カスタムラベルを使用して、ジョブ、クラスタ、その他のリソースを識別します。ラベルを使用すると、後でフィルタを使用してリソースを見つけることが容易になります。Dataproc では、標準の Google Cloud ラベルシステムを使用したカスタムラベルをサポートしているため、リソースにラベルを付けると、そのリソースを他の Google Cloud サービスでも管理しやすくなります。
- Cloud Storage バケットを整理して、さまざまなタイプのジョブを区別します。ビジネスの構造や部門に対応するバケットにデータをグループ化すると、権限の管理が容易になります。
- 個々のジョブまたは密接に関連するジョブグループのクラスタを定義します。ジョブのスコープが適切に定義されていて、それらのジョブにのみ個別のクラスタ構成を使用する場合は、エフェメラル クラスタの設定を更新する方がはるかに簡単です。
次のステップ
Hadoop 移行ガイドの他のパートを確認する。
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。