ワークロードを Hadoop クラスター (旧 EMR コンソール) から DataLake クラスター (新しい EMR コンソール) に移行します。新しい EMR コンソールは、次世代のクラウドネイティブなオープンソースビッグデータプラットフォームです。DataLake、Dataflow、OLAP、カスタムといった新しいクラスタータイプを提供します。DataLake クラスターは、Hadoop クラスターのアップグレードバージョンです。移行パスは、クラスターバージョン、メタデータストレージタイプ、およびデータストレージ方法の 3 つの要因によって決定されます。
前提条件
開始する前に、以下を確認してください。
-
旧 EMR コンソールと新しい EMR コンソールの両方へのアクセス
-
クラスターを作成およびリリースする権限
-
旧クラスターで使用されているメタデータストレージタイプ、データストレージアーキテクチャ、およびスケジューリングシステムを特定済みであること
事前準備
旧クラスターの評価
移行前に、現在のビッグデータアーキテクチャを分析します。以下を特定し、記録します。
-
サービスとバージョン: 旧クラスターで実行されているすべてのサービスとそのバージョンをリストアップします。これにより、アップグレードの互換性と必要な機能更新が決定されます。
-
メタデータストレージタイプ: 旧クラスターが Data Lake Formation (DLF) またはセルフマネージド ApsaraDB RDS データベースのどちらを使用しているかを判断します。これにより、メタデータ移行パスが決まります。
-
データストレージアーキテクチャ: データがローカルの Hadoop 分散ファイルシステム (HDFS)、Object Storage Service (OSS)、またはブロックモードの JindoFS のいずれに保存されているかを特定します。これにより、データ移行方法が決まります。
-
ユーザー認証: OpenLDAP、Ranger、または Kerberos がデプロイされているかを確認します。新しいクラスターがこれらのセキュリティ構成をどのように継承するかを計画します。
-
スケジューリングシステム: 移行中のタスク継続性を維持するために、開発およびスケジューリングプラットフォームを特定します。
複数の旧クラスターを移行する場合は、業務継続性を維持するために、一度に 1 つずつ移行します。
インスタンス構成の収集
EMR on ECS ページのクラスターの 基本情報 タブと ノード タブで、旧クラスターのハードウェアおよびソフトウェア構成を表示します。以下を記録します。
| 構成タイプ | 記録する項目 | 目的 |
|---|---|---|
| ソフトウェア | クラスターバージョン、サービスバージョン、利用中のコンポーネント、Hive メタデータストレージタイプ | 新しいクラスターの互換性のあるバージョンを決定 |
| ハードウェア | ゾーン、ノードグループ仕様、および課金方法 | 新しいクラスターでハードウェアをレプリケートまたは最適化 |
(オプション) サービス構成のエクスポート
旧クラスターにカスタマイズされたサービス構成がある場合は、それらをエクスポートして、手動で再構成するのではなく、作成時に新しいクラスターに適用できるようにします。
-
構成をエクスポートします。「サービス構成のエクスポートとインポート」に従って構成ファイルをエクスポートします。エクスポートされたファイルには、次のパラメーターが含まれます。
エクスポート時には、次の制約事項に注意してください。- 構成ファイルの選択: 編集済みのファイルのみを選択します。- エクスポートモード: Hadoop クラスターの場合、これを カスタムまたは変更された構成のみをエクスポート に設定することはできません。- エクスポート形式: 新しいクラスターへの直接インポートを有効にするには、JSON を選択します。
パラメーター 説明 ApplicationName サービス名 ConfigFileName 構成ファイル名 ConfigItemKey 構成項目キー ConfigItemValue 構成項目値 -
エクスポートされたファイルをレビューし、クリーンアップします。新しい環境に適用されない構成を削除します。
-
YARN リソースパラメーター: 新しいクラスターの実際のハードウェア仕様に合わせて値を調整します。
-
JindoFS 認証情報プロバイダー: JindoFS 固有の認証情報設定を OSS または OSS-HDFS 構成に置き換えます。「OSS または OSS-HDFS の認証情報プロバイダーの構成」をご参照ください。
-
-
クリーンアップされた構成ファイルを、新しいクラスターを作成する際のプリセット構成として使用します。「このガイドの後半の (オプション) カスタムソフトウェア構成」をご参照ください。
(オプション) ブートストラップアクションのレビュー
旧クラスターにブートストラップアクションスクリプトが構成されているかを確認します。構成されている場合は、新しいクラスターで使用する前に各スクリプトを評価します。
-
JAR パッケージ名とパスを、新しいコンソールのファイルの場所と一致するように更新します。「よく使用されるファイルのパス」をご参照ください。
-
スクリプトで使用されている OSS コマンドを更新します。「ブートストラップアクションの管理」をご参照ください。
更新後、スクリプトを OSS にアップロードし、クラスター作成時に新しいパスを参照します。
本番クラスターに適用する前に、テスト環境ですべてのブートストラップアクションスクリプトを検証してください。
(オプション) Auto Scaling ルールのレビュー
旧クラスターで Auto Scaling が構成されている場合は、新しいクラスターを作成する前に次のパラメーターを記録し、新しいクラスターの準備ができた後に再構成します。
-
旧 EMR コンソールで、EMR on ECS に移動し、クラスターを開き、Auto Scaling タブをクリックします。
-
関連する Auto Scaling グループの ルール設定 をクリックし、以下を記録します。
-
最大インスタンス数
-
最小インスタンス数
-
グレースフルシャットダウン
-
トリガーモード
-
トリガールール (スケールアウトとスケールイン)
-
新しいクラスターでの再構成については、「Auto Scaling ルールの追加」をご参照ください。
新しいクラスターでは、Auto Scaling の構成 パネルで、インスタンスタイプ選択モード、課金方法、インスタンスタイプ、およびグレースフルシャットダウンも構成できます。「ノードグループの管理」をご参照ください。
(オプション) クラスター負荷の評価
新しいクラスターのサイジングを行う前に、旧クラスターのリソース使用率をレビューします。
-
サービスメトリック: YARN および HDFS のリソース使用量を表示します。「サービスメトリックの表示」をご参照ください。
-
EMR Doctor 日次レポート: コンピューティングリソース、YARN スケジューリング、および HDFS ストレージディストリビューションをレビューします。「日次クラスターレポートとレポート内の分析結果の表示」をご参照ください。
旧コンソールで EMR Doctor を使用する前に、EMR Doctor をアクティブ化してください。「EMR Doctor (Hadoop クラスター) のアクティブ化」をご参照ください。
移行計画
評価に基づいて、続行する前に以下を決定します。
-
プロダクトバージョンとサービス: 新しいクラスターにデプロイするサービスとバージョンを決定します。ステップ 1 の「プロダクトバージョンとオプションサービスの選択」をご参照ください。
-
メタデータストレージ: DLF 統合メタデータまたはセルフマネージド RDS を選択します。
組み込み MySQL はテスト環境専用であり、本番環境では使用しないでください。
-
データストレージ: OSS-HDFS または OSS を選択します。
ステップ 1: 新しい EMR コンソールでのクラスター作成
新しいクラスターの作成
「クラスターの作成」に従い、収集した構成を適用します。次の設定に注意してください。
プロダクトバージョンとオプションサービス (少なくとも 1 つ選択)
旧クラスターとの互換性に基づいてサービスとバージョンを選択します。
サービス互換性
オープンソースコミュニティが新しいバージョンをリリースするにつれて、DataLake クラスターの一部のサービスは Hadoop クラスターのサービスよりも新しいバージョンになります。次の表は、下位互換性範囲を示しています。各範囲内で、新しいバージョンは以前のバージョンによって生成されたデータを読み取ることができます。
| サービス | 範囲 1 | 範囲 2 | 範囲 3 | 範囲 4 |
|---|---|---|---|---|
| Spark | 2.X | 3.X | — | — |
| Hive | 2.X | 3.X | — | — |
| Tez | すべてのバージョンが互換 | — | — | — |
| Delta Lake | 0.6.X | 0.8.0–1.1.0 | — | — |
| Iceberg | 0.12.X | 0.13.X | — | — |
| Hudi | 0.6.X | 0.8.X | 0.9.X | 0.10.X |
| Sqoop | すべてのバージョンが互換 | — | — | — |
| Ranger | 1.X | 2.X | — | — |
| OpenLDAP | すべてのバージョンが互換 | — | — | — |
互換性情報は参考用です。各サービスの公式ドキュメントで確認してください。
旧コンソールで利用可能な一部のサービス (Hue、Zeppelin、Oozie など) は、新しいコンソールではサポートされていません。これらは EMR Notebook または EMR Workflow に移行するか、新しいクラスターに同等のエンジンをデプロイしてください。
プロダクトバージョン
旧クラスターバージョンに基づいて EMR バージョンシリーズを選択します。データレイクシナリオでは、EMR は EMR V3.X と EMR V5.X の 2 つのシリーズを提供します。
| 旧クラスターバージョン | 新しいクラスターバージョンシリーズ |
|---|---|
| EMR V3.35.0 (YARN 2.8.5, HDFS 2.8.5, Hive 2.3.7, Spark 2.4.7) | EMR V3.X シリーズ |
| EMR V5.6.0 (YARN 3.2.1, HDFS 3.2.1, Hive 3.1.2, Spark 3.2.1) | EMR V5.X シリーズ |
ソフトウェアバージョンの要件が満たされている場合は、最新機能にアクセスするために、利用可能な最新の EMR バージョンを選択します。
HDFS または OSS-HDFS の選択
EMR V5.12.1 および EMR V3.46.1 以降、オプションサービスから HDFS または OSS-HDFS を基盤となるストレージとして選択できます。
計画しているストレージソリューションに基づいてオプションサービスを選択します。
| 新しいコンソールでのストレージ | 選択するサービス |
|---|---|
| OSS | OSS-HDFS |
| OSS-HDFS | OSS-HDFS |
OSS-HDFS を選択する場合は、クラスターのルートストレージディレクトリ パラメーターを構成して、OSS-HDFS が有効になっているバケットをクラスターのルートストレージパスとして指定します。
メタデータ
| メタデータストレージタイプ | 説明 |
|---|---|
| DLF 統合メタデータ (推奨) | メタデータは DLF に保存されます。旧クラスターがすでに DLF を使用している場合は、DLF カタログ を同じ値に設定します。メタデータは自動的に共有され、移行は不要です。 |
| セルフマネージド RDS | メタデータは、管理する ApsaraDB RDS データベースに保存されます。既存のデータベースパラメーターを構成します。「セルフマネージド ApsaraDB RDS for MySQL データベースの構成」をご参照ください。 |
| 組み込み MySQL | メタデータは、クラスター上のローカル MySQL データベースに保存されます。テスト環境専用です。 |
(オプション) カスタムソフトウェア構成
旧クラスターからサービス構成をエクスポートした場合は、新しいクラスターを作成する際に カスタムソフトウェア構成 をオンにし、構成コンテンツをフィールドに貼り付けます。「ソフトウェア構成のカスタマイズ」をご参照ください。
ハードウェア構成
収集したリソース使用率データに基づいて、マスター、コア、およびタスクノードのハードウェアを選択します。
-
最新の ECS インスタンスファミリーとクラウドディスクタイプを使用して、更新されたハードウェア機能にアクセスします。
-
必要に応じて、クラスター作成後に同じロールを持つノードグループを追加します。
-
パブリックネットワーク IP の割り当て: マスターノードまたはオープンソースコンポーネントの Web UI へのインターネットアクセスが必要な場合は、マスターノードグループでこのスイッチをオンにします。
(オプション) ゲートウェイの作成
旧コンソールでゲートウェイを使用してジョブを送信し、クラスターを分離している場合は、EMR-CLI を使用して新しい環境にゲートウェイをデプロイします。このツールは、既存の ECS インスタンスにゲートウェイをデプロイし、クラスター構成を自動的に同期します。「EMR-CLI を使用したゲートウェイのデプロイ」をご参照ください。
ステップ 2: データの移行と検証
新しいクラスターが実行されたら、旧クラスターからメタデータ、データ、およびジョブを移行します。
メタデータの移行
旧クラスターと新しいクラスターのメタデータ管理モードに基づいて移行方法を選択します。新しいクラスターには DLF 統合メタデータを強く推奨します。
| 旧メタデータモード | 新しいメタデータモード | 移行方法 |
|---|---|---|
| DLF | DLF | 移行は不要です。新しいクラスターで同じ DLF カタログを設定します。 |
| 統合メタベース | DLF | 「EMR メタデータの移行」をご参照ください。 |
| ローカル MySQL | DLF | 「メタデータの移行」をご参照ください。 |
| セルフマネージド ApsaraDB RDS | DLF | 「メタデータの移行」をご参照ください。 |
データの移行
旧クラスターと新しいクラスターのストレージモードに基づいて移行方法を選択します。
| 旧ストレージ | 新しいストレージ | 移行方法 |
|---|---|---|
| OSS | OSS | 移行は不要です。 |
| OSS | OSS-HDFS | Jindo DistCp を使用します。 |
| ブロックモードの JindoFS | OSS-HDFS | Jindo DistCp を使用します。 |
| HDFS | OSS-HDFS | Jindo DistCp を使用します。 |
データの検証
データ移行が不要な場合は、このステップをスキップしてください。
移行後、HDFS データと Hive データベースおよびテーブル内のデータの正確性を検証します。不整合が見つかった場合は、影響を受けるタスクを再実行するか、不足しているデータをすぐに補完します。
| 要件 | 検証方法 |
|---|---|
| ファイル検証 | 移行前と移行後にチェックサム値を計算し、比較して変更やデータ破損がないことを確認します。 |
| 概算データ検証 | テーブルレベルの統計 (行数、数値列の合計と平均、最小値と最大値) を確認して、全体的な整合性を迅速に評価します。 |
| 詳細データ検証 | 各行のデータを比較して、移行後もすべてのレコードが破損していないことを確認します。 |
ジョブの移行
スケジューリング環境に基づいてジョブを移行します。
-
EMR Data Platform (旧コンソール): EMR Workflow に移行します。「旧 EMR コンソールにおける EMR Data Platform からのデータ移行に関するお知らせ」をご参照ください。
-
DataWorks またはセルフマネージドプラットフォーム: プラットフォームの移行ドキュメントに従います。コンピューティングクラスターエンドポイントなどの主要構成を更新して、新しいクラスターを指すようにします。
ステップ 3: 並行検証の実行
トラフィックを切り替える前に、旧クラスターと新しいクラスターの両方でジョブを同時に実行し、データ整合性とビジネス精度を検証します。これは、ダブルラン検証と呼ばれることもあります。
具体的なアプローチは、ビジネスアーキテクチャ、データ処理要件、およびリスク許容度によって異なります。シナリオに合った並行実行計画を設計します。目標は、切り替えをコミットする前に、新しいクラスターが旧クラスターと同一の結果を生成することを確認することです。
ステップ 4: 切り替えと旧クラスターのリリース
並行検証によって新しいクラスターがすべてのワークロードを正しく処理することを確認した後、メンテナンスウィンドウをスケジュールし、切り替えを実行します。
-
旧クラスターから新しいクラスターへジョブを徐々に移行します。
-
新しいクラスターでのジョブ処理量を段階的に増やします。
-
すべてのジョブが安定して実行されるまで、新しいクラスターを監視します。
すべてのビジネスデータが新しいクラスターで実行され、旧クラスターにワークロードが残っていない場合は、「クラスターのリリース」に従って旧クラスターをリリースします。