## Memo
## Memo with LLM
### 論文情報
**論文のタイトル**: Metastable Failures in the Wild
**著者と所属**:
- Lexiang Huang (The Pennsylvania State University, Twitter)
- Matthew Magnusson (University of New Hampshire)
- Abishek Bangalore Muralikrishna (University of New Hampshire)
- Salman Estyak (The Pennsylvania State University)
- Rebecca Isaacs (Twitter)
- Abutalib Aghayev (The Pennsylvania State University)
- Timothy Zhu (The Pennsylvania State University)
- Aleksey Charapko (University of New Hampshire)
**カンファレンス/ジャーナル名**: 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 2022)
**発表年**: 2022年7月 (Carlsbad, CA, USA)
### 論文概要
メタスタブル障害（Metastable Failures）は、分散システムの一種の障害パターンであり、初期トリガーが除去された後もシステムが永続的な過負荷状態に留まる特性を持つ。本論文では、AWS、Azure、GCPなどの大規模クラウドプロバイダーから11の異なる組織にわたる22のメタスタブル障害を分析し、これらが実環境で広く観察される障害パターンであることを実証している。さらに、Bronson et al.の既存モデルを拡張して、障害の引き金（トリガー）と増幅メカニズムを分類し、制御環境で複数のアプリケーションを用いてそれらの検証を行っている。
### 詳細解説
#### 問題設定
分散システムにおける障害は、単純なハードウェア故障やソフトウェアバグだけでは説明できない現象が存在する。[[2021__HotOS__Metastable Failures in Distributed Systems|Bronson et al. (HotOS 2021)]]は「メタスタブル障害」という新しい障害クラスを提唱したが、それらの例は簡略化されたシナリオに限定されていた。本論文の主な問題設定は以下の通りである：
1. **メタスタブル障害の普遍性の検証**: 実際の運用環境で、メタスタブル障害がどの程度の頻度で発生しているのかを定量的に理解すること
2. **障害メカニズムの分類と抽象化**: 様々な組織の公開インシデント報告から、メタスタブル障害に共通するパターンを抽出し、より正確なモデルを構築すること
3. **障害の再現と検証**: 制御環境で異なるタイプのメタスタブル障害を実験的に再現し、提案モデルの妥当性を確認すること
入力データとしては、AWS、Azure、GCP、IBM、Spotify、Elasticsearch、Apache Cassandraなどから公開されている数百のインシデント報告書を利用している。
#### 提案手法
**1. メタスタブル障害の定義と状態遷移モデル**
論文では、分散システムの状態を3つに分類する：
- **安定状態（Stable State）**: システムが提供負荷を処理でき、一時的な過負荷から自動回復可能
- **脆弱状態（Vulnerable State）**: システムが高い負荷を処理可能だが、余裕容量が限定されており、一時的な過負荷で失敗する可能性がある
- **メタスタブル障害状態**: 初期トリガーが除去されても、sustaining effectにより永続的に過負荷状態が継続
数学的には、容量(Capacity)と負荷(Load)の関係で表現される：
- 容量 C と負荷 L に対して、L > C となる過負荷状態がある
- メタスタブル状態では、トリガーが除去されても L > C が続く
**2. トリガーの分類**
障害を引き起こす要因として、2つのタイプのトリガーを特定：
- **負荷増加型トリガー（Load-Spike Triggers）**: 突発的な負荷増加。例：予期しないトラフィック急増、クライアントの再試行（retry）
- **容量低下型トリガー（Capacity-Decreasing Triggers）**: システムの処理能力を低下させる要因。例：キャッシュのヒット率低下、データベース接続数の制限、リーダー選出による一時的な性能低下
**3. 増幅メカニズムの分類**
sustaining effectを実現する2種類の増幅メカニズム：
- **負荷増幅（Workload Amplification）**: フィードバックループにより負荷が自己増殖。例：
- 再試行による負荷増幅：クライアントタイムアウト → リトライ → さらに高い負荷 → より多くのタイムアウト
- エラーパスの高コスト処理：エラーハンドリング時の過度なロギング
- **容量低下増幅（Capacity Degradation Amplification）**: 過負荷状態がシステム自体の容量を低下させるフィードバック。例：
- ガベージコレクション（GC）の頻繁化
- ロック競合の増加
- メモリ不足によるスワップ増加
**4. 実証的データセットの構築と分析**
22のメタスタブル障害事例を収集。表1では以下が示される：
- AWS：4件（キャッシュ障害、ELB設定変更による瞬時的障害など）
- Google Cloud：4件
- Microsoft Azure：4件
- その他の組織：10件（IBM、Spotify、Elasticsearch、Cassandraなど）
各インシデントの特性：
- 継続時間：1.5～73.53時間（中央値：4～10時間）
- 45%が複数のトリガーを含む
- 35%がトラフィック急増に関連
- 45%がバグのあるコード展開やコンフィグレーション変更に関連
#### 新規性
本論文の新規性は以下の点にある：
1. **第一次的な実証研究**: Bronson et al.が理論的フレームワークを提唱したのに対し、本論文は実環境で22件の事例を系統的に収集し、メタスタブル障害の普遍性を初めて実証した
2. **フレームワークの拡張と精密化**: 既存の4象限モデルをさらに精密化し、トリガーと増幅メカニズムの詳細な分類を提供
3. **複合障害の考慮**: 実環境では複数のトリガーと増幅メカニズムが組み合わさることを初めて大規模に報告
4. **業界観点の追加**: Twitterでの実経験に基づく垂直統合型の障害分析（例：GCによるメタスタブル障害の実例）
5. **実験的検証**: MongoDB、分散キャッシュ、マイクロサービスなど複数のアプリケーションで異なるタイプのメタスタブル障害を再現
#### 実験設定
**1. データセット**
公開インシデント報告書の収集ソース：
- Pinboard（pinboard.in/u:postmortems）
- postmortems.info
- SRE Weekly
- 各組織の公式インシデント報告
候補インシデントから最終的に22件を選定基準：
- 十分な詳細情報がある
- メタスタブル障害の要素（トリガーとsustaining effect）が明確に特定可能
**2. 実験用アプリケーション**
メタスタブル障害の再現環境：
- MongoDB レプリケーション（負荷増幅型）
- 分散キャッシュシステム（容量低下型トリガー）
- マイクロサービスアーキテクチャ
各実験は数VMで実施される小規模環境でも再現可能
**3. 評価指標**
メタスタブル障害の診断と定性的分析：
- トリガーの特定と分類
- Sustaining effectの検出
- 復旧メカニズムの分析
定量的メトリクス（実験）：
- スループット（Goodput）の測定
- レイテンシの時系列追跡
- 容量利用率の観察
#### 実験結果
**1. 公開インシデント分析の結果**
22件のメタスタブル障害の統計：
| 項目 | 結果 |
|------|------|
| 識別されたインシデント | 22件 |
| 参加組織数 | 11 |
| 最大継続時間 | 73.53時間（IBM1事例） |
| 最短継続時間 | 1.5時間 |
| 中央値継続時間 | 4～10時間（35%） |
| 複数トリガー | 45% |
| 負荷増加関連 | 35% |
| 人的要因関連 | 45% |
| 再試行による負荷増幅 | 50%以上 |
**2. トリガーの内訳**
- バグのあるコード展開：25%
- コンフィグレーション変更：20%
| トラフィック急増：35%
- その他のハードウェア・ネットワーク障害：20%
複合トリガーの例：
- GGL2（Google）：ロード急増 + エラーハンドリング
- AWS3：キャッシュ障害 + リトライ急増
**3. Sustaining Effect（増幅メカニズム）の内訳**
- 再試行による負荷増幅：50%以上
- 高コストなエラーパス処理：15%
- ロック競合：10%
- リーダー選出による性能低下：10%
- その他（メモリリーク、GC）：15%
**4. 復旧メカニズム**
すべての復旧事例で以下のいずれかが適用：
- 直接的な負荷削減（Load Shedding）：60%
- スロットリング・リクエスト破棄：20%
- ポリシー変更（タイムアウト調整など）：15%
- システム再起動：5%
復旧時間：
- 自動復旧なし（人的介入必須）：全事例
- 平均復旧時間：8～20時間
**5. 実験による再現と検証**
MongoDB レプリケーション実験：
- ノード障害 + リトライ急増により、ノード復帰後もメタスタブル状態が続くことを確認
- 容量：通常100 req/sec処理可能
- トリガー後：リトライ重複により15 req/secの有効スループットのみに低下
- 継続時間：トリガー除去後も4～6時間メタスタブル状態継続
分散キャッシュ実験：
- キャッシュヒット率低下（80-90% → 0%）がトリガー
- データベースへのクエリ急増がsustaining effect
- 自動スケールも追いつかず、2時間以上のメタスタブル状態が発生
**6. 重要な知見**
- Amazon Web Services（AWS）においては、過去10年で報告された15件の大規模障害のうち、少なくとも4件がメタスタブル障害が原因
- メタスタブル障害は比較的低頻度だが、発生時の影響は極めて大きい（平均4～10時間の継続）
- 自動復旧メカニズムは機能せず、人的介入による負荷削減が必須
### 結論
本論文により以下が明らかになった：
1. **普遍性の実証**: メタスタブル障害は理論的興味の対象ではなく、実環境で広く観察される実際的な問題
2. **高い影響度**: 発生頻度は低いが、一度発生すると数時間～数日の大規模障害に発展
3. **設計への示唆**:
- 再試行の無分別な使用を避ける
- システムの過度な最適化を避ける（パフォーマンスの勾配を維持する）
- 早期段階での積極的な負荷削減が効果的
4. **今後の課題**:
- メタスタブル障害の自動検出
- 予防的なシステム設計
- 自動復旧メカニズムの開発
## Abstract
最近、Bronson et al.は分散システムにおけるメタスタブル障害という一種の障害パターンを理解するためのフレームワークを提唱した。その論文における例は、Facebookで観察された障害の簡略化されたバージョンであった。本研究では、多くの組織（大規模クラウドプロバイダーから小規模企業まで）の公開インシデント報告書を調査することにより、実環境でのメタスタブル障害の普遍性を研究している。主な知見は3つある。第1に、メタスタブル障害は普遍的に観察されており、11の異なる組織からの22のメタスタブル障害の詳細な研究を提示する。第2に、メタスタブル障害は多くの重大な停止のパターンであり、例えば過去10年間にAmazon Web Servicesで報告された15件の主要な停止のうち、少なくとも4件はメタスタブル障害が原因であった。第3に、Bronson et al.のモデルを拡張して、実環境で観察されるメタスタブル障害をより良く反映するために、2種類のトリガーと2種類の増幅メカニズムを分類し、これを確認するために、制御環境で異なる種類のメタスタブル障害を再現する複数のアプリケーション例を開発した。我々は、この研究がメタスタブル障害の深い理解と解決策の構築に役立つと信じている。