## 定義 分散システムにおける自己強化型の障害パターン。通常は安定して動作するシステムが、何らかのトリガーによって高負荷状態に入り、負荷を軽減するはずの機構(再試行・増設など)が逆に負荷を増大させ、システムが元の安定状態に戻れなくなる状態。[[Nathan Bronson]] ほか（HotOS 2021）が「メタ安定障害」として体系化し、Huang et al.（OSDI 2022）が本番事例を分析した。(Source: [[@2021__HotOS__Metastable Failures in Distributed Systems]], [[@2023__ATC__On-demand Container Loading in AWS Lambda]]) **3 状態モデル**(Source: [[@2021__HotOS__Metastable Failures in Distributed Systems]]): 1. **安定状態(Stable)**: トリガーが発生しても自力回復可能 2. **脆弱状態(Vulnerable)**: 暗黙的しきい値超過後に遷移。健全に見えるが、トリガーでメタ安定状態に陥りうる。多くの本番システムは効率性のために意図的に脆弱状態で運用されている 3. **メタ安定状態(Metastable)**: トリガーを除去してもフィードバックループが持続し、グッドプットが使用不能なほど低下する **メカニズム**: 1. トリガー(キャッシュが空になる、ワークロードが急変するなど) 2. サービス低下(レイテンシ増大など) 3. 自己強化ループ: レイテンシ増 → 同時実行数増(Little の法則) → 資源競合悪化 → さらなるレイテンシ増 4. システムが自力で安定状態に復帰できない **歴史的背景**: Denning (1968) の「ワーキングセットモデル」で記述されたページングシステムのスラッシングは同様の現象。1960 年代からコンピュータシステムで観察されてきた。 ## Lambda キャッシュにおける例 [[@2023__ATC__On-demand Container Loading in AWS Lambda]] では、エンドツーエンドのキャッシュヒット率が 99.8% 超というシステムで、キャッシュが空になった場合の連鎖を分析している。 - ヒット率 99.8% → キャッシュ空になると S3 への負荷が通常の最大 **500 倍** - S3 からの取得レイテンシ増大 → コンテナ起動レイテンシ増大 - Little の法則より: レイテンシ増大 → 同時実行タスク数増加 → 新たな Lambda スロット需要増加 - 新規コンテナ起動がさらにキャッシュミスを生み、S3 負荷がさらに増大 **対策**: 1. **並行処理数制限**: コンテナ起動が遅延して同時タスク数が上限を超えると、新規起動を拒否して飛行中タスクの完了を待つ 2. **空キャッシュからのコールドスタートテスト**: 最大並行数で空キャッシュから起動できることを継続的に確認 3. **定常作業(Constant Work)原則**: 再試行に依存せず、成功時・失敗時で同量の作業を行う設計([[イレイジャーコーディング]]がこれを実現) ## 横断的知見 - **持続効果の発生源は「効率性向上機能」という逆説**: キャッシュ・再試行・フェイルオーバー・リンクアグリゲーションといった信頼性・効率性を高める機能が、メタ安定障害の sustaining effect の温床になる。このパターンは HotOS 2021 の 4 事例すべてで確認される。Constant Work 原則で設計すると再試行起因のループを回避できる。(Source: [[@2021__HotOS__Metastable Failures in Distributed Systems]], [[@2023__ATC__On-demand Container Loading in AWS Lambda]]) - **隠れキャパシティと広告キャパシティの乖離が事故の種**: ルックアサイドキャッシュ事例では広告容量 3,000 QPS・隠れキャパシティ 300 QPS（10:1 の差）。Lambda キャッシュ事例ではヒット率 99.8% が空になると S3 へ 500 倍の負荷倍率。高効率キャッシュほどこの乖離が大きい。(Source: [[@2021__HotOS__Metastable Failures in Distributed Systems]], [[@2023__ATC__On-demand Container Loading in AWS Lambda]]) - **再試行(retry)はメタ安定障害の典型的な原因のひとつ**: Brooker と MacCárthaigh の「定常作業(Constant Work)」原則は再試行に頼らず設計することでこれを回避する。イレイジャーコーディングで余剰リクエストを送り最初に返ってきたものを使う方式は、この原則の実例。(Source: [[@2023__ATC__On-demand Container Loading in AWS Lambda]]) - **マルチレイヤー障害の原因解明困難性**: リンク不均衡事例では、アプリ層は単純なネットワークモデルを想定し、ネットワーク層は単純なアプリモデルを想定していたため、どちら単独では診断できず、2 年以上未解決となった。修正はコネクションプールの MRU ポリシー変更という 1 行だった。(Source: [[@2021__HotOS__Metastable Failures in Distributed Systems]]) - **[[グレイ障害]]との関係**: グレイ障害（Huang+, HotOS 2017）は「Observer が健全と判断するが App が不健全と観測する」非対称観測性の問題。メタ安定障害とは異なる分類だが、どちらも通常の障害検知(fail-stop)では捕捉できない障害パターンという共通点を持つ。脆弱状態や持続効果もオブザーバビリティの非対称性によって見えにくい。(Source: [[@2021__HotOS__Metastable Failures in Distributed Systems]], [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]]) ## 未解決の問い - 並行処理数制限のしきい値をどのように動的に決定するか？固定しきい値では過剰な拒否または不足な拒否が生じ得る。 - キャッシュのプリウォームは空キャッシュからのメタ安定状態を完全に防止できるか、それとも別のリスクを生むか？ - 特性メトリクス(characteristic metric)を未知のメタ安定障害に対して事前に特定する体系的な手法は存在するか？ - 小規模テスト環境でのフィードバックループ強度を本番スケールに外挿する方法はあるか？（本番規模に依存する定数があり、単純な線形スケーリングは成立しない） - 弾力的クラウドインフラによるスケールアウトをメタ安定障害からの回復手段として使えるか？ステートフルシステムでは再構成コストが短期的にキャパシティを下げ、復旧が間に合わない可能性がある。 ## 関連 - [[@2021__HotOS__Metastable Failures in Distributed Systems]] — メタ安定障害の体系化原典（HotOS 2021） - [[@2023__ATC__On-demand Container Loading in AWS Lambda]] — Lambda での具体的なメタ安定障害対策 - [[イレイジャーコーディング]] — 定常作業原則による再試行回避の実装 - [[コンテナ起動高速化]] — メタ安定障害が問題になる文脈 - [[グレイ障害]] — 観測性の非対称性という関連する障害パターン - [[差分可観測性]] — グレイ障害の核心概念。脆弱状態の不可視性と共鳴する ## 出典 - Bronson et al. "Metastable Failures in Distributed Systems." HotOS 2021. - Huang et al. "Metastable Failures in the Wild." OSDI 2022. - Brooker et al. "On-demand Container Loading in AWS Lambda." USENIX ATC 2023. - MacCárthaigh. "Reliability, Constant Work, and a Good Cup of Coffee." AWS Builders' Library, 2020.