このガイドでは、オンプレミスの Hadoop 分散ファイル システム（HDFS）から Google Cloud にデータを移行するプロセスについて説明します。
次のように、オンプレミス Hadoop からの移行方法を 4 回に分けて説明します。これはその 2 番目のガイドです。
- オンプレミスの Hadoop インフラストラクチャの Google Cloud への移行では、移行プロセスの概要を示し、特に大規模な永続的クラスタからエフェメラル モデルへの移行について詳しく説明しています。
- 本ガイド。データを Google Cloud に移行する方法を重点的に説明しています。
- HBase から Bigtable へのデータの移行
- オンプレミスから Dataproc への Hadoop ジョブの移行では、Dataproc や他の Google Cloud プロダクトでジョブを実行するプロセスについて説明します。
データの移行計画
以下のセクションでは、オンプレミスの HDFS から Google Cloud へのデータ移行を計画する際のベスト プラクティスについて説明します。移行作業を段階的に行うことを計画してください。これにより、各データボディの移行後にジョブの移行、テストを行う時間を確保できます。
データの移行方法を決める
HDFS データをクラウドに転送する際に考慮すべき移行モデルには、push と pull の 2 種類があります。どちらのモデルでも、Hadoop DistCp を使用してオンプレミスの HDFS クラスタから Cloud Storage にデータをコピーしますが、それぞれのモデルで採用されているアプローチは異なります。
最も単純なモデルは、push モデルです。このモデルでは、ソースクラスタがそのデータノードで distcp ジョブを実行し、ファイルを直接 Cloud Storage に push します（以下の図を参照）。
pull モデルはより複雑ですが、いくつかの利点があります。このモデルでは、Dataproc のエフェメラル クラスタがそのデータノードで distcp ジョブを実行し、ソースクラスタからファイルを pull して Cloud Storage にコピーします（以下の図を参照）。
push モデルが最も単純なモデルである理由は、ソースクラスタがデータを直接 Cloud Storage に push できるため、コピーを実行するための追加のコンピューティング リソースを作成する必要がないためです。ただし、移行中、他の通常のデータ処理ジョブのためにソースクラスタの使用を継続することを予定している場合は、コピージョブも実行できるだけの十分なリソース（CPU、RAM、ネットワーク帯域幅など）がソースクラスタにあることを確認する必要があります。
ソースクラスタがすでにコンピューティング容量いっぱいで実行しており、ソースクラスタでコピーを実行するためのリソースを増加できない場合は、代わりに pull モデルの使用を検討する必要があります。
pull モデルは push モデルよりも複雑ですが、さまざまな利点があります。
- ソースノードはクラスタからブロックを提供するためだけに使われるため、ソースクラスタの CPU および RAM リソースに対する影響が最小限になります。Google Cloud で、コピージョブを処理するために pull クラスタのリソース仕様を微調整し、移行が完了したら pull クラスタを破棄することもできます。
- ソースクラスタのネットワーク上のトラフィックが削減されるため、より多くのアウトバウンド帯域幅が使用可能になり、転送速度が向上します。
- Dataproc のエフェメラル クラスタとしてのソースクラスタに Cloud Storage コネクタをインストールする必要はありません。ソースクラスタにすでにインストールされているコネクタが、Cloud Storage へのデータ転送を処理します。
両方のモデルでのネットワーク使用量の影響を理解するには、Hadoop が HDFS でデータ レプリケーションを処理する方法を考えてください。Hadoop は各ファイルを複数のブロックに分割します（ブロックのサイズは通常、128～256 メガバイトです）。Hadoop はこれらのブロックを複数のデータノードと複数のラックにわたって複製することで、データノードやラックで障害が発生してもデータが失われないようにします。標準構成では、ブロックごとに 3 つのレプリカが格納されます。
Hadoop ではさらに、「ラック認識」機能も採用しています。ラック認識機能は、各ブロックの 2 つのコピーを同じラック内の異なるデータノードに格納してレイテンシを短縮し、3 つ目のコピーを別のラックに格納して冗長性と可用性を高めます。次の図に、このレプリケーション ロジックの概要を示します。
push モデルを使用してファイルをコピーする場合、つまり、distcp マップタスクをソースクラスタのデータノードで実行する場合は、まず、さまざまなデータノードからファイルのすべてのブロックが収集されます。収集されたファイルのブロックが、ソースクラスタから Cloud Storage に push されます。この場合、次の図に示すように、ネットワーク上のトラフィックはファイルの合計サイズの約 2 倍近くになることがあります。
pull モデルを使用してファイルをコピーする場合、つまり、distcp マップタスクが Google Cloud 内の pull クラスタのデータノードで実行される場合は、ブロックはソースクラスタから直接送られるため、ネットワークを通過するのは一度だけとなります。したがって、次の図に示すように、ネットワーク全体のトラフィックはファイルの合計サイズに制限されます。
pull モデルを使用する場合は、多数の並列接続によってソースクラスタに負担がかからないよう、distcp マップタスクの数と帯域幅の使用量をモニタリングする必要があります。
データの移動先を決める
Hadoop の最終的な移行先は、クラウド ネイティブのソリューションまたはハイブリッド ソリューションになります。これらの違いは、オンプレミス コンポーネントを残すかどうかにあります。クラウド ネイティブのソリューションでは、クラウドにデータを格納し、そこでデータを処理します。ハイブリッド ソリューションでは、データの一部がオンプレミスに残ります。この場合、オンプレミスのデータにジョブを実行したり、オンプレミス データを扱うジョブをクラウドで実行したりします。
クラウド ネイティブのソリューションは管理が簡単ですが、ビジネスまたは技術的な条件で、データや処理をオンプレミスに残す必要があることもあります。ハイブリッド ソリューションの場合、ワークロードを処理する技術とプロダクトの組み合わせも、それぞれの環境によって異なります。
Cloud Storage 以外のプロダクトにデータを移行する場合
ほとんどのデータを Cloud Storage に移動します。ただし、別の Google Cloud プロダクトにデータを移行したほうがよい場合もあります。
Apache HBase からデータを移行する場合は、同等の機能を提供する Bigtable への移行を検討してください。
Apache Impala からデータを移行する場合は、同等の機能を提供する BigQuery への移行を検討してください。
HBase または Impala に、Bigtable や BigQuery に保存しなくても使用できるデータが存在する場合もあります。ジョブで Bigtable や BigQuery の機能が必要ない場合は、Cloud Storage にデータを保存してください。
権限を考慮してデータの場所を計画する
Google Cloud では、オンプレミスの HDFS と異なり、ファイルに対する権限をきめ細かく設定できません。ファイルへのアクセス許可は、Cloud Storage バケットレベルで設定するのが最も簡単な方法です。HDFS データセットごとに異なる権限を設定している場合は、Cloud Storage で異なる権限を持つバケットを作成することを検���してください。そしてデータに適切な権限を持つバケットに HDFS データを保存します。
ファイルを Cloud Storage と HDFS で異なる構造に移動する場合は、すべての変更を記録してください。Dataproc にジョブを移行する場合は、移行先で正しいデータパスを設定する必要があります。
段階的な移行を計画する
データを段階的に移行するように計画します。データを移行している間に、対応するジョブをクラウドに移行できるように、時間的に余裕のあるスケジュールを設定します。バックアップやアーカイブなど、優先度の低いデータから移行を行います。
データの分割
段階的に移行する場合、データを複数の部分に分割する必要があります。以下のセクションでは、データセットを分割する最も一般的な方法について説明します。
タイムスタンプで分割する
段階的な移行でデータを分割する一般的な方法は、古いデータをクラウドに格納し、新しいデータをオンプレミス システムの HDFS に保存する方法です。これにより、新規に作成するジョブや移行したジョブを重要でない古いデータでテストできます。この方法では、少量のデータから移行を始めることができます。
重要な考慮事項:
- 時間で分割するだけでなく、他の方法でもデータを分割できるか。データをサポート対象のジョブや所有する組織ごとに分割し、さらに時間で分割することで、より絞り込んだデータセットを作成できます。
- 絶対日時を使うか、相対日時を使うか。システムに重要な変更を行う前に生成されたデータをすべてアーカイブするなど、特定の時点でデータを分割するほうがよい場合もあります。古いデータを処理して現在の標準に合わせられるかどうかを確認するために、バック���ィル ジョブを作成してクラウド内のシステムをテストする場合は、絶対日時のほうが適しています。また、現在の日付を基準とするタイムスタンプに基づいて、データをクラウドに移行しなければならない場合もあります。たとえば、1 年以上前に作成されたすべてのデータ、過去 3 か月間に編集されていないすべてのデータを移動する場合などです。
- どのタイムスタンプを優先するのか。ファイルに複数のタイムスタンプが存在することは少なくありません。ファイルの作成日が最も重要な場合も、最終変更日や、ファイルのメタデータに含まれる他のタイムスタンプが重要な場合もあります。
- すべてのデータのタイムスタンプが同じ形式になっているか。タイムスタンプを処理する方法は 1 つではありません。データが複数のソースから提供される場合、タイムスタンプはさまざまな形式で保存されている可能性があります。データを分割する前に、タイムスタンプの形式が一致していることを確認する必要があります。
ジョブで分割する
データを使用するジョブでデータを分割することもできます。この方法は、ジョブを段階的に移行する場合に役立ちます。これにより、移行するジョブで使用されるデータだけを移行できます。
重要な考慮事項:
- クラウドに移行するジョブは自己完結型か。ジョブでの分割は、完結したデータ単位を扱うジョブには最適なオプションですが、処理するデータがシステム全体に分散している場合は管理が難しくなります。
- データの用途が変わる可能性があるか。データを分割する前に、その用途が変わる可能性があるかどうか慎重に検討してください。
- ジョブで分割して移行した場合に、管理しやすいサイズのデータチャンクになるようにスコープされているか。
ジョブだけではなく、より範囲の広い機能的な条件でデータを分割することもできます。たとえば、クラウド内ですべての ETL 作業を実行し、オンプレミスで分析とレポートの作成を行うこともできます。
所有権で分割する
場合によっては、データを所有権で分割することもできます。この方法のメリットは、データ編成と会社の組織図が対応する点です。また、Google Cloud のロールベースのアクセス管理を行うことができます。たとえば、特定のロールで使用されるデータを個別の Cloud Storage バケットに移行すると、権限の設定が簡単になります。
重要な考慮事項:
- オーナーが明確か。通常、所定のデータ項目のメインのオーナーがどのユーザーであるかは明らかですが、頻繁にアクセスするユーザーがそのデータのオーナーではない場合もあります。
- 所有権と併用できる分割基準が他にあるか。所有権で分割した結果、データセットがかなりの大きさになる場合もあります。タスクや時間でさらにデータを分割すると、データセットを絞り込める場合があります。
ハイブリッド ソリューションでデータを同期する
ハイブリッド ソリューションでは、データが Google Cloud とオンプレミス システムの��方からアクセスされる場合があり、これが課題の一つとな��て��ます。両方の環境からデータセットにアクセスする場合は、一方の環境にプライマリ ストレージを置き、もう一方の環境に同期コピーを維持する必要があります。
プライマリ ストレージの場所に関係なく、データの同期は問題になります。データの変更を識別し、対応するコピーに変更を反映させるメカニズムが必要です。矛盾する変更が発生する可能性がある場合は、それらを解決する対策も講じる必要があります。
重要な考慮事項:
- 可能であれば、データのコピーを常に読み取り専用にする。編集される可能性のあるデータが多ければ多いほど、同期方法が複雑になります。
- ハイブリッド ソリューションで保持するデータのコピーは 2 つまでにする。コピーはオンプレミスで 1 つ、Google Cloud 内で 1 つだけ保持します。
Apache Airflow などのテクノロジーを使用すると、データの同期管理が容易になります。
データの移行
以下のセクションでは、データを Google Cloud に移行する際の考慮事項について説明します。
データのアクセス権を構成する
ファイル権限の機能は Cloud Storage と HDFS で異なります。データを Cloud Storage に移動する前に、Identity and Access Management（IAM）をよく理解しておく必要があります。
アクセス制御を行う最も簡単な方法は、アクセス要件に基づいてデータを個々の Cloud Storage バケットに入れて並べ替え、バケットレベルで認可ポリシーを構成することです。個々のユーザーまたはグループに役割を割り当て、アクセス権を付与できます。ここでは、グループにアクセス権を付与し、必要に応じてグループにユーザーを割り当てます。Cloud Storage にデータをインポートして構造化する前に、データのアクセス方法を決めておく必要があります。
Google Cloud プロダクトには独自の権限とロールがあります。Cloud Storage と Dataproc ではアクセス管理の方法が異なります。各プロダクトのポリシーは個別に評価する必要があります。プロダクト間で役割と権限が直接マッピングされているわけではありません。
クラウドベースの Hadoop システムのポリシーを決める前に、次のドキュメントをよくお読みください。
Cloud Storage で個々のファイルにさらに細かい権限を割り当てる必要がある場合は、アクセス制御リスト（ACL）を使用できます。ただし、おすすめのオプションは IAM です。権限が特に複雑な場合のみ、ACL を使用してください。
DistCp を使用して Cloud Storage にデータをコピーする
Cloud Storage は Hadoop 互換のファイル システムを使用しているので、Hadoop DistCp を使用してオンプレミスの HDFS から Cloud Storage にデータを移動できます。DistCp では、いくつかの方法でデータを移動できますが、次の方法をお��すめします。
Cloud Interconnect または Cloud VPN を使用して、オンプレミス ネットワークと Google ネットワークの間にプライベート リンクを確立します。
データ転送に使用する Dataproc クラスタを作成します。
Google Cloud CLI を使用して、クラスタのマスター インスタンスに接続します。次に例を示します。
gcloud compute ssh [CLUSTER_NAME]-mCLUSTER_NAMEは、ジョブに作成した Dataproc クラスタの名前です。接尾辞-mはマスター インスタンスを表します。クラスタのマスター インスタンスで、DistCp コマンドを実行してデータを移動します。
データの移動に必要な実際の DistCp コマンドは、次のようになります。
hadoop distcp hdfs://nn1:8020/20170202/ gs://bucket/20170202/
この例での nn1 と 8020 は、ソースデータが保存されている NameNode とポートです。bucket はファイルのコピー先 Cloud Storage バケットの名前です。
Cloud Storage トラフィックは、デフォルトで Transport Layer Security（TLS）によって暗号化されます。
データ転送の検証
個別のストレージ システム間（たとえば、複数の HDFS クラスタ間）や、HDFS と Cloud Storage の間でデータをコピーまたは移動する際は、データの整合性を保証するために、なんらかの検証を行うことをおすすめします。データが転送中に改ざんされていないことを確実にするためには、こうした検証が不可欠です。詳しくは、データ転送の検証に関するガイドをご覧ください。
リクエスト レートを増やしていく
Cloud Storage はオブジェクトの一覧表示で整合性を保つために、バケットごとにオブジェクト キーのインデックスを維持します。このインデックスは辞書順に並べ替えられて格納され、オブジェクトがバケットに書き込まれたり、バケットから削除されたりするたびに更新されます。オブジェクトのキーはすべてインデックスの小さな範囲内にあるため、オブジェクトの追加や削除により競合が発生する可能性は必然的に高まります。
Cloud Storage はこのような競合を検知し、影響を受けるインデックスの範囲の負荷を複数のサーバーに自動的に再分散します。新しい接頭辞でオブジェクトを書き込む場合���1 秒あたりの書き込みリクエスト数がリクエスト レートの 1,000 件を超えることが見込まれるとしたら、Cloud Storage ドキュメントの説明に従ってリクエスト レートを徐々に増やしてください。そうしないと、レイテンシやエラーレートが一時的に高まる可能性があります。
データの移行速度を向上させる
オンプレミス クラスタから Google Cloud にデータを転送する最も簡単な方法は、パブリック インターネット経由で VPN トンネルを使用する方法です。1 つの VPN トンネルで必要なスループットが得られない場合は、複数の VPN トンネルを作成します。これにより、Google Cloud がトラフィックを自動的にトンネルに分散するので、使用可能な帯域幅が増えます。
ただし、複数の VPN トンネルでも十分な帯域幅や接続の安定性が得られないことがあります。ス���ープットを向上させるため、以下の方法を検討してください。
ネットワークと Google のエッジ接続拠点（PoP）間でダイレクト ピアリングを使用する。これにより、ネットワークと Google Cloud 間のホップ数が減ります。
Cloud Interconnect サービス プロバイダを使用して、Google のネットワークと直接接続する。サービスの詳細はパートナーごとに異なります。ほとんどの場合、ネットワークの可用性とパフォーマンスに対する SLA が提供されます。詳細については、サービス プロバイダに直接お問い合わせください。
Google Cloud パートナーとの連携
Google Cloud は、データの移行を支援する多くのパートナーと協力しています。データ移行に役立つサービスの詳細については、Cloud Storage をサポートするパートナーをご覧ください。利用可能なサービスと利用規約はプロバイダによって異なります。詳細については、プロバイダに直接ご確認ください。
次のステップ
Hadoop 移行ガイドの他のパートを確認する。
Cloud Storage に関する詳細
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。