次の方法で共有

GPU に関する Azure Kubernetes Service (AKS) のためのベスト プラクティス

AKS クラスターで GPU ワークロードを実行するには、適切なセットアップと継続的な検証によって、コンピューティング リソースのアクセス可能性、セキュリティ保護、最適な利用効率を維持することが必須です。 この記事では、GPU 対応ノードの管理方法、構成の検証方法、ベンダー固有の診断コマンドを使ってワークロードの中断を減らす方法に関するベスト プラクティスを説明します。

GPU ワークロード (例: AI モデルのトレーニング、リアルタイム推論、シミュレーション、ビデオ処理など) は、多くの場合、以下のような構成に依存します。

  • GPU ドライバーが適切で、ランタイムに互換性がある。
  • GPU リソースのスケジュールが正確に設定されている。
  • コンテナー内で GPU ハードウェア デバイスにアクセスできる。

構成の不備は、大きなコスト、想定外のジョブ エラーや、GPU を有効活用できない状態の発生につながります。

正しい GPU ワークロード配置を強制的に適用する

既定では、AKS スケジューラは、十分な CPU とメモリが使える任意の利用可能ノードにポッドを配置します。 このため、ガイダンスを設定しない場合、以下 2 つの重要な問題が発生することがあります。

  1. GPU ワークロードが GPU 非搭載ノード上にスケジュールされ、起動に失敗する。
  2. 汎用ワークロードによって GPU ノードが占有され、高コストのリソースが浪費される。

正しい配置を適用するには以下のようにします。

  • [gpu-vendor].com/gpu: NoSchedule などのキーを使って GPU ノードをテイントします (例: nvidia.com/gpu: NoSchedule)。 これにより、GPU 非対応ワークロードをそのノード上にスケジュールしないようブロックすることができます。
  • 対応する容認値を GPU ワークロードのポッド スペックに追加して、テイントした GPU ノード上にそれらをスケジュールできるようにします。
  • スケジューラに GPU 容量を確実に予約させるため、以下のように、GPU リソースの要求と制限をポッド内に定義します。
resources:
  limits:
    [gpu-vendor].com/gpu: 1
  • 検証ポリシーまたはアドミッション コントローラーを使って、GPU ワークロードに、必要な容認とリソース制限を含めることを強制します。

このアプローチにより、GPU 対応のワークロードのみを GPU ノードに配置させ、必要とされる特殊なコンピューティング リソースへのアクセスを提供できます。

実稼働 GPU ワークロードをデプロイする前に、GPU ノード プールが以下を満たしていることを必ず確認してください。

  • 互換性のある GPU ドライバーが装備されている。
  • 正常な Kubernetes デバイス プラグイン DaemonSet をホストしている。
  • 公開しているスケジュール可能リソースに [gpu-vendor].com/gpu が含まれている。

GPU ノード プールで現在実行されているドライバーのバージョンは、GPU ベンダーに関連付けられているシステム管理インターフェイス (SMI) を使って確認できます。

以下のコマンドは、NVIDIA GPU 対応ノード プール上のドライバー インストール状況とランタイムの準備状況を確認するために、GPU デバイス プラグイン デプロイ ポッド内から nvidia-smi を実行します。

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

出力は、次の出力例のようになります。

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

上記の手順を個々の GPU ノード プールに対して実行し、各ノードにインストールされているドライバーのバージョンを確認します。

AMD GPU 対応ノード プールについては、代わりに AMD GPU コンポーネントをデプロイし、ROCm デバイス プラグイン ポッド内で amd-smi コマンドを実行して、インストールされているドライバーのバージョンを確認します。

GPU 対応ノード上のノード OS イメージを常に最新の状態に更新しておく

AKS 上の GPU ワークロードのパフォーマンス、セキュリティ、互換性を確実に維持するには、推奨される最新のノード OS イメージを GPU ノード プールに適用した状態を常に保つことが不可欠です。 以下の理由により、それらの更新プログラムはきわめて重要です。

  • 非推奨バージョンやサポート終了 (EOL) バージョンを置き換える運用グレードの最新 GPU ドライバーが含まれている。
  • お使いの現行 Kubernetes バージョンとの互換性が完全にテストされている。
  • GPU ベンダーが確認した既知の脆弱性についての対策が施されている。
  • OS とコンテナー ランタイムの最新の機能強化が組み込みまれ、安定性と効率性が向上している。

GPU ノード プールを AKS からリリースされた最新の推奨ノード OS イメージに アップグレードするには、自動アップグレード チャネルを設定する方法と、手動アップグレードを使う方法があります。 最新のノード イメージ リリースの監視と追跡管理は、AKS リリース トラッカーで行うことができます。

共有クラスターを使う場合の GPU ワークロードの分離

