GKE で HPC ワークロードを実行するためのベスト プラクティス

Google Kubernetes Engine(GKE)は、ハイ パフォーマンス コンピューティング(HPC)ワークロード向けの高性能でスケーラブルなプラットフォームを提供します。高いパフォーマンスと運用効率を実現するには、GKE が提供する HPC 固有の VM ファミリーなどのワークロード最適化インフラストラクチャを使用します。このドキュメントでは、インフラストラクチャとワークロードを管理して GKE で HPC アプリケーションの実行を最適化するためのベスト プラクティスについて説明します。

GKE のすべてのベスト プラクティスの概要については、 GKE のベスト プラクティスをご覧ください。

インフラストラクチャとノードの構成

このセクションでは、HPC ワークロード用に基盤となるインフラストラクチャと GKE ノードを構成するためのベスト プラクティスについて説明します。

コンピューティング負荷の高いワークロードに H4D VM を選択する

アプリケーションに適したハードウェアを選択します。H4D VM は、コンピューティング負荷の高い HPC アプリケーションのスループットを最大化するように設計されています。H4D VM は、マルチノード ワークロードに高パフォーマンス、低コスト、拡張性を提供します。H4D は、コンピューティング負荷の高い HPC に最適なコンピューティング最適化インスタンスを提供するコンピューティング最適化マシン ファミリーの一部です。

H4D マシンシリーズの詳細については、 コンピューティング最適化マシン ファミリー: H4D マシンシリーズをご覧ください。

HPC 最適化 GKE クラスタの作成方法については、 H4D でハイ パフォーマンス コンピューティング ワークロードを実行するをご覧ください。

ノード割り当て可能リソースを考慮する

ノードの総リソース容量とワークロードに割り当て可能なリソースの違いを理解します。GKE ノードは、機能するためにリソースを必要とする kubelet やコンテナ ランタイムなどのシステム コンポーネントを実行します。GKE は、システム機能とノードの信頼性確保のために、事前に定義された量のリソースを予約します。ワークロードに割り当てられる実際のリソース量(VM サイズから GKE が予約する容量を引いた値)を把握することで、HPC ワークロードのリソース リクエストのサイズを適切に設定できます。

詳しくは、次のリソースをご覧ください。

プリエンプションを軽減するためにコアを予約する

ワークロードがノードで使用可能なすべての物理コアを使用すると、レイテンシの影響を受けやすいシステム デーモンと競合する可能性があります。この競合により、OS スケジューラが HPC ワークロードを中断してシステム タスクを実行するプリエンプションが頻繁に発生し、パフォーマンスが低下する可能性があります。

パフォーマンスを維持するには、使用可能なすべての CPU をワークロードに割り当てないでください。重要なシステム プロセスが適切に機能するには、少量の CPU オーバーヘッドが必要です。コンピューティング容量の 100% をワークロードに割り当てると、これらのシステム コンポーネントとのリソース競合が発生し、パフォーマンスが低下する可能性があります。たとえば、H4D マシンタイプの場合、パフォーマンスを維持するには、192 個未満の CPU を使用するようにワークロードを構成します。

クラスタとワークロードの構成

このセクションでは、GKE クラスタを構成して HPC ワークロードをデプロイするためのベスト プラクティスについて説明します。

クラスタの作成に Cluster Toolkit を使用する

Cluster Toolkit を使用すると、GKE での HPC ワークロードのデプロイと管理を簡素化できます。このツールキットには、高性能環境でコンピューティング、ストレージ、ネットワーク リソースを構成するためのベスト プラクティスが組み込まれたリファレンス デザイン ブループリントが用意されています。

Cluster Toolkit を使用して H4D クラスタを作成する手順については、H4D でハイ パフォーマンス コンピューティング ワークロードを実行するをご覧ください。

容量管理に Flex Start を使用する

バースト(動的)または時間的制約の少ない HPC ワークロードの場合は、H4D オンデマンドまたは予約済み容量が使用できない場合に、Flex Start を使用して容量管理を強化します。Flex Start は H4D ノードのライフサイクルを管理し、バーストまたは時間的制約のあるリソースのニーズに対応します。

詳細については、 Flex Start で H4D クラスタを作成するをご覧ください。

密結合ワークロードにコンパクト プレースメント ポリシーを使用する

レイテンシの影響を受けやすい密結合の HPC ワークロードに、コンパクト プレースメント ポリシーを実装します。このポリシーにより、すべての Pod がホストマシン上で互いに近くにプロビジョニングされます。この構成により、ノード間のネットワーク レイテンシが最小限に抑えられます。これは、ノード間通信に依存するアプリケーションにとって重要です。

H4D でハイ パフォーマンス コンピューティング ワークロードを実行するで説明されているように、gcloud CLI を使用して H4D クラスタを作成すると、GKE はコンパクト プレースメント ポリシーを自動的に構成します。Cluster Toolkit を使用している場合、このポリシーも自動的に構成されます。 他のノードタイプにコンパクト プレースメントを手動で構成する場合は、 GKE ノードのコンパクト プレースメントを定義するをご覧ください。

適切なリソース リクエストを設定する

HPC ジョブのサイズを設定する前に、ノードで実際に割り当て可能な CPU を確認します。 kubectl get node コマンドを使用して、割り当て可能なリソースを表示します。ジョブの CPU 要件が、GKE システム予約後の GKE で使用可能なリソースを超えないようにします。

GKE には、リソース リクエストの分析と自動調整に役立つ機能がいくつか用意されています。詳細については、プロビジョニング不足のワークロードとプロビジョニング過剰のワークロードを特定するをご覧ください。

単一のワークロードにノード全体を割り当てる

H4D ノード全体を占有するように MPI ジョブを構成します。H4D インスタンスは、ホスト全体の VM としてプロビジョニングされます。この戦略では、ノードの容量の大部分が予約され、ワークロードが分離されます。レプリカが同じ物理ノードに配置されないようにするには、コンテナ リソース リクエストまたは Pod の反アフィニティを使用します。

H4D VM との高速ネットワーキングに Cloud RDMA を有効にする

H4D VM を使用する場合は、Pod の Cloud RDMA を有効にするようにデプロイ マニフェストを構成します。この構成により、高速 RDMA ネットワーク インターフェースがコンテナ化されたワークロードに正しく公開されます。手順については、 RDMA 用にマニフェストを構成するをご覧ください。

ベスト プラクティスの概要

次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。

トピック タスク
インフラストラクチャとノードの構成 コンピューティング負荷の高いワークロードに H4D VM を選択する
インフラストラクチャとノードの構成 ノード割り当て可能リソースを考慮する
インフラストラクチャとノードの構成 プリエンプションを軽減するためにコアを予約する
クラスタとワークロードの構成 クラスタの作成に Cluster Toolkit を使用する
クラスタとワークロードの構成 容量管理に Flex Start を使用する
クラスタとワークロードの構成 密結合ワークロードにコンパクト プレースメント ポリシーを使用する
クラスタとワークロードの構成 適切なリソース リクエストを設定する
クラスタとワークロードの構成 単一のワークロードにノード全体を割り当てる
クラスタとワークロードの構成 H4D VM との高速ネットワーキングに Cloud RDMA を有効にする

次のステップ