Cloud Data Fusion では、クラスタ構成とは、Dataproc で Spark ジョブを実行するときにデータ処理パイプラインが計算リソースをどのように使用するかを定義することを指します。このページでは、クラスタ構成の主な方法について説明します。
デフォルトのエフェメラル クラスタ（推奨）
Cloud Data Fusion パイプラインでは、デフォルト クラスタの使用が推奨されるアプローチです。
- Cloud Data Fusion は、パイプラインの実行ごとに一時的な Dataproc クラスタを自動的にプロビジョニングして管理します。パイプライン実行の開始時にクラスタを作成し、パイプライン実行が完了した後に削除します。
- エフェメラル クラスタのメリット:
- シンプルさ: クラスタを手動で構成または管理する必要はありません。
- 費用対効果: パイプラインの実行中に使用されたリソースに対してのみ料金が発生します。
クラスタを調整してパフォーマンスをチューニングするには、クラスタのサイズ設定をご覧ください。
静的クラスタ（特定のシナリオ用）
静的クラスタは、次のシナリオで使用できます。
- 長時間実行されるパイプライン: 継続的にまたは長時間実行されるパイプラインの場合、エフェメラル クラスタを繰り返し作成して破棄するよりも、静的クラスタの方が費用対効果が高い場合があります。
- クラスタの集中管理: 組織でクラスタの作成と管理ポリシーを一元的にコントロールする必要がある場合は、Terraform などのツールとともに静的クラスタを使用できます。
- クラスタの作成時間: すべてのパイプライン用の新しいクラスタの作成に要する時間が、ユースケースに適していない場合。
ただし、静的クラスタでは、より多くの手動構成が必要になり、クラスタのライフサイクルを自分で管理する必要があります。
静的クラスタを使用するには、Dataproc クラスタに次のプロパティを設定する必要があります。
dataproc:dataproc.conscrypt.provider.enable=false
静的クラスタのクラスタ構成オプション
静的クラスタを使用する場合は、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 クラスタに対してパイプラインを実行するをご覧ください。
クラスタの再利用
実行間で 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.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
詳細については、クラスタのサイズ設定をご覧ください。