クラスタとジョブの柔軟性と効率を最大化する

このページでは、 Google Cloud リージョン全体でリソースの取得可能性を最大化し、プロビジョニングの遅延を減らし、パフォーマンスと費用の最適化を活用する、復元力のある Managed Service for Apache Spark クラスタを設計するためのベスト プラクティスとスケジューリング戦略について説明します。

リソースの取得可能性の概要

固定された Managed Service for Apache Spark クラスタでジョブを実行すると、単一障害点が発生し、局所的な可用性の低下やプロビジョニングの遅延により、ジョブの中断やクラスタとジョブの障害が発生する可能性があります。

次のいずれかの厳格なアンチパターンで構成されたクラスタでは、リソースが利用できなくなるリスクが高くなります。

  • 固定ゾーン プレースメント: Managed Service for Apache Spark AutoZone でクラスタを最適なゾーンに動的に配置するのではなく、zone フラグまたはフィールドを使用して単一のゾーンをハードコードします。このアンチパターンでは、クラスタの作成時に、隣接するゾーンで使用可能なコンピューティング リソースを使用できません。
  • ノードロールごとに 1 つのマシンタイプまたは世代: ノードロールを 1 つのマシン世代またはタイプに制限します。このアンチパターンにより、クラスタが代替手段にフォールバックできなくなります。
  • 優先度が最も高いランクのマシン ファミリーが少なすぎる: フォールバック ランクが定義されている場合でも、フレキシブル VM ポリシーのランク 0 に 1 つまたは 2 つのマシン ファミリーのみをリストします。このアンチパターンでは、Managed Service for Apache Spark が最初に取得できるリソースのプールが狭くなるため、下位ランクへのフォールバックやプロビジョニングの遅延が発生する可能性が高くなります。
  • 少数の大規模な VM を使用した垂直スケーリング: 少数の大規模な VM シェイプに依存するようにクラスタを垂直方向にスケーリングします。このアンチパターンでは、スケジューリングの柔軟性が制限されます。
  • オール オア ナッシングのクラスタ作成: 自動スケーリングと組み合わせた部分的なクラスタ作成を使用するのではなく、すべてのワーカーノードを同時にプロビジョニングする必要があります。このアンチパターンでは、一時的なリソース不足によりワーカーノードを割り当てられない場合、クラスタの作成が失敗します。
  • ピーク時のスケジューリングの急増: ピーク時に大規模なバッチ パイプラインをトリガーすると、リージョン内の競合が増加します。

リソースの取得可能性とは、ハードウェアの柔軟性、マルチゾーン、スケーラビリティを考慮してジョブを設計することです。クラスタを固定構成から切り離し、マルチマシン ファミリーのフォールバックを有効にすることで、作成の成功率を高め、起動レイテンシを最小限に抑え、SLA を一貫して達成できます。

リソースの取得可能性に関する推奨事項

リソースの可用性とジョブの安定性を向上させるには、次の最適化を導入します。

フレキシブル VM を使用する

フレキシブル VM 機能を使用すると、マスター、プライマリ、セカンダリのワーカーノードにランク付けされた VM タイプのリストを指定できます。これにより、リストされた VM タイプを評価し、利用可能な容量を持つゾーンを自動的に選択することで、作成の成功率が向上します。

推奨事項: ディスク オーバーライドでフレキシブル VM を使用します。これにより、同じクラスタ ポリシー内の異なる候補マシン ファミリーに、ハイパーディスクや永続ディスクなどの異なるディスクタイプを指定できます。また、1 つのポリシー内で Gen2 マシン ファミリーと Gen4 マシン ファミリーを組み合わせて、より広範なプールでジョブをスケーリングし、容量制限を回避することもできます。

ランク 0 で少なくとも 3 つの異なるマシン ファミリーを指定します。Managed Service for Apache Spark は、優先度が最も高い（ランク 0）リストから最初に取得するため、ランク 0 の範囲を広くすると、クラスタ作成時に候補リソースのプールが最大になり、その後、下位のランクにフォールバックします。ランク 0 で Gen4 ファミリーと Gen2 ファミリーを組み合わせることが、このプールを拡大する最も効果的な方法です。

