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

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

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

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

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

  • 固定ゾーン プレースメント: Managed Service for Apache Spark AutoZone でクラスタを最適なゾーンに動的に配置するのではなく、zone フラグまたはフィールドを使用して単一のゾーンをハードコードします。このアンチパターンでは、隣接するゾーンで使用可能なコンピューティング リソースをクラスタの作成に使用できません。
  • ノードロールごとの単一のマシンタイプまたは世代: ノードロールを単一のマシン世代またはタイプに制限します。このアンチパターンでは、クラスタが代替手段にフォールバックすることを防ぎます。
  • 大規模な VM の数を減らして垂直方向にスケーリングする: 少数の大規模な VM シェイプに依存するようにクラスタを垂直方向にスケーリングします。このアンチパターンは、スケジュールの柔軟性を制限します。
  • クラスタの全か無かの作成: クラスタの部分的な作成と自動スケーリングを組み合わせて使用するのではなく、すべてのワーカーノードを同時にプロビジョニングする必要があります。このアンチパターンでは、一時的なリソースの利用不可によりワーカーノードを割り当てることができない場合、クラスタの作成が失敗します。
  • ピーク時のスケジューリングの急増: 使用量のピーク時に大規模なバッチ パイプラインをトリガーすると、リージョン競合が増加します。

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

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

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

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

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

推奨事項: ディスクのオーバーライドでフレキシブル VM を使用します。これにより、同じクラスタ ポリシー内のさまざまな候補マシン ファミリーに対して、ハイパーディスクや Persistent Disk などのさまざまなディスクタイプを指定できます。単一のポリシー内で第 2 世代と第 4 世代のマシン ファミリーをブレンドして、より広範なプールでジョブをスケーリングし、容量上限を回避することもできます。

N2 マシンと N2D マシンを使用するジョブの場合、次のランキングを検討してください。

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

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

  • ランク 0: n2d-standard-16、n2-standard-16
  • ランク 1: n4-standard-16、n4d-standard-16
  • ランク 2: c4-standard-16、c4d-standard-16、c3-standard-22、c3d-standard-16
  • ランク 3: e2-standard-16

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

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

  • リソース割り当て: フォールバック タイプを使用して Flexible 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 など）にスケジュールします。

次のステップ