# 継続的プロファイリング ## 定義 本番システムで継続的にパフォーマンスデータを収集し、メトリクスやトレースが「何が起きているか」を示した後に「なぜそうなっているか」をコードレベルまで掘り下げるオブザーバビリティシグナルである。CPU・Heap・GPU・Mutex・IO・言語固有（Go pprof・JVM・Java pprof）など複数種類のプロファイラで構成される（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）。 ### プロファイラの種別 - **CPU プロファイラ**: 関数ごとの CPU 時間の割合を計測 - **Heap プロファイラ**: メモリ割り当てパターンと漏れを検知 - **GPU プロファイラ**: GPU カーネルの実行時間と占有率を計測 - **Mutex プロファイラ**: ロック競合とデッドロックを計測 - **IO プロファイラ**: ディスク・ネットワーク IO のボトルネックを計測 **サンプリングプロファイラ**: 従来のプロファイリングは計装オーバーヘッドが大きく本番投入が困難だった。統計的サンプリングにより「数%以内」のオーバーヘッドで本番計装が実用的になった（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）。 **アイシクルグラフ**: CPU 時間などのリソース配分を関数呼び出し階層で示す標準的な可視化形式。「炎のグラフ（Flame Graph）」の亜形。 ## 横断的知見 - **本番 CPU プロファイルが LLM コード最適化エージェントのベンチマーク基盤になる**: [[DODO]](Datadog Observability-Driven Optimizer)は Datadog Continuous Profiler の集約フレームグラフ(CPU 時間 1% 未満サブツリーを刈り込み)をグランドトゥルースとして Go マイクロベンチマークを生成し、プロファイル類似度 ≥98% を収束基準とする。これは「継続的プロファイリングのシグナルをリアルタイム障害診断」に使う従来の AIOps 用途から「コード最適化エージェントのベンチマーク生成基盤」への利用拡大を示す。DODO の適用で成熟した内部 Go サービスの CPU コストが 8% 以上削減された点は、継続的プロファイリングが観測だけでなく能動的改善ループの入力として機能することを実証した。(Source: [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]]) - **async-profiler のフレームグラフがエージェント実装の非効率性を特定する**: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]] は async-profiler(safepoint バイアスを回避するサンプリングプロファイラ)を Java トレーシングエージェントの根本原因分析に使用し、OpenTelemetry の `CodeSpanNameExtractor`・`ArrayBasedContext` コピー・`AddThreadDetailsSpanProcessor` など具体的な高コストパスを特定した。プロファイリングの用途が「本番システムの実行時挙動把握」から「Java エージェント実装のボトルネック特定」まで広がることを示す。collapsed ファイルからの手動タグ付けで 5 タスク(MEMORY/TIME/CALL-TREE/METADATA/QUEUE)に分類する手法は、フレームグラフの機械的解析ではなくコード解析と組み合わせた半構造化アプローチ。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **プロファイリングと LLM 推論最適化の接点**: GPU プロファイラは LLM 推論の[[カーネルフュージョン]]・[[コアレスドメモリアクセス]]・Attention 実装の最適化発見に使われる。[[eBPF]] ベースの非侵襲プロファイラ（[[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]）が LLM 推論演算子単位で侵襲なし計装を実現した。これは CNCF Whitepaper の「ギャップ 1: 自動/非侵襲計装」に対する部分的な回答と位置づけられる（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]）。 - **サンプリングによる低オーバーヘッド化という設計原則は、CNCFの本番プロファイラと2020年時点のOSプロファイラ理論で一致する**: 『詳解 システム・パフォーマンス 第2版』4章は、CPU プロファイリングにおいてタイマーベースのサンプリング(典型的に99Hz。ターゲットの周期との同期を避けるため100Hzを避ける)がオーバーヘッドを予測可能にし、必要な水準まで発生頻度を調整できるため「一般に安全」だと説明する(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]])。この「イベント全数計装(トレーシング)でなくサンプリングでオーバーヘッドを抑える」という原則は、CNCF Whitepaperが継続的プロファイリングを「統計的サンプリングにより数%以内のオーバーヘッドで本番投入が実用的になった」シグナルと位置づける根拠と同型であり、OSカーネルレベルのCPUプロファイリング理論(2020年)が3年後のオブザーバビリティ標準化(CNCF, 2023年)でプロファイルシグナルの設計原則としてそのまま踏襲されたことを示す。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]], [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - **「タイマーベースサンプリングは頻繁な事象の観測に向く」という99Hzの設計原則の系譜は、2020年のOSプロファイラ理論よりさらに29年遡り、1991年のモニタ分類論に既に明記されている**: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.2は、事象駆動(event-driven)モニタは「事象がまれならオーバーヘッドはほぼゼロだが、事象が頻繁だと過大なオーバーヘッドを生む」のに対し、サンプリング型(sampling monitor、クロック割り込みで一定間隔起動)は「オーバーヘッドが事象頻度に依存しないため頻繁な事象の観測に理想的」と明言する。『詳解 システム・パフォーマンス 第2版』が2020年に示した「タイマーベースサンプリングがオーバーヘッドを予測可能にする」という説明は、この1991年モデルの言い換えに近い。すなわち「サンプリングでオーバーヘッドを事象頻度から切り離す」という継続的プロファイリングの根幹原則は、少なくとも1991年のモニタ設計論まで遡れる、計算機性能測定における古典的な知見である。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.2, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]]) - **1991年時点では「サンプリング頻度をどう決めるか」は事象頻度と要求解像度から一般論として述べられるにとどまり、99Hzのような具体的な数値には未到達である**: 第7章§7.2は「サンプリングの頻度は事象頻度と要求される解像度で決まる」と原理を述べるが、周期同期を避けるための具体的な周波数(99Hz)のような実装上の知見は含まない。この種の具体的な数値指針は、OSのタイマー割り込み機構がより精密に理解された後年の実践(2020年のBrendan Gregg の説明)で初めて明文化されたと考えられ、原理の発見(1991年)と実装上の精緻化(2020年)の間に約30年の時間差があることを示す。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.2, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]]) - **プロファイリングとトレーシングの粒度トレードオフを、プロファイルを秒単位・スパン単位でインデックス化することで解消するという設計思想が、CNCF Whitepaperのシグナル分類に具体的な統合方法を与える**: CNCF Whitepaper(2023)はプロファイルをメトリクス・トレース・ログと並ぶ独立シグナルとして位置づけるにとどまるが、`Observability Engineering`第2版第20章はより踏み込み、トレーシングが提供する「リクエストレベル・外側関数粒度の俯瞰」と、プロファイリングが提供する「内側関数レベルだがプロセス全体粒度の詳細」という相補的なトレードオフを明示したうえで、プロファイルを秒単位のデータやトレーススパンに紐づけてインデックス化すれば両方の粒度を同時に得られるという統合の具体的な方向性を示す。これはCNCF Whitepaperが指摘する「シグナル間の相関」というギャップに対する、プロファイル×トレースの組み合わせに特化した回答と位置づけられる。(Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) - **継続的プロファイリングツールの導入判断が、単一エンジニアの関心事から複数チーム横断の要件へ拡大した実例が加わる**: HoneycombではDODOのような外部の「LLMコード最適化ベンチマーク基盤」への応用に先立つ段階として、2024年末に継続的プロファイリングツールの選定に半数以上の異なるチームが関与するようになったと`Observability Engineering`第2版第20章は述べる。これはDODO(Datadog)がすでに確立された継続的プロファイリング基盤の上に構築されるベンチマーク応用であるのに対し、Honeycombの事例は組織がそもそも継続的プロファイリングをどう全社的な実践として定着させるかという、より前段階の採用プロセスを示す。(Source: [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) - **アイシクルグラフ/フレームグラフが示す「自己時間対継承時間」の区別は、1991年のプログラム実行モニタの階層的プロファイルレポート論点にすでに明記されている**: 継続的プロファイリングの標準的可視化であるアイシクルグラフ・フレームグラフは、関数呼び出し階層でのCPU時間などのリソース配分を示すが、この背後には「あるプロシージャが直接消費した資源(self-time)」と「それが呼んだ下位プロシージャが消費した資源(inherited time)」を区別するという設計判断がある。[[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] §8.1.1は、この自己時間対継承時間の区別と、モジュール別→プロシージャ別→文別という階層的サマリー、詳細度のズームイン・ズームアウト機能を、1991年時点のプログラム実行モニタの標準的な設計要件として既に明記している。フレームグラフという可視化形式そのものは後年の発明だが、それが表現する情報構造(呼び出し階層別の自己時間・継承時間の分解)は1991年のプロファイルレポート論点と同一であり、継続的プロファイリングの可視化設計原則が計装技術の進歩によらず構造的に不変であることを、[[モニタの分類と設計トレードオフ]]が示す事象駆動対サンプリングの不変性とは別の角度から裏付ける(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] §8.1.1)。 - **「測定単位の粒度が低いほどオーバーヘッドが増す」という1991年の一般原則は、MLプロファイリングにおけるGPU対TPUのオーバーヘッド非対称性という2026年の実測知見と整合する**: 第8章§8.1.1は「測定単位のレベルが低いほど(機械命令水準に近いほど)モニタリングのオーバーヘッドが増す」と述べる。これは、[[MLプロファイリング]]が報告するXProf(MLSys2026)の実測――GPU(H100)プロファイラがカーネル単位の高頻度コールバックという細粒度の計装方式を取るためTPUプロファイラ(0.3%未満)より一桁近く高いオーバーヘッド(0.13%〜2.30%)を示す――の一般原理として読める。両者を重ねると、「観測粒度とオーバーヘッドはトレードオフの関係にある」という1991年の定性的原則が、35年後のヘテロジニアスアクセラレータ環境でも定量的に再現されていることがわかる(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] §8.1.1, [[MLプロファイリング]])。 ## 未解決の問い - プロファイルデータを LLM コード最適化エージェントのベンチマーク基盤として使う場合、プロファイル収集の時間軸(スナップショット vs 継続集計)と最適化対象関数の選択基準(CPU 占有率閾値、変更頻度)をどう設計すべきか。DODO は「1% 未満を刈り込む」シンプルなヒューリスティックだが、より体系的な基準は？ - 継続的プロファイリングのデータはどこに蓄積・検索されるべきか？ CNCF Whitepaper がログ/トレース/プロファイルの OSS DB 不足をギャップとして挙げているが、2025〜2026 年時点でのエコシステム成熟度は？ - GPU プロファイリングと CPU プロファイリングの統合ビューは標準化されつつあるか？ HPC・AI ワークロードでは GPU/CPU 境界のボトルネックが支配的であり、統合観測が重要になる。 - 1991年の課金ログ(accounting log、[[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] §8.3)は「別目的で常時取得されているデータを性能解析に転用する」という発想を示すが、これは継続的プロファイリングが目指す「専用計装による低オーバーヘッド常時収集」とは対照的な戦略である。クラウド環境のコスト・使用量データのような課金目的の既存テレメトリを、継続的プロファイリングの補完(専用計装が使えない環境でのフォールバック)として転用する実践は現代でも成立するか。 ## 関連 - [[オブザーバビリティ]] — 5 シグナルのひとつ - [[テレメトリ]] — 収集・転送の基盤 - [[ハードウェアカウンタ]] — CPU/GPU の低レベル計測 - [[GPU観測性]] — GPU ワークロードのプロファイリング - [[eBPF]] — 非侵襲プロファイリングの実装基盤 - [[DODO]] — Datadog Continuous Profiler を LLM コード最適化のベンチマーク基盤として活用 - [[本番接地型ベンチマーク]] — CPU プロファイルをコード最適化評価に使う設計原則 - [[Brendan Gregg]] — タイマーベースプロファイリングの99Hz設計原則の提示者 - [[Honeycomb.io]] — 2024年末に複数チーム横断で継続的プロファイリングツールを選定した実例 - [[フレームグラフ]] / [[クリティカルパス分析]] — トレーシングとプロファイリングを組み合わせる関連メソドロジ - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] — 事象駆動対サンプリング型モニタの分類の初出。「サンプリングはオーバーヘッドを事象頻度から切り離す」原則の1991年時点での定式化 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] — 自己時間対継承時間の区別・階層的プロファイルレポート・測定単位の粒度対オーバーヘッドの1991年時点での定式化 - [[モニタの分類と設計トレードオフ]] — 上記の1991年モデルを扱う姉妹概念 ## 出典 - [[@2023__CNCF TAG Observability__Observability Whitepaper]] - [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]] - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]](タイマーベース/イベントベースプロファイリングの分類、99Hzサンプリングの理由、オーバーヘッド設計原則) - [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]("Using the Correct Observability Signals, Together"、トレーシングとプロファイリングの粒度統合) - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]](§7.2 事象駆動対サンプリング型モニタの分類) - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]](§8.1.1 プログラム実行モニタの測定単位・自己時間対継承時間の区別)