Compute Engine インスタンスと Slurm クラスタをモニタリングする

このドキュメントでは、予約容量を使用して作成した A4X Max、A4X、A4、A3 Ultra、A3 Mega の Compute Engine インスタンスをモニタリングする方法について説明します。具体的には、このドキュメントでは、Cloud Monitoring ダッシュボードを使用して、スタンドアロン コンピューティング インスタンスまたは Slurm クラスタのパフォーマンス ボトルネックを特定してトラブルシューティングする方法について説明します。これらのダッシュボードを使用すると、ワークロードのダウンタイムとパフォーマンスの問題を最小限に抑えることができます。

事前構築済みの Monitoring ダッシュボードを作成または使用して、スタンドアロン コンピューティング インスタンスまたは Slurm クラスタをモニタリングする場合は、次の項目をモニタリングできます。

• コンピューティング インスタンスの健全性

• GPU パフォーマンス

• ネットワーク伝送効率

• ブロックとサブブロック間のネットワーク効率

• 機械学習（ML）ワークロードの効率

• ストラグラー検出

始める前に

ワークロードをモニタリングする前に、次の手順を完了します（まだ完了していない場合）。

• モニタリング可能なワークロードをデプロイする。サポートされているワークロードについては、このドキュメントの制限事項をご覧ください。ワークロードをデプロイする方法については、デプロイ オプションの概要をご覧ください。

• ワークロードのモニタリング サービス Google Cloud について学習する:

  • このドキュメントの指標は、Monitoring ダッシュボードを使用します。モニタリング ダッシュボード、モニタリングの保持期間、モニタリングの料金について学習する。

  • Straggler 検出では、Cloud Logging にログエントリも提供されます。Logging インターフェース、Logging の保持期間、Logging の料金について学習する。

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

制限事項

• このドキュメントの指標は、次のすべての条件を満たすコンピューティング インスタンスで実行されるワークロードでのみサポートされます。

  • コンピューティング インスタンスは、スタンドアロンの Compute Engine インスタンスとして作成するか、Slurm クラスタの一部として作成する必要があります。
  • コンピューティング インスタンスは、予約済み容量を使用して作成されている必要があります。
  • コンピューティング インスタンスは、A4X Max、A4X、A4、A3 Ultra、A3 Mega のマシンシリーズを使用する必要があります。
    • ただし、遅延検出では、A3 Mega マシンシリーズを使用する仮想マシン（VM）インスタンスもサポートしています。
  注意: A4X Max、A4X、A4、A3 Ultra、A3 Mega 以外のマシンシリーズでも指標が表示されることがありますが、それらの指標は正しくない可能性があります。
• インフラストラクチャ指標の既知の問題:

  • 一部のコンピューティング インスタンスでは、GPU Power Consumption 指標が表示されない場合があります。
  • 一部のコンピューティング インスタンスでは、GPU Temperature 指標または GPU Thermal Margin 指標が表示されないか、指標の代わりに NaN が表示されることがあります。
  • 指標が収集されてから 7 分間は、 Google Cloud コンソールに表示されないことがあります。

• ML ワークロードの指標をモニタリングするには、ワークロードのモニタリングを設定する必要があります。

• 遅延検出指標には、次の追加の制限があります。

  • A3 Mega 以外のサポートされているマシンシリーズの場合、遅延検出は、Collective Communication Analyzer（CoMMA）ライブラリを有効にして NCCL テレメトリーを Google Cloud サービスにエクスポートするコンピューティング インスタンスのみをサポートします。詳細については、CoMMA の概要をご覧ください。

  • 注意: 次のような遅延検出を使用すると、偽陽性または偽陰性が表示されることがあります。

    • Straggler 検出ログには、Straggler 検出をサポートしていないコンピューティング インスタンスは Straggler の疑いがないことが報告されます。
    • 多くの ML ワークロードでは、ストラグラーの検出は正確ですが、複雑な通信パターンを持つワークロードでは不正確になる可能性が高くなります。

    したがって、他の指標でワークロードに問題が発生していることが示されている場合にのみ、疑わしい遅延を処理することをおすすめします。ワークロードの全体的なパフォーマンスが満足のいくものである場合は、対応は推奨されません。

  • 通常、ストラグラーの検出には最長で 10 分ほどかかります。
  • このドキュメントの他の指標とは異なり、プロジェクトの遅延検出指標をクラスタ、ブロック、サブブロック、コンピューティング インスタンスでフィルタすることはできません。ただし、遅延の疑いがある 1 つ以上のコンピューティング インスタンスの ID で、遅延検出ログのクエリをフィルタできます。