GPU ノード プールを持つ単一の AKS クラスター内で複数種類の GPU ワークロード (例: モデル トレーニング、リアルタイム推論、バッチ処理など) が実行されている場合は、以下の目的のために、それらのワークロードを分離することが重要です。

  • 異なる種類のワークロード間に偶発的な干渉やリソース競合が発生することを避ける。
  • セキュリティを改善し、コンプライアンスの境界を維持する。
  • GPU リソース使用量の管理と監視をワークロード カテゴリ別にシンプルに行う。

名前空間とネットワーク ポリシーを使うと、単一の AKS クラスター内にある GPU ワークロード間を分離することができます。 これにより、各種ワークロードに特有のクォータ、制限、ログ記録構成を設定でき、より明確なガバナンスが可能になります。

サンプル シナリオ

例として、相互通信の必要がない 2 種類の GPU ワークロードをホストする AKS クラスターの場合を考えてみましょう。

  • トレーニング ワークロード: リソースを集中的に使用する AI モデル トレーニング ジョブ。
  • 推論ワークロード: 待ち時間を抑えることが重要なリアルタイム推論サービス。

これら 2 つのワークロードを分離するには、以下の手順を実行します。

  1. kubectl create namespace コマンドを使って、ワークロードの種類ごとに専用の名前空間を作成します。

    kubectl create namespace gpu-training
kubectl create namespace gpu-inference

  2. GPU ワークロード ポッドに、以下のような種類別のラベルを付けます。

    metadata:
  namespace: gpu-training
  labels:
    workload: training

  3. ネットワーク ポリシーを適用して、トラフィックをワークロードの種類別に分離します。 以下のマニフェストは、gpu-training 名前空間のすべてのイングレスとエグレスを (明示的に許可されたものを除き) ブロックします。

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: gpu-training
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress: []
  egress: []

このポリシー:

  • これは、gpu-training 名前空間内のすべてのポッドに適用されます。
  • すべての着信トラフィックと送信トラフィックを既定で拒否し、強力な分離をサポートします。

このモデルには、共有 GPU 環境における明確さ、制御の的確さ、安全性を高める効果があります。特に、ランタイム プロファイル、リスク レベル、運用要件がワークロードの種類によって異なる場合は非常に役立ちます。

GPU ノード上のリソース使用量をマルチインスタンス GPU (MIG) で最適化する

GPU ワークロードは種類によってメモリ要件が大きく異なり、小規模なデプロイ (例: NVIDIA A100 40 GB など) は 1 個の GPU 全体を必要としない場合もあります。 しかし、既定では、たとえ使用率が低くても個々のワークロードが GPU リソースを占有します。

AKS では、マルチインスタンス GPU (MIG) を使って GPU を小さなスライスに分割し、GPU ノードのリソース使用量を最適化する機能がサポートされており、チームにおいて小規模ジョブのスケジュール設定をより効率的に行うことができます。 サポートされている GPU サイズと、AKS でマルチインスタンス GPU の使用を開始する方法についての詳細情報を参照してください。

エフェメラル NVMe データ ディスクを高パフォーマンス キャッシュとして使用する

AKS の GPU VM で実行されている AI ワークロードでは、トレーニングと推論のパフォーマンスを最大化するために、一時ストレージへの高速で信頼性の高いアクセスが不可欠です。 エフェメラル NVMe データ ディスクは、VM ホストに直接接続された高スループットで待機時間の短いストレージを提供するため、データセットのキャッシュ、中間チェックポイントとモデルの重みの格納、データの前処理と分析のためのスクラッチ領域の提供などのシナリオに最適です。

AI ワークロード用に GPU 対応ノード プールをデプロイする場合は、パフォーマンスの高いキャッシュまたはスクラッチ領域として機能するようにエフェメラル NVMe データ ディスクを構成します。 この方法は、I/O のボトルネックを排除し、データを集中的に使用する操作を高速化し、データを待機している間に GPU リソースがアイドル状態にならないことを保証するのに役立ちます。

エフェメラル NVMe データ ディスクは、さまざまな Azure GPU VM ファミリでサポートされています。 GPU VM のサイズに応じて、最大 8 個のエフェメラル NVMe データ ディスクがあり、合計容量は最大 28 TiB です。 VM サイズの詳細な構成については、選択した GPU ファミリの ND H100 v5 シリーズのドキュメント または VM サイズのドキュメントを参照してください。

プロビジョニングと管理を簡素化するには、Kubernetes ワークロードのエフェメラル NVMe ディスクを自動的に検出して調整できる Azure Container Storage を使用します。

推奨されるシナリオは次のとおりです。

Important

エフェメラル NVMe ディスク上のデータは一時的なものであり、VM の割り当てが解除または再デプロイされると失われます。 これらのディスクは、重要でない一時的なデータにのみ使用し、永続的な Azure ストレージ ソリューションに関する重要な情報を格納します。

エフェメラル NVMe データ ディスクの詳細については、 AKS のエフェメラル NVMe データ ディスクのベスト プラクティスを参照してください。

次のステップ

AKS における GPU ワークロードのデプロイと管理の詳細については、以下の記事を参照してください。

  • Last updated on