## 概要 [[坪内佑樹]]（[[さくらインターネット研究所]]）が Observability Conference Tokyo 2025 で発表したスライド。AI スパコンサービス「[[SAKURAONE]]」のオブザーバビリティ現状と、クラウドネイティブ分野とのギャップ（オブザーバビリティギャップ）を整理し、3 つのギャップ（学習処理性能のボトルネック特定・アプリかインフラかの問題切り分け・マイクロバーストモニタリング）を研究開発で解消する方針を示す。 ## 主要メッセージ - AI スパコンサービスのオブザーバビリティは「ハードモード」である。アプリケーションコードの計装不可・GPU/RDMA 通信の特殊性により、既存の OTel + Grafana ベースのリソース分析ではワークロード分析に届かない。 - OTel Collector を中心としたメトリクス・ログ・プロファイル基盤を構築済みだが、ログとプロファイルは有効利用できていない（p.34）。 - ギャップ解消の方向として、eBPF による GPU ゼロコード計装（CUDA API 層・ドライバ層・GPU 内部層）と、R-Pingmesh による RoCE ネットワーク常時監視を挙げる。 ## 視覚的に重要な図表 **p.13 さくらONE の構成** ![[_attachments/o11yconjp2025/page-013.png]] 12,000 CPU コア・800 GPU（H100）・800 NIC（400 GbE）・800 GbE インターコネクト・200 GbE ストレージネットワーク・2PB ストレージの 100 ノード構成。 **p.18 AI スパコンサービスのオブザーバビリティ要求** ![[_attachments/o11yconjp2025/page-018.png]] ユーザー観点（学習処理性能・計算資源利用率）とプロバイダ観点（障害・故障管理・計算資源利用率）を、ワークロード分析とリソース分析の 2 軸で整理。 **p.19 責任境界による計装・収集の制約** ![[_attachments/o11yconjp2025/page-019.png]] プロバイダはアプリケーションコードの計装不可・アプリログの収集不可。OS・ドライバ・デバイス・ジョブスケジューラのみが計装対象。 **p.32 データパイプラインの構成（全体像）** ![[_attachments/o11yconjp2025/page-032.png]] GPU ノード（100）・ログインノード（1）・インターコネクトスイッチから OTeL Collector Agent → OTeL Collector Gateway → VictoriaMetrics / VictoriaLogs / Pyroscope → Grafana のフロー。 **p.33 GPU ノードの構成** ![[_attachments/o11yconjp2025/page-033.png]] Node Exporter・DCGM Exporter・Lustre Exporter（GSI-HPC）・IPMI Exporter・Process Exporter・RDMA Exporter（自作、github.com/yuuki/rdma_exporter）が OTeL Collector Agent を経由。opentelemetry-ebpf-profiler でゼロコードプロファイリング。 **p.36 オブザーバビリティギャップ** ![[_attachments/o11yconjp2025/page-036.png]] ギャップ (1) 学習処理性能のボトルネック特定（ユーザー/性能観点）、(2) アプリかインフラの問題切り分け（障害・故障観点）、(3) マイクロバーストモニタリング（プロバイダ/投資効果観点）。 **p.43 GPU ゼロコード計装の最先端** ![[_attachments/o11yconjp2025/page-043.png]] CUDA API 層（uprobes / libcudart.so）・GPU ドライバ層（tracepoints / kprobes）・GPU 内部層（PTX へ eBPF コード注入、bpftime）の 3 階層。OSDI 2025・HDCS 2025 の最新研究を参照。 **p.44 GPU ゼロコード計装の課題** ![[_attachments/o11yconjp2025/page-044.png]] 分散トレーシングへの帰着には深層学習フレームワーク層・CUDA API 層・GPU ドライバ層・GPU 内部層の各イベントを相関させる必要があるが、そのようなツールは現存しない。研究開発領域。 **p.47 R-Pingmesh** ![[_attachments/o11yconjp2025/page-047.png]] RNIC 間のアクティブプルービングによる RoCE ネットワーク監視。サービストラフィックとは独立した RNIC 単位のプルービング、RoCE パケットによるプルービング、RTT・パケットロスの常時計測の 3 特徴。 **p.50 まとめ** ![[_attachments/o11yconjp2025/page-050.png]] 制約：アプリケーションログ/コードの計装・収集不可。現状：OTel + Grafana でメトリクス・ログ・プロファイル基盤を構築、リソース分析はうまくいっているがワークロード分析が未達。ギャップ：(1) 学習処理過程の分散トレース（eBPF で CUDA/ドライバ/内部層のイベント相関）、(2) アプリかインフラかの切り分け（メッシュ状の RDMA Ping システムの実装）、(3) マイクロバースト監視。 ## 口頭説明・補足 - GPU 利用率 100% であっても演算効率が高いとは限らず、テンソルコア使用率 40–50% でようやく良い効率とされる（p.23 周辺の口頭説明）。 - Grafana の HPE Clusterview パネルプラグインは HPC 専門家に好評で、ラック→サーバ→GPU の入れ子構造を空間的に可視化できる。使い方の理解に半日かかった（口頭説明）。 - ジョブビューのガントチャートは Observability Conference 登壇のために 3 日前に急ぎ作成した。Slurm ジョブ履歴を MariaDB から取得して Grafana で可視化している（口頭説明）。 - PyTorch Profiler のオーバーヘッドに関して、1.42 倍遅延を増加させるという報告がある（EuroMLSys 2023 の論文を引用、p.41）。 - 会場で AI スパコンや大規模 AI 学習に携わっている参加者はほぼ 0 人であり、馴染みのないシステムの事例として技術好奇心の刺激とオブザーバビリティ自体の理解を深める機会と位置づけた（口頭説明）。 - マイクロバースト（ギャップ (3)）は講演時間の制約でスキップ。100 ミリ秒単位で全帯域を使い切った後ゼロに戻るバースト的通信があり、5 秒間隔のスクレイプでは捉えられない問題がある（口頭説明）。 ## 概念・実体への接続 - [[GPU観測性]] — GPU ゼロコード計装の 3 階層整理。先行 SpeakerDeck で触れた内容を本講演で再確認・拡張。 - [[LLM学習モニタリング]] — リソース分析基盤の具体構成（OTel Collector + VictoriaMetrics + Grafana）とワークロード分析の未達を提示。 - [[集合通信]] — Ring アルゴリズムの可視化（p.39）、NCCL エラーコードの不透明さ（p.46）。 - [[RDMA]] — R-Pingmesh による RoCE ネットワーク常時監視。 - [[SAKURAONE]] — システム構成の詳細（100 ノード × 8 H100 GPU、TOP500 #49）。 - [[坪内佑樹]] — 登壇者。SRE から AI スパコンのオブザーバビリティへ。 - [[さくらインターネット研究所]] — 所属組織。 ## 限界・不確実点 - transcript は YouTube 自動字幕（日本語）であり、固有名詞・専門用語の精度に限界がある。 - ギャップ (3) マイクロバーストモニタリングの詳細は講演でスキップされたため、スライド上の情報のみ。 - 発表日は YouTube 動画と SpeakerDeck の公開日から 2025-06-26 と推定。 - R-Pingmesh の実装は発表時点で途中であり未デプロイ（p.48、口頭説明で「まだ実装途中でデプロイできていない」と明言）。