Cloud Data Fusion では、クラスタ構成とは、Dataproc で Spark ジョブを実行するときにデータ処理パイプラインがコンピューティング リソースをどのように利用するかを定義することを指します。このページでは、クラスタ構成の主なアプローチについて説明します。
デフォルトの一時クラスタ（推奨）
Cloud Data Fusion パイプラインでは、デフォルト クラスタの使用が推奨されるアプローチです。
- Cloud Data Fusion は、パイプラインの実行ごとに一時的な Dataproc クラスタを自動的にプロビジョニングして管理します。パイプライン実行の開始時点でクラスタを作成し、パイプラインの実行が完了した後に削除します。
- エフェメラル クラスタのメリット:
- シンプルさ: クラスタを手動で構成または管理する必要はありません。
- 費用対効果: パイプラインの実行中に使用されたリソースに対してのみ料金が発生します。
クラスタを調整してパフォーマンスをチューニングするには、クラスタのサイズ設定をご覧ください。
静的クラスタ（特定のシナリオの場合）
次のシナリオでは、静的クラスタを使用できます。
- 長時間実行されるパイプライン: 継続的に実行されるパイプラインや長期間実行されるパイプラインの場合、エフェメラル クラスタを繰り返し作成して削除するよりも、静的クラスタの方が費用対効果が高くなることがあります。
- クラスタの集中管理: 組織でクラスタの作成と管理ポリシーを一元的にコントロールする必要がある場合は、Terraform などのツールとともに静的クラスタを使用できます。
- クラスタの作成時間: すべてのパイプライン用の新しいクラスタの作成に要する時間が、ユースケースに適していない場合。
ただし、静的クラスタでは手動構成が多く必要になり、クラスタのライフサイクルを自分で管理する必要があります。
静的クラスタを使用するには、Dataproc クラスタで次のプロパティを設定する必要があります。
dataproc:dataproc.conscrypt.provider.enable=false
capacity-scheduler:yarn.scheduler.capacity.resource-calculator="org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator"
静的クラスタのクラスタ構成オプション
静的クラスタを使用する場合、Cloud Data Fusion には次の側面に関する構成オプションがあります。
- ワーカー マシンタイプ: クラスタ内のワーカーノードの仮想マシンタイプを指定します。これにより、各ワーカーで使用可能な vCPU とメモリが決まります。
- ワーカー数: クラスタ内のワーカーノードの初期数を定義します。Dataproc は、ワークロードに基づいてこの数を自動スケーリングする場合があります。
- ゾーン: クラスタの Google Cloud ゾーンを選択します。ロケーションは、データの局所性とネットワーク パフォーマンスに影響する可能性があります。
- 追加の構成: プリエンプション設定、ネットワーク設定、初期化アクションなど、静的クラスタの高度なオプションを構成できます。
ベスト プラクティス
パイプライン用の静的クラスタを作成する場合は、次の構成を使用します。
| パラメータ | 説明 |
|---|---|
yarn.nodemanager.delete.debug-delay-sec |
YARN のログを保持します。 推奨値: 86400（1 日に相当します） |
yarn.nodemanager.pmem-check-enabled |
YARN が物理メモリの上限を確認して、コンテナが物理メモリを超過した場合にコンテナを強制終了できるようにします。 推奨値: false |
yarn.nodemanager.vmem-check-enabled |
YARN が仮想メモリの上限を確認し、コンテナが物理メモリを超過した場合にコンテナを強制終了できるようにします。 推奨値: false |
dataproc.scheduler.driver-size-mb |
ドライバの平均メモリ フットプリントにより、マスターノードにドライバ プロセスを実行するのに十分なメモリがない場合、Dataproc はジョブをキューに登録します。これはジョブの同時実行に影響する可能性がありますが、メモリの多いマスターノードを使用することで軽減できます。 推奨値: 2048 |
詳細については、既存の Dataproc クラスタに対してパイプラインを実行するをご覧ください。
クラスタの再利用
実行間で Dataproc クラスタを再利用して、処理時間を短縮できます。クラスタの再利用は、接続プーリングやスレッド プーリングと同様のモデルで実装されます。実行が完了した後、指定された期間、クラスタは稼働し続けます。新しい実行が開始されると、コンピューティング プロファイルの構成に一致する使用可能なアイドル状態のクラスタが検索されます。存在する場合はそれが使用され、存在しない場合は新しいクラスタが開始されます。
クラスタの再利用に関する考慮事項
- クラスタは共有されません。通常のエフェメラル クラスタ プロビジョニング モデルと同様に、クラスタは一度に 1 つのパイプライン実行を実行します。クラスタは、アイドル状態の場合にのみ再利用されます。
- すべての実行でクラスタの再利用を有効にすると、すべての実行を処理するために必要な数のクラスタが必要に応じて作成されます。エフェメラル Dataproc プロビジョナーと同様に、作成されるクラスタの数を直接制御することはできません。リソースの管理には、引き続き Google Cloud 割り当てを使用できます。たとえば、最大 7 件の並列実行で 100 件実行する場合、特定の時点で最大 7 つのクラスタが存在します。
クラスタは、異なるパイプラインが同じプロファイルを使用し、同じプロファイル設定を共有するとすぐに、それらのパイプライン間で再利用されます。プロファイルのカスタマイズを使用している場合でも、クラスタは再利用されますが、カスタマイズが完全に同じである場合に限られます。これには、クラスタのラベル付けなどのすべてのクラスタ設定が含まれます。
クラスタの再利用が有効になっている場合、主に次の 2 つの費用に関する考慮事項があります。
- クラスタの起動と初期化に使用されるリソースが少なくなります。
- クラスタは、パイプライン実行の間や最後のパイプライン実行後にアイドル状態になるため、より多くのリソースが使用されます。
クラスタの再利用による費用の削減効果を予測することは困難ですが、費用を最大限に削減するための戦略を採用できます。この戦略では、チェーンされたパイプラインのクリティカル パスを特定し、このクリティカル パスでクラスタの再利用を有効にします。これにより、クラスタがすぐに再利用され、アイドル時間が無駄にならず、最大限のパフォーマンス上のメリットが得られます。
クラスタの再利用を有効にする
デプロイされたパイプライン構成の [コンピューティング構成] セクションで、または新しいコンピューティング プロファイルを作成するときに、次のようにします。
- [クラスタの削除をスキップ] を有効にします。
- 最大アイドル時間は、クラスタが次のパイプラインで再利用されるまで待機する時間です。デフォルトの最大アイドル時間は 30 分です。最大アイドル時間については、再利用のコストとクラスタの可用性を考慮してください。最大アイドル時間の値が大きいほど、実行の準備が整った状態でアイドル状態になっているクラスタの数が増えます。
トラブルシューティング: バージョンの互換性
問題: Cloud Data Fusion 環境のバージョンが Dataproc クラスタのバージョンと互換性がない場合があります。
推奨: 最新の Cloud Data Fusion バージョンにアップグレードし、サポートされている Dataproc バージョンのいずれかを使用します。
以前のバージョンの Cloud Data Fusion は、サポートされていない Dataproc バージョンんとのみ互換性があります。 Dataproc は、これらのバージョンで作成されたクラスタの更新とサポートを提供していません。サポートされていないバージョンで作成されたクラスタを引き続き実行することはできますが、サポートされているバージョンで作成されたクラスタに置き換えることをおすすめします。
| Cloud Data Fusion のバージョン | Dataproc のバージョン |
|---|---|
| 6.11.1 | 2.3 |
| 6.10.1.1 | 2.2***、2.1、2.0 * |
| 6.10 | 2.1、2.0 * |
| 6.9 | 2.1、2.0、1.5 * |
| 6.7-6.8 | 2.0、1.5 * |
| 6.4-6.6 | 2.0 *, 1.3 ** |
| 6.1-6.3 | 1.3** |
major.minor イメージのバージョンを指定することをおすすめします。
Dataproc クラスタで使用する OS バージョンを指定するには、OS バージョンが、前の表で お使いの Cloud Data Fusion 用にサポートされている Dataproc バージョンと互換性がある必要があります。
トラブルシューティング: コンテナがゼロ以外の終了コード 3 で終了した
問題: 自動スケーリング ポリシーが使用されておらず、静的 Dataproc クラスタでメモリ プレッシャーが発生しているため、ログにメモリ不足例外（Container exited with a non-zero
exit code 3）が表示されます。
推奨: エグゼキュータのメモリを増やします。
パイプラインに task.executor.system.resources.memory ランタイム引数を追加して、メモリを増やします。次のランタイム引数の例では、メモリを 4,096 MB に設定しています。
"task.executor.system.resources.memory": 4096
詳細については、クラスタのサイズ設定をご覧ください。