必要なロール

AI Hypercomputer ワークロードの指標をモニタリングするために必要な権限を取得するには、次の IAM ロールを付与するように管理者に依頼してください。

• Cloud Monitoring で指標を表示するには: プロジェクトに対するモニタリング編集者 （roles/monitoring.editor）
• Logging で遅延検出ログを表示するには: プロジェクトに対するログビューア （roles/logging.viewer）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、AI Hypercomputer ワークロードの指標をモニタリングするために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

AI Hypercomputer ワークロードの指標をモニタリングするには、次の権限が必要です。

• ダッシュボードを表示する: プロジェクトに対する monitoring.dashboards.get
• ダッシュボードを作成する: プロジェクトの monitoring.dashboards.create
• ログエントリを表示する: プロジェクトに対する logging.logEntries.list

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

利用可能な指標

ユースケースに応じて、次の指標を使用して、コンピューティング インスタンスと Slurm クラスタをモニタリングできます。

• コンピューティング インスタンスに接続された GPU の健全性、パフォーマンス、ネットワーク パフォーマンスをモニタリングするには、インフラストラクチャ指標をご覧ください。

• ML ワークロードの GPU の効率をモニタリングするには、ML ワークロードの指標をご覧ください。

• パフォーマンスが遅い ML ワークロードで、遅延の原因となっている可能性のあるコンピューティング インスタンスをモニタリングするには、遅延検出指標をご覧ください。

これらの指標を表示する方法については、このドキュメントの指標を可視化するをご覧ください。

インフラストラクチャ指標

コンピューティング インスタンスに接続された GPU の健全性、パフォーマンス、ネットワーク パフォーマンスをモニタリングするには、次の指標を使用します。

• GPU の健全性指標

• GPU パフォーマンス指標

• GPU ネットワーク パフォーマンス指標

• GPU の致命的なエラーの指標

Compute Engine で使用可能な指標の概要については、Google Cloud 指標をご覧ください。

GPU の健全性指標

GPU の健全性をモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
マシンのステータス	machine/machine_status	A4X Max、A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスが使用するマシンが正常かどうか。または、マシンが異常で修復が必要かどうか。
NVSwitch のステータス	instance/gpu/nvswitch_status	A4X Max、A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスにアタッチされた NVIDIA GPU の NVLink スイッチで問題が発生しているかどうか。
VM インフラストラクチャの健全性	instance/gpu/infra_health	A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスが実行されているクラスタ、ブロック、サブブロック、ホストの健全性。この指標でコンピューティング インスタンスのインフラストラクチャが異常であることが示されている場合、指標には問題も記述されます。
VM 障害予測スコア	instance/gpu/failure_prediction_score	A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスが実行されているホストが、今後 5 時間以内にパフォーマンスが低下する可能性。値は 0.0～1.0 の範囲で指定できます。値が一定期間 1.0 に近いほど、コンピューティング インスタンスが劣化する可能性が高くなります。その場合は、ジョブを別のコンピューティング インスタンスに移動し、コンピューティング インスタンスで問題が発生した場合は、そのホストを障害として報告することをおすすめします。

GPU パフォーマンス指標