汎用ワークロード（現在 N2 マシンまたは N2D マシンで実行されているジョブなど）の場合は、次のランキングを使用します。

  • ランク 0: N4、N4D（Hyperdisk Balanced を使用）、N2、N2D
  • ランク 1: C4、C4D（Hyperdisk Balanced を使用）、C2D。ローカル SSD は C4 と C4D で使用できますが、通常、8 コアまたは 16 コアでは 1 ～ 2 個のローカル SSD のみがサポートされます。
  • ランク 2: E2（パフォーマンスが低い。必要な場合にのみ使用）

たとえば、n2d-standard-16 を使用するジョブの場合、ランキングは次のようになります。

  • ランク 0: n4-standard-16、n4d-standard-16、n2-standard-16、n2d-standard-16
  • ランク 1: c4-standard-16、c4d-standard-16、c2d-standard-16
  • ランク 2: e2-standard-16

N4 と N4D には Hyperdisk が必要で、N2 と N2D は永続ディスクを使用するため、ランク 0 を、同じランクを共有するものの異なる diskConfig 値を使用する 2 つのインスタンス選択として定義します。たとえば、次の gcloud dataproc clusters create フラグは、前の例のプライマリ ワーカー ポリシーを定義します。

gcloud dataproc clusters create CLUSTER_NAME \
    --region=REGION \
    --zone="" \
    --num-workers=NUM_WORKERS \
    --worker-instance-selection='{"machineTypes":["n4-standard-16","n4d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["n2-standard-16","n2d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c4-standard-16","c4d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c2d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["e2-standard-16"],"rank":2,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}'

フレキシブル VM を使用する場合は、次の要素を考慮してください。

  • 混合ディスクタイプのサポート: Gen3 マシンタイプと Gen4 マシンタイプは、Hyperdisk ディスクタイプのみをサポートし、Persistent Disk タイプはサポートしていません。Gen2 と Gen4 をブレンドする場合は、instanceFlexibilityPolicy のインスタンス選択ごとに diskConfig を指定します。詳細については、ディスクのオーバーライドをご覧ください。

  • リソース割り当て: フォールバック タイプを使用してフレキシブル VM ポリシーを定義すると、Compute Engine はリージョン内のすべての候補タイプとディスクの割り当てを確認します。構成されたすべての項目に十分なコンピューティング割り当てとディスク割り当てがプロジェクトに割り当てられていることを確認します。

  • Compute Engine の割引: フレキシブル確約利用割引（CUD）を利用して、複数の VM ファミリーとリージョンにわたって費用ベースの割引を適用します。

  • 料金: Google Cloud 料金計算ツールを使用して、ポリシーの各ランクの費用を比較します。

構成テンプレートとデプロイの例については、以下をご覧ください。

自動ゾーン プレースメントを使用する

AutoZone の配置を使用して、Managed Service for Apache Spark がリソースをプロビジョニングする最適なゾーンを選択できるようにします。カスタム Virtual Private Cloud（VPC）ネットワークを使用する場合は、サブネットにすべてのリージョン ゾーンにわたる十分な IP アドレスがあることを確認してください。

より小さいマシンの形を使用する

大規模な VM で垂直方向にスケーリングするのではなく、小規模なマシンタイプ（4、8、16 コア）で水平方向にスケーリングするようにジョブを設計します。VM サイズが小さいほど、ゾーン間の可用性が高くなり、作成の遅延を防ぐことができます。

  • ドライバノードに大規模なマシンタイプを使用するジョブを確認して再設計します。
  • ワーカーノード（単一ノードクラスタ）なしでドライバノードのみを実行するジョブを確認します。単一ノードクラスタで実行されているジョブは、動的にスケールアップして、実行を単一の物理ホストにバインドすることはできません。

クラスタの自動スケーリングを使用する

リソースの変動（急増）があるジョブの容量を管理するには、十分な最大インスタンス数でクラスタの自動スケーリングを使用します。

自動スケーリングで部分的なクラスタ作成を使用する

部分的なクラスタ作成を使用します。これにより、自動スケーリングでプライマリ ワーカーの最小数を指定できます。リクエストされた数よりも少ないワーカーでクラスタが起動した場合、リソースが利用可能になると、自動スケーリングによってワーカーが動的に追加されます。

オフピーク時にジョブをスケジュールする

日中や週末など、オフピーク時にジョブをスケジュールします。スケジューリングの急増を回避するため、標準以外の時間（10:00 ではなく 10:07 など）にスケジュールを設定します。

次のステップ