# 遅延注入 ## 定義 遅延注入(Delay Injection)とは、ネットワークサービスに対するリクエストのタイミングを制御的に操作し、その操作パターンが他のサービスに伝播するかを統計的に検定することで、サービス間の依存性を能動的に発見する手法である。Zand ら INFOCOM 2014([[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]])が提案したシステム Rippler が代表実装。トラフィックウォーターマーキングとも呼ばれ、「リクエスト到達タイミングにパターンを刻み、そのパターンの伝播を観測する」という原理に基づく。 具体的な手順: 観測期間を等幅の時間窓に分割し、奇数窓で対象サービス S1 へのリクエストを td 秒遅延させ、偶数窓では遅延させない。S1 → S2 の依存関係が存在する場合、S2 へのリクエスト到達数が奇数窓(アイドル窓)と偶数窓(ビジー窓)で異なる分布に従う。この差を 3 種の統計的検定(独立 t 検定・対応 t 検定・ウィルコクソン符号順位検定)で検出する。 ## 横断的知見 - **同じ「遅延注入」という操作が、依存性発見と障害検知という別々の目的に使われている**: Rippler は依存性を発見するために遅延を刻んでその伝播を統計的に検定するのに対し、Sieve([[フェイルスローハードウェア]] 障害の検知)は既知の依存構造(同期ブロック・タイムアウトスコープ)を静的解析で先に特定し、そこへ遅延を入れてバグを露出させる。前者は遅延を**観測の道具**として、後者は**破壊の道具**として使う。両者は「遅延がシステムを伝播する経路」という同じ性質に依拠しており、Rippler が発見する依存グラフは Sieve が注入すべき点の候補集合になりうる。(Source: [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]], [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) - **遅延の長さは「大きいほど強い」ではなく、目的に応じて設計すべきパラメータである**: Rippler は td 秒の遅延がレイテンシ敏感なサービスを壊さない範囲であることを制約とする。Sieve は逆に、同期 I/O には既定 5 分(無期限ブロッキングを確実に起こす)、タイムアウト保護 I/O にはタイムアウト値の 2/3(タイムアウト機構を起動しつつタイムアウトタスクとハンドラの順序を入れ替える)と使い分ける。さらに FATE・Legolas の一律 1 分遅延では ZK-4836 のクライアント作成要求がタイムアウトしてしまい、バグが**発現しなくなる**——長すぎる遅延が検知力を下げる実例である。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §4.4・§6.2.2, [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]]) - **遅延注入は能動的アプローチだが追加トラフィックを生成しない**: Rippler は既存リクエストのタイミングを操作するだけで、新たなプローブパケットを生成しない。ADD のような「負荷注入(load injection)」とは異なり、ネットワーク帯域への追加負荷がない。これは受動的手法(追加トラフィックなし)と能動的手法(高精度)の利点を組み合わせる設計選択である。(Source: [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]]) - **遅延注入はアプリケーション非依存だが「センサ配置の柔軟性」に依存する**: トラフィックウォーターマーキングはサービスの内部実装・プロトコルに依存しないが、デレイヤーを対象サービスとクライアントの間に配置できる物理/論理的な位置が必要。X-Trace・ADD もセンサ配置問題を解決しているが、それらはアプリケーション改変が必要。遅延注入はアプリケーション非依存性とセンサ配置問題の両立を初めて達成した手法である。(Source: [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]]) - **「相関は因果でない」問題への構造的な解」として遅延注入は機能する**: 受動的手法の根本的限界は相関(2 サービスが同時に使われる)と因果(一方が他方を必要とする)の混同である。遅延注入では「S1 への遅延が S2 へ伝播するか」を直接テストするため、共通の第三要因や偶然の相関を除外できる。これは手法の本質的な優越性の根拠である。(Source: [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]]) ## 未解決の問い - 100〜500ms の遅延注入がレイテンシ敏感なサービス(音声通話・リアルタイム取引等)に与える影響はどう定量化・制御するか。どこまで遅延を小さくすればほとんどのサービスに安全か。 - クラウドネイティブ・マイクロサービス環境(Kubernetes、サービスメッシュ)では sidecar プロキシを介した遅延注入が可能か。Envoy フィルタ経由で Rippler の設計を再現できるか。 - 遅延注入は「遅延を保存する依存性タイプ」のみ検出可能。バックアップ・ロードバランシング依存性(一方が遅延しても他方が肩代わりする)への対処策はあるか。 - 本手法では対象サービスを事前に定義する必要がある。動的に変化するマイクロサービス環境でサービスカタログを自動的に維持するとどう統合できるか。 - 複数の Rippler インスタンスを同時実行した場合、別の注入実験のリップルが干渉して偽陽性を生む可能性はあるか。分散環境での並列実行の安全性は。 - Rippler は 10 分以上(ネットワーク負荷によっては 4 ヶ月)の長期観測を要する。依存性発見の緊急性が高いシナリオ(インシデント対応中のリアルタイム依存マップ更新)にどう対応するか。 - Rippler が発見するサービス依存グラフを、Sieve のような細粒度遅延注入の**候補障害点の絞り込み**に使えるか。静的解析(コード側)と能動的な依存性発見(実行時トラフィック側)は、注入対象の特定において補完的に働くか、それとも別々の粒度を扱っていて統合できないか。([[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) - 遅延長を固定値でなく、対象 I/O のタイムアウト値やレイテンシ分布から動的に決める設計は、Rippler 型(依存性発見)と Sieve 型(バグ検知)の両方で有効か。Sieve が ZK-4817 の検出に「同一点へ異なる遅延長で 2 回」を要したことは、単一の既定値では足りない場面があることを示す。([[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) ## 関連 - [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]] — 本概念の唯一現時点の一次ソース - [[Ali Zand]] / [[Giovanni Vigna]] / [[Christopher Kruegel]] / [[Richard Kemmerer]] — 提案者 - [[UC Santa Barbara]] — 研究機関 - [[ネットワーク依存性発見]] — 上位概念(本手法が解く問題ドメイン) - [[障害注入]] — 兄弟概念(遅延注入は障害注入の特殊形だが追加トラフィック不要の点で異なる) - [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] / [[Sieve]] / [[フェイルスローハードウェア]] — 遅延注入をバグ検知に用いる系統 - [[サービストポロジ]] / [[ネットワーク依存性発見]] — 現代版の発展形 ## 出典 - Zand, Ali, Giovanni Vigna, Richard Kemmerer, Christopher Kruegel. "Rippler: Delay Injection for Service Dependency Detection." *IEEE INFOCOM 2014*, pp. 2157–2165. - Gen Dong, Yu Hua, Yongle Zhang, Zhangyu Chen, Menglei Chen. "Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems." *ACM Transactions on Computer Systems*, 2026. DOI: 10.1145/3838187.