GPU のパフォーマンスをモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
累積コンテキスト使用率	instance/gpu/accumulated_context_utilization_seconds	A4X Max、A4X、A4、A3 Ultra、A3 Mega	GPU がワークロードの処理に費やした合計時間（秒単位）。
GPU 消費電力	instance/gpu/power_consumption	A4X Max、A4X、A4、A3 Ultra、A3 Mega	ホスト上の個々の GPU で消費される電力（ワット単位）と 10 進数値。複数の GPU が接続されているコンピューティング インスタンスの場合、この指標はホスト上の各 GPU の消費電力を個別に示します。
SM 使用率	instance/gpu/sm_utilization	A4X Max、A4X、A4、A3 Ultra、A3 Mega	ゼロ以外の値は、GPU のストリーミング マルチプロセッサ（SM）がアクティブに使用されていることを示します。
GPU の温度	instance/gpu/temperature	A4X Max、A4X、A4、A3 Ultra、A3 Mega	ホスト上の個々の GPU の温度（摂氏（℃）単位の 10 進数値）。複数の GPU が接続されているコンピューティング インスタンスの場合、この指標はホスト上の各 GPU の温度を個別に提供します。
GPU のサーマル マージン	instance/gpu/tlimit	A4X Max、A4X、A4、A3 Ultra、A3 Mega	個々の GPU が高温のために速度を落とす必要が生じる前に、その GPU が持つ熱ヘッドルーム（摂氏（℃）および 10 進数値）。複数の GPU が接続されているコンピューティング インスタンスの場合、この指標はホスト上の各 GPU の熱ヘッドルームを個別に提供します。

GPU ネットワーク パフォーマンス指標

GPU のネットワーク パフォーマンスをモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
Link Carrier Changes	instance/gpu/link_carrier_changes	A4X、A4、A3 Ultra、A3 Mega	ネットワーク リンクのキャリアが 1 分間に変更される頻度。
ネットワーク RTT	instance/gpu/network_rtt	A4X、A4、A3 Ultra、A3 Mega	ネットワーク データが送信元と宛先の間を移動するラウンドトリップ時間（マイクロ秒単位）。
ブロック間のネットワーク トラフィック	instance/gpu/network/inter_block_tx	A4X、A4、A3 Ultra、A3 Mega	ブロック間のネットワーク トラフィックのバイト数。
サブブロック間のネットワーク トラフィック	instance/gpu/network/inter_subblock_tx	A4X、A4、A3 Ultra、A3 Mega	サブブロック間のネットワーク トラフィックのバイト数。
サブブロック内のネットワーク トラフィック	instance/gpu/network/intra_subblock_tx	A4X、A4、A3 Ultra、A3 Mega	単一のサブブロック内のネットワーク トラフィックのバイト数。
NVLink アクティブ速度	instance/gpu/nvlink_active_speed	A4X Max、A4X、A4、A3 Ultra、A3 Mega	現在のアクセスリンクのポート速度（Gbps）。
スループット（受信バイト数）	instance/gpu/throughput_rx_bytes	A4X、A4、A3 Ultra、A3 Mega	ネットワーク トラフィックから受信したバイト数。
スループット TX バイト数	instance/gpu/throughput_tx_bytes	A4X、A4、A3 Ultra、A3 Mega	ネットワーク トラフィックに送信されたバイト数。

GPU 致命的エラー指標

GPU で発生し、コンピューティング インスタンスの停止を強制したり、パフォーマンスに悪影響を及ぼす可能性のあるエラーをモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
NVLink ランタイム エラー	instance/gpu/nvlink_runtime_error	A4X Max または A4X	NVLink ランタイム エラーが発生したかどうか。
修正不可能な DRAM ECC エラー	instance/gpu/dram_uncorrectable_ecc_error_count	A4X Max または A4X	GPU ダイナミック ランダム アクセス メモリ（DRAM）内の訂正不能な誤り訂正コード（ECC）の数。
訂正不可能な DRAM 行の再マッピング数	instance/gpu/dram_uncorrectable_row_remapping_count	A4X Max または A4X	GPU DRAM の訂正不可能なエラーからの行の再マッピングの数。
修正不可能な DRAM 行の再マッピングに失敗しました	instance/gpu/dram_row_remapping_failed	A4X Max または A4X	次のいずれかの問題により、GPU DRAM の行の再マッピングが失敗したかどうか。 メモリバンクにはすでに 8 つの訂正不能なエラー行が再マッピングされているため、メモリバンクの再マッピングの試行が失敗しました。 行がすでに再マッピングされているため、行の再マッピングの試行が失敗しました。 合計 512 回のリマッピングが発生したため、リマッピングの試行が失敗しました。
訂正不能な PCIe エラー	instance/gpu/pcie_fatal_error_count	A4X Max または A4X	修正不可能な Peripheral Component Interconnect Express（PCIe）エラーの数。
訂正不能なキャッシュ ECC エラー	instance/gpu/cache_uncorrectable_ecc_error_count	A4X Max または A4X	キャッシュ メモリ内の訂正不可能な ECC の数。

