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

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

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

このセクションでは、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 ワークロードの場合は、Flex Start を使用して、H4D オンデマンドまたは予約済み容量が使用できない場合の容量管理を強化します。Flex Start は、H4D ノードのライフサイクルを管理し、バースト的または時間的制約のあるリソースのニーズに対応します。

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

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

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

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

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

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

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 を有効にする

次のステップ