# プローブ効果 ## 定義 プローブ効果(probe effect)とは、計装(計測コードの挿入)がシステムの実際の動作に与える影響である。特に**無効なプローブによるオーバーヘッド**を「disabled probe effect」と呼ぶ。 DTrace は本番適用の前提として **ゼロ・プローブ効果(zero probe effect)** を設計原則に掲げる。「DTrace が存在しないときとまったく同じ速度でシステムが動作する」ことが要件であり、有効化された計装でも「絶対安全(absolutely safe)」— 誤操作でシステム障害を引き起こさない — を保証する([[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]])。 静的計装(LTT・ATOM・Purify 等)は、プローブが無効であっても条件チェックや分岐を含む小さなオーバーヘッドを常に誘発する。これが本番常駐を妨げる根本的な理由である。 ## 横断的知見 - **「disabled probe effect ゼロ」の実現方法は計装方式によって異なる**: DTrace FBT は命令書き換え(no-op / trap 置換)で有効化まで影響ゼロを維持。SDT は no-op マクロでコンパイル時に計装点を埋め込み 150+ 箇所追加しても性能差を計測不能にした。[[eBPF]] の kprobe/uprobe も同様の動的パッチ機構を採用。一方、静的計装の LTT は約 45 イベントを固定定義し、イベントごとに小さなプローブ効果が蓄積する。(Source: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]]) - **GPU 計装では「計装抽象度の選択」がプローブ効果の大きさを決定する**: ホスト側 eBPF uprobe は GPU カーネルに直接は触れず、PTX IR 注入(eGPU)は SASS バイナリ書き換え(NVBit)より低オーバーヘッドと主張される。計装を入れる抽象度の高低がプローブ効果の「場所」と大きさを変える構造は DTrace 時代から不変。(Source: [[動的計装]]) - **DTrace の「zero probe effect」設計原則が解決しようとする問題は、2004年時点で Mark Burgess がシステム管理論の一般原理として同時に定式化していた**: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]]が示す probe effect は特定の計装技術(kprobe/uprobe 相当の動的パッチ)の工学的達成として語られるのに対し、同じ 2004 年に出版された [[@2004__Wiley__Principles of Network and System Administration - Chapter 13 Analytical system administration]] §13.7.1 は「有限のリソースを持つ系である量を測定する行為は、常にその測定が行われる条件そのものを変化させる」という一般原理(Principle 67: Uncertainty)として、CPU使用率計測プログラム自体がCPUを消費し測定条件を変える例とともに提示する。両者は同年に独立に発表されており、DTrace のエンジニアリング的解(disabled probe effect をゼロに設計する)は、Burgess が一般原理として述べた問題の特殊解の一つと読める——ただし Burgess はこの原理を計装技術の設計指針としてではなく、測定結果の解釈(§13.7で展開される誤差論)の前提として位置づけている点で射程が異なる。(Source: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]], [[@2004__Wiley__Principles of Network and System Administration - Chapter 13 Analytical system administration]] §13.7.1) - **カオスエンジニアリング17章(Nathan Aschbacher著)は、DTraceの「zero probe effect」設計原則とBurgess(2004)の一般原理(Principle 67: Uncertainty)がすでに提示した問題を、サイバーフィジカルシステム(CPS)というさらに厳しい制約下で再確認し、カオス実験そのものがプローブ効果の発生源になるという新しい観点を加える**: 本ページはこれまで、DTraceが「disabled probe effectをゼロにする」ことを設計原則に掲げたこと、およびBurgessが同じ問題を「有限のリソースを持つ系である量を測定する行為は、常にその測定が行われる条件そのものを変化させる」という一般原理として独立に定式化したことを記録している(既出)。17章はオシロスコープのプローブ(抵抗・静電容量・アース線のインダクタンス)という物理計測の比喩で同じ現象を導入したうえで、カオスエンジニアリングの領域では「測定によるプローブ効果」に加えて「障害や他の変数を注入するためのシステムのレイヤー」という第二の発生源があると指摘する。低レイテンシIOインタフェイス上でカオス実験用の条件式(「今カオス実験しているか?」)をクリティカルパスに仕込むこと自体が、分岐予測器のようなCPU最適化ハードウェアと相互作用しパイプラインフラッシュを誘発しうるという具体例は、DTrace論文(kprobe/uprobe相当の動的パッチ)やBurgessの一般原理のいずれにもない、「実験のための計装コード自体が新たな障害モードを生む」という観点を付け加える。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.5, [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]], [[@2004__Wiley__Principles of Network and System Administration - Chapter 13 Analytical system administration]] §13.7.1) - **17章の「ダミープローブ」によるベースライン把握という対処法は、DTraceが設計時点でゼロ・プローブ効果を達成する方式と対照的に、事後的・実験的にプローブ効果を切り分ける方式である**: DTraceはSDTのno-opマクロやFBTの命令書き換えといった実装上の工夫により、有効化前のプローブ効果を設計時点でゼロに近づける(既出)。17章が示す対処法は、これとは異なるアプローチを取る——カオスを注入していないときにも同様の負荷をかける「ダミーのプローブ」を作り、その状態でのシステム特性を経験的に測定してから本物のプローブによる実験を行うことで、プローブそのものの影響を事後的に切り分ける。また17章は「利便性と引き換えに正確性を手に入れる」という第三の戦略も提示する——通信の信頼性を評価したいならCPU使用率への副作用は無視してよい、というように、評価したい系の特性にとって無関係なプローブの副作用は許容するという設計判断である。DTraceが計装方式の工学的完成度でゼロ・プローブ効果を目指すのに対し、17章は「プローブ効果は逃れられないもの」という前提のもとで、ベースライン測定と評価対象の絞り込みという運用上の切り分け技法を提示しており、CPSのような厳しい許容範囲を持つ領域では、ゼロを目指す設計(DTrace)よりも影響を計測し許容する運用(17章)が現実的な選択肢になりうることを示す。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.5.1, [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]]) - **システムコールフックのオーバーヘッドは、計装を置く位置だけでなく、追加経路が引き起こす処理で決まる**: zpoline はバイナリ書き換えとトランポリンを使うため `getpid` のフックが 41 nsであり、NULL 実行検査なしの 40 nsとの差は 1 nsにとどまる。一方、`ptrace` はトレーサーとのスケジューリング、`int3` と SUD はシグナル処理を含み、それぞれ 31,201 ns、1,342 ns、1,156 nsとなる。DTrace の無効時ゼロ・プローブ効果という設計目標と、zpoline の有効フック経路の実測値は、異なる運用条件でプローブ効果を評価する二つの軸を示す。(Source: [[@2023__USENIX-ATC__zpoline - a system call hook mechanism based on binary rewriting]], [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]]) - **DPDK native tracing は、プローブ効果をイベント単価ではなくバッチ償却で評価する**: DPDK fast-path tracepoint は平均約39 CPU cyclesで、平均 batch size 16・RX/TX 2点の構成では約4.875 cycles/packet、非計装 VPP の約250 cycles/packetに対して約2%と推定される。zpoline の41 nsというシステムコールフック単体の値とは測定単位と頻度が異なるため、低オーバーヘッド性を比較するにはイベント単価、発行頻度、バッチサイズ、ワークロードを同時に記録する必要がある。(Source: [[@2026__ICPE__A Transparent and Efficient Performance Analysis Approach to Enhance DPDK Observability]], [[@2023__USENIX-ATC__zpoline - a system call hook mechanism based on binary rewriting]]) ## 未解決の問い - 17章が示す「ダミープローブによるベースライン測定」という事後的な切り分け技法と、DTraceが設計時点で達成する「zero probe effect」は、どちらがCPSのような厳しい許容範囲を持つ領域でより実用的か。計装方式(動的パッチ)自体をCPS向けに設計し直すことで、事後的な切り分けを不要にできるか。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.5.1) - [[eBPF]] の verifier が関数呼び出し・ループ展開を制限することで実質的に「安全性保証」を与えるが、DTrace の DIF(前向き分岐のみ)と形式的に同等かどうか比較した研究はあるか。 - 「本番で常時有効化できる計装」と「診断時のみ有効化する計装」の運用境界はどこに引かれるべきか。DTrace の投機的トレースは「常時オン + 後決めフィルタ」という第三の軸を提示した。 - zpoline の 41 nsというフックオーバーヘッドが、システムコール頻度・フック関数の処理・キャッシュ状態を含む本番ワークロードでどの程度のプローブ効果へ増幅されるか。 - DPDK の burst 分布が変化したとき、平均約2%という tracepoint オーバーヘッド推定がどの程度増幅されるか。また、native tracing の条件付き有効化・sampling を fast path へ導入しても診断精度を保てるか。 ## 関連 - ソース: [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 13 Analytical system administration]] / [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] - 概念: [[DTrace]] / [[動的計装]] / [[eBPF]] / [[オブザーバビリティ]] / [[機能安全]] / [[カオスエンジニアリング]] / [[システムコールフック]] / [[バイナリ書き換え]] - エンティティ: [[Bryan Cantrill]] / [[Sun Microsystems]] / [[Mark Burgess]] / [[Nathan Aschbacher]] / [[zpoline]] ## 出典 - [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]](probe effect の定義と zero probe effect の設計原則) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 13 Analytical system administration]] §13.7.1(Principle 67: Uncertainty、測定行為が系を変化させるという一般原理) - Nathan Aschbacher, 「サイバーフィジカルで行こう」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 17章 §17.5-§17.5.1。 - [[@2023__USENIX-ATC__zpoline - a system call hook mechanism based on binary rewriting]](システムコールフックのオーバーヘッドと適用時の性能低下) - [[@2026__ICPE__A Transparent and Efficient Performance Analysis Approach to Enhance DPDK Observability]](DPDK fast-path tracepoint の cycles、バッチ償却、VPP macrobenchmark)