ML ワークロードの指標

ML ワークロードの生産性（特にスループット）をモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
生産的な時間	workload/goodput_time	A4X、A4、A3 Ultra、A3 Mega	ワークロードがグッドプット アクティビティに費やした時間（秒）。これらのアクティビティは、モデル トレーニング中のフォワード パスやバックワード パスなど、有用なコアタスクです。
非生産的な時間	workload/badput_time	A4X、A4、A3 Ultra、A3 Mega	ワークロードが badput アクティビティに費やした時間（秒）。これらのアクティビティは、トレーニング用のデータの読み込みや前処理などのオーバーヘッド タスクです。

ストラグラー検出指標

遅延検出指標は、遅延の疑いがあるものを特定するのに役立ちます。ストラグラーは、最終的にワークロード全体を遅くする単一障害点であり、クラッシュしない障害です。

VM の遅延タスクの検出をモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
Suspected Stragglers	instance/gpu/straggler_status	A4X、A4、A3 Ultra、A3 Mega	ワークロードのパフォーマンスに影響を与えている遅延 VM である疑いがあるかどうか。他の指標でワークロードに問題が発生していることが示されている場合にのみ、遅延していると思われるタスクに対処することをおすすめします。

また、A4X、A4、A3 Ultra、A3 Mega インスタンスのログエントリで、ストラグラー検出指標を確認することもできます。たとえば、次のクエリを使用できます。

説明	クエリ
特定の VM の遅延が疑われるログ。このクエリを使用して、プロジェクト内の特定のワークロードにストラグラーの疑いがあるかどうかを確認します。	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID" INSTANCE_ID は、VM の ID に置き換えます。指定する VM を追加するごとに、次の条件をクエリに追加します。 OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
プロジェクトの遅延検出からのすべてのログ。このクエリを使用して、疑わしい遅延タスクが検出されなかった場合に、遅延タスク検出サービスが実行されているかどうかを確認します。（制限により、特定の VM で疑わしい遅延のないログをフィルタすることはできません）。	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

ストラグラー検出指標は、次の理由から、大規模な ML ワークロードに特に役立ちます。

• 大規模な ML ワークロードは、ストラグラーの影響を受けやすい。大規模な ML ワークロードでは、同期型の超分散コンピューティングが使用されます。（つまり、同時に実行される相互依存性の高いコンポーネントが多数存在します）。このアーキテクチャでは、大規模な ML ワークロードが straggler などの単一障害点の影響を受けやすくなります。

• 大規模な ML ワークロードで遅延を特定して特定することは非常に困難です。参考として、単一障害点には次の 2 つのタイプがあることを考慮してください。

  • 停止障害: システム全体を停止させる障害（ホストエラーやメンテナンス イベントなど）。比較的簡単に検出して解決できます。

  • slow failures: クラッシュせずにパフォーマンスが大幅に低下する障害。特定とデバッグが非常に困難です。

  遅延障害の性質上、特に大規模な同期ワークロードでは、遅延を検出して特定することが本質的に困難です。

指標を表示する

コンピューティング インスタンスと Slurm クラスタの指標を表示するには、次のように Monitoring ダッシュボードを使用します。

• インフラストラクチャの指標とストラグラー検出の指標を表示するには、次の操作を行います。

  • インフラストラクチャの健全性とパフォーマンスの概要をすばやく確認する場合や、既存のダッシュボードをカスタマイズする場合は、事前構築済みのダッシュボードを使用します。

  • 特定のモニタリング ニーズに合わせて、カスタム ダッシュボードを作成します。

