# 障害耐性劣化変更検知 ## 定義 障害耐性劣化変更検知(Erroneous Software Changes that Reduce fault Resilience detection, ESCR 検知)とは、マイクロサービスシステムの**障害耐性(fault resilience)**を低下させる誤りソフトウェア変更(ESCR)を、本番展開前に検知することを指す。 **ESCR** は「デプロイ直後には正常動作しているが、ネットワーク変動・CPU 使用率高騰などの障害が発生したとき初めてサービス障害が顕在化する」変更である。即時障害を引き起こす ESCF(Erroneous Software Changes that cause immediate Failures)とは区別される。 He et al., ISSRE 2024([[@2024__ISSRE__Guardian of the Resiliency - Detecting Erroneous Software Changes Before They Make Your Microservice System Less Fault-Resilient]])は 256 件の実世界インシデント分析から、誤りソフトウェア変更の **37.87%** が ESCR であると定量化した初の研究である。 --- ## ESCR の 4 カテゴリ(実証研究より) | カテゴリ | 説明 | 割合 | |---|---|---| | I - 冗長性不足 | 障害時に必要な冗長リソースの不適切な削減 | 29.69% | | II - バックアップノード誤構成 | 障害時に無効なバックアップノードを設定 | 23.44% | | III - 問題リクエスト設定 | 無効 DB アクセスや無限ループを起動するリクエストを許可 | 32.81% | | IV - 誤った転送戦略 | 障害時のリクエスト転送ミス設定 | 14.06% | --- ## ESCR 検知の核心的課題 従来の変更後モニタリング(ECD)が ESCR を見逃す理由は 3 つ: 1. **監視窓の問題**: 障害発生タイミングが予測不能で、通常の監視窓内に偶発的障害が入るとは限らない 2. **大量の KPI**: 実世界マイクロサービスでは 1 変更あたり数百万の KPI を要チェック 3. **ラベルデータ不足**: ESCR は顕在化が遅れるため、障害時の KPI パターンを事前に収集するのが困難 --- ## 主要アプローチ: ResilienceGuardian [[ResilienceGuardian]](He+ ISSRE 2024)はステージング環境への**計画的障害注入**によって上記課題を回避する: 1. **ステージング環境での障害注入**(ChaosBlade): 典型障害 8 種を注入し、障害前後の KPI を収集 2. **データ拡張**: ノイズ注入とノイズ強度スケーリングで擬似ラベル付き KPI セグメントペアを生成 3. **障害特化 LSTM 分類器群**: 各障害に個別の軽量分類器を訓練し、転移学習で訓練コストを約 8.73 倍削減 4. **並列化戦略**: KPI ペアと分類器の二次元並列化で百万規模 KPI を分単位で処理 性能: F1 = 0.90(HipsterShop)・0.89(Train-Ticket)、訓練時間 8.32 分(Kontrast の 290.74 分から 97% 削減) --- ## 横断的知見 - **ESCR は変更起因インシデントの中で「遅延顕在化型」として独立した問題クラスを形成する**: He+ ISSRE 2024 は 256 件の実障害分析から ESCR が誤り変更の 37.87% を占めることを定量化した。[[変更起因インシデント]]([[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]: デプロイ直後 45.9%・しばらく経過後 16.9%)と組み合わせると、「しばらく経過後に障害が起きたとき初めて顕在化する」という ESCR の特性は、変更後監視窓を長くする以外の手段として「障害注入でプロアクティブに耐性評価する」アプローチが有効な理由を説明する。ESCR という問題設定自体が、既存の変更管理研究(ECD・SCWarn・Gandalf 等)が見落としてきた死角を明示化した。(Source: [[@2024__ISSRE__Guardian of the Resiliency - Detecting Erroneous Software Changes Before They Make Your Microservice System Less Fault-Resilient]], [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]) - **ステージング環境での障害注入による耐性評価は「事後モニタリング」から「事前プローブ」への発想転換である**: 従来の ECD(SCWarn・Kontrast 等)が「デプロイ後の KPI 変動を監視して異常検知する」のに対し、ResilienceGuardian は「デプロイ前に意図的に障害を与えて応答を観測する」。この事前プローブ型アプローチは、[[障害注入]]の「テスト目的」使用(SRE Book Chapter 17)の変更管理への応用と見ることができる。Chaos Engineering が本番環境の耐性を確認する目的に対し、ResilienceGuardian はステージング環境で変更の影響を検査する点が異なる。(Source: [[@2024__ISSRE__Guardian of the Resiliency - Detecting Erroneous Software Changes Before They Make Your Microservice System Less Fault-Resilient]], [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]]) --- ## 未解決の問い - ESCR はネットワーク変動・CPU 高騰などの**外部障害**との組み合わせで初めて顕在化するが、「どの障害種別と組み合わさったとき最も危険な ESCR か」を事前予測できるか。障害注入の網羅性は有限であり、想定外の障害パターンへの ESCR の汎化能力は未知。 - ステージング環境と本番環境のギャップ(データ量・障害強度・ワークロードパターンの差異)が ESCR 検知の偽陰性(本番では顕在化するがステージングでは見えない)をどの程度生むか。本番環境での障害注入と組み合わせるリスク制御の設計はどうあるべきか。 - ESCR の 4 カテゴリ(冗長性不足・バックアップ誤構成・問題リクエスト・誤転送)は 256 件から帰納したものだが、より大規模・多様なシステムでも同じカテゴリ分布が成立するか。Kubernetes 環境特有の ESCR カテゴリ(HPA/VPA 誤設定、サービスメッシュの障害時ルーティング誤設定等)は既存分類に収まるか。 - ResilienceGuardian は KPI のみを利用するが、トレースやログを追加したマルチモーダル ESCR 検知は精度をどれだけ向上させるか。特にバックアップノードの誤構成(カテゴリ II)はログで早期発見できる可能性があるが、KPI だけでは観測が難しい。 - ソフトウェア変更管理の 5 段階(展開・検知・トリアージ・診断・再展開)の中で、ResilienceGuardian は「展開前検知」に特化する。ESCR を検知した後の「ESCR の原因箇所(コード/構成)の特定」= RCCA は未解決——検知した変更のどのパラメータが耐性を低下させたかを自動説明する機能の設計は今後の課題。 --- ## 関連 - **ソース**: [[@2024__ISSRE__Guardian of the Resiliency - Detecting Erroneous Software Changes Before They Make Your Microservice System Less Fault-Resilient]] - **概念**: [[ソフトウェア変更管理]] / [[変更起因インシデント]] / [[障害注入]] / [[AIOps]] / [[根本原因分析]] - **エンティティ**: [[ResilienceGuardian]] / [[Guanglei He]] / [[Xiaohui Nie]] / [[Dan Pei]] / [[BizSeer]] / [[Tsinghua University]] - **関連 MOC**: 関連する既存 MOC は未確認。[[AIOps - Fault Localization - MOC]] や [[SRE - MOC]] が最も近い可能性がある ## 出典 - [[@2024__ISSRE__Guardian of the Resiliency - Detecting Erroneous Software Changes Before They Make Your Microservice System Less Fault-Resilient]](§II 実証研究・4 カテゴリ, §III フレームワーク設計, §IV 評価結果, §V 制約と今後の方向)