• ML ワークロード指標を表示するには、ワークロードのモニタリングを設定する方法に関するドキュメントをご覧ください。

• 遅延検出のログを表示するには、遅延検出ログを表示するをご覧ください。

ダッシュボードの使用時に問題が発生した場合は、パフォーマンスの低下に関するトラブルシューティングをご覧ください。

事前構築済みのダッシュボードを使用する

AI Hypercomputer 用に事前構築された Monitoring ダッシュボードを使用して、コンピューティング インスタンスと Slurm クラスタの指標を表示できます。事前構築されたダッシュボードのコピーを作成して、ニーズに合わせて変更することもできます。

AI Hypercomputer 用の事前構築済みダッシュボードを使用する手順は次のとおりです。

1. Google Cloud コンソールで [ダッシュボード] ページに移動します。

   [ダッシュボード] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. [名前] 列で、表示する指標に基づいて、次のいずれかのダッシュボードの名前をクリックします。

   • コンピューティング インスタンスの正常性、GPU パフォーマンス、ストラグラーの検出をモニタリングするには、Cluster Director Health Monitoring ダッシュボードを使用します。

     これらの指標を使用して問題を特定して分析する方法については、GCE Interactive Playbook - Cluster Director Health Monitoring プレイブック ダッシュボードもご覧ください。

   • ネットワーク伝送効率をモニタリングするには、クラスタ ディレクタ伝送効率ダッシュボードを使用します。

   • ブロックとサブブロック間のネットワーク効率をモニタリングするには、クラスタ ディレクター ブロック ネットワーク ダッシュボードを使用します。

     これらの指標を使用して問題を特定して分析する方法については、GCE Interactive Playbook - Cluster Director Block Network プレイブック ダッシュボードもご覧ください。

   選択したダッシュボードの詳細ページが開きます。ツールバーの期間セレクタを使用して、データの期間を変更できます。

3. 省略可: ダッシュボードのコピーを作成してニーズに合わせてカスタマイズするには、 [ダッシュボードをコピー] をクリックします。

カスタム ダッシュボードを作成する

カスタムのモニタリング ダッシュボードを作成する手順は次のとおりです。

1. モニタリングする指標を選択します。まだ確認していない場合は、このドキュメントの使用可能な指標をご覧ください。

2. カスタム ダッシュボードを作成して管理する。

遅延検出ログを表示する

ログ エクスプローラを使用して遅延検出ログを表示する手順は次のとおりです。

1. Google Cloud コンソールで、セグメント [ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] の結果を選択します。

   デフォルトでは、このページはプロジェクト内のすべてのログをクエリします。[クエリを停止] をクリックします。

2. ツールバーの期間セレクタを使用して、分析する期間を選択します。

3. [クエリ] ペインに、遅延検出ログのクエリを入力します。

4. [クエリを実行] をクリックします。

以下に、遅延検出ログエントリの例を示します。

  {
    ...
    "jsonPayload": {
      ...
      "@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
      "suspectedStragglersDetection": {
        "numNodes": 4,
        "nodes": [
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_1"
          },
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_2"
          },
          {
            "instanceId": "INSTANCE_ID_3",
            "latencyMs": 4
          },
          {
            "instanceId": "INSTANCE_ID_4",
            "latencyMs": 0
          }
        ],
        "message": "Suspected stragglers detected."
      }
    },
    "resource": {
      "type": "project",
      "labels": {
        "project_id": "PROJECT_NUMBER"
      }
    },
    ...
    "severity": "INFO",
    "logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
    ...
  }
  

このログエントリは、次のフィールドで構成されています。

• numNodes: プロジェクトで検出された、遅延している可能性のあるコンピューティング インスタンスの数。この例では、4 つの疑わしいストラグラー コンピューティング インスタンスが検出されています。
• instanceId: ストラグレアの疑いがあると検出されたコンピューティング インスタンスの ID。

次のステップ

• VM の観察とモニタリング
• クラスタの健全性スキャナを使用してクラスタをテストする
• Google Cloud サービスのダッシュボードをカスタマイズする
• パフォーマンスの低下に関するトラブルシューティング