> [!abstract] 概要(abstract の日本語訳) > 分散システムにおける障害パターン——メタ安定障害——を記述する。現在、メタ安定障害はブラックスワン的事象として現れる。過去の出来事では起こりうることを示唆するものが何もなく、深刻な影響を及ぼし、後から説明するほうが予測するよりはるかに容易である。メタ安定障害のインスタンスは表面上は異なって見えるが、より深い分析では同じフレームワーク内で理解できることが示される。 > メタ安定障害について考えるためのフレームワークを導入し、大規模分散システムの運用中に観察された例に適用し、既知のメタ安定障害に対してシステムを耐性にするためにアドホックに開発された手法を調査する。未知のメタ安定障害に対して堅牢なシステムを構築するための体系的なアプローチは依然として未解決の問題である。 ## 論文情報 - **タイトル**: Metastable Failures in Distributed Systems - **著者**: [[Nathan Bronson]]（Rockset、旧 Facebook）、[[Abutalib Aghayev]]（[[The Pennsylvania State University]]）、[[Aleksey Charapko]]（[[University of New Hampshire]]）、[[Timothy Zhu]]（[[The Pennsylvania State University]]） - **媒体**: HotOS '21（Workshop on Hot Topics in Operating Systems） - **会場・日程**: 2021 年 5 月 31 日〜6 月 2 日、Ann Arbor、MI、USA - **DOI**: https://doi.org/10.1145/3458336.3465286 - **ページ数**: 7 ページ ## 概要 本論文は、分散システムにおいて大規模障害を引き起こす「[[メタ安定障害]](metastable failure)」という障害パターンを初めて体系化したビジョン論文である。著者たちはハイパースケール分散システムを 10 年以上運用した経験から事例を収集し、表面上は異なる障害が同一のフレームワークで説明できることを示す。またアドホックな対策を整理し、未解決の研究課題を提示する。 ## 問題設定 対象: ハイパースケール分散システムにおいて、ハードウェア障害・設定ミス・ソフトウェアバグとは異なる種類の広域障害が発生する。これらはブラックスワン的事象として現れ、インターネット大手で数分〜数時間に及ぶ広域停止を引き起こしてきた。逆説的なことに、根本原因はしばしば「効率性・信頼性を高めるはずの機能」である。 **定義**: メタ安定障害は、制御されていない負荷源を持つオープンシステムにおいて、トリガーが悪い状態への遷移を引き起こし、トリガーが除去されても悪い状態が持続する場合に発生する。この状態では有効スループット(グッドプット)が使用不能なほど低下し、sustaining effect(持続効果)——しばしばワーク増幅や全体的な効率低下を伴う——がシステムの悪い状態からの脱出を阻む。 物理学のメタ安定性の定義に倣い、この悪い状態を「メタ安定障害状態」と呼ぶ。トリガーを取り除くと解決する障害（DoS 攻撃、limplock、livelock）はメタ安定障害ではない。メタ安定障害状態からの脱出には、再起動や負荷の大幅削減などの強い是正措置が必要である。 ## 提案手法: メタ安定障害の 3 状態フレームワーク **Figure 1: メタ安定障害を経験するシステムの状態と遷移** ![[_attachments/hotos21-s11-bronson/fig01-state-transitions.png]] (Figure 1. Stable→Vulnerable→Metastable の遷移図。Stable と Metastable の間には Recovery 経路があるが、Metastable からの自力回復には強い是正措置が必要。) メタ安定障害のライフサイクルは 3 フェーズで構成される: 1. **安定状態(Stable)**: システムは通常動作。トリガーが発生しても、負荷増幅が収まればシステムは自力で安定状態に戻る 2. **脆弱状態(Vulnerable)**: 暗黙的・不可視のしきい値を超えると遷移する。システムは健全に見えるが、トリガーによってメタ安定状態に陥りうる。脆弱状態への遷移に気づかないため、多くの本番システムは効率性のために意図的に脆弱状態で運用されている 3. **メタ安定状態(Metastable)**: トリガーを除去してもフィードバックループが持続する。グッドプットは使用不能な水準まで低下する。最悪のケースではフィードバックループが伝染し、トリガーにさらされていなかった部分もメタ安定状態に陥る 障害が発生すると当初はトリガーが責められるが、真の根本原因は sustaining effect(持続効果)にある。 ## 事例研究 著者たちはハイパースケール分散システムの運用から 4 つの代表的事例を示す。いずれも retrospect では説明が容易だが、事前予測は困難だった。 ### 2.1 リクエスト再試行(Request Retries) 最も一般的な持続効果のメカニズム。ウェブアプリケーション(280 QPS)が 10 秒間のネットワーク停止から復旧すると、停止中に蓄積された再試行リクエストが DB を過負荷にする。レイテンシが上昇する限り、クライアントは再試行により 560 QPS を送り続け(元の 2 倍)、DB は回復できない。 **Figure 2: 安定・脆弱・メタ安定状態でのウェブアプリケーションのグッドプット** ![[_attachments/hotos21-s11-bronson/fig02-goodput-vs-load.png]] (Figure 2. 負荷(QPS)に対するグッドプット(QPS)の曲線。安定状態では 150 QPS まで線形、脆弱状態では 150〜300 QPS の範囲、メタ安定状態ではグッドプットがほぼゼロに落ちる。) - 安定状態と脆弱状態の境界: 150 QPS(DB 最大容量の半分) - 脆弱状態は月・年単位で継続しうるが、ある日突然メタ安定状態に遷移する ### 2.2 ルックアサイドキャッシュ(Look-aside Cache) 90% ヒット率のキャッシュ(memcached)を使うシステムでは、3,000 QPS まで処理可能(300 QPS 超が脆弱状態)。キャッシュが消失すると DB は 10 倍のクエリを受けてレイテンシ増大 → タイムアウト → キャッシュへの書き戻し失敗 → キャッシュが空のまま → DB の高負荷が継続するループに陥る。 キャッシュ消失により有効 QPS が 3,000 から 300 に下落する(10 倍のクエリ増幅)。復旧するには DB が単独で処理できる 300 QPS 以下まで負荷を落とすか再試行を制限する必要がある。 ### 2.3 遅いエラー処理(Slow Error Handling) 本番システムの成功パスは高度に最適化されているが、エラーパスはデバッグのためにスタックトレース取得(CPU 大量消費)・DNS ルックアップ(スレッドブロック)・ディスクへのログ記録(バッファ付き I/O でも断続的にブロック)・集中ログサービスへの送信(帯域消費)などを行う。 トリガーがエラー処理コードの使用リソースを枯渇させると、エラー処理がさらにリソース不足を悪化させる自己持続的なエラー状態が発生する。唯一の即時解決策は負荷削減。 ### 2.4 リンク不均衡(Link Imbalance) ルックスルーキャッシュとデータベース間の集約リンク(LAG: アグリゲートリンク)で全トラフィックが 1 本のケーブルに集中するメタ安定障害。決定論的ハッシュ関数による負荷分散が想定される設計だが、MRU(最近最多使用)ポリシーによるコネクションプールの特性が sustaining effect を形成する。 **メカニズム**: キャッシュミスの急増 → 単一 DB サーバへの並行クエリ → 輻輳したリンクのクエリが最後に完了 → MRU ポリシーで輻輳リンク上のコネクションがプールのトップに残る → 次の定常状態クエリが輻輳リンクに集中 → リンクの過負荷が継続。 この障害は 2 年以上にわたって原因不明のまま複数回の障害を引き起こした。複数レイヤーのエンジニアが実装詳細を共有し合って初めて解明され、修正は「コネクションプールのポリシー変更」という 1 行だった。 ## 既知メタ安定障害への対処手法 ### 負荷過剰時のポリシー変更(Change of Policy during Overload) フェイルオーバーや再試行の無効化・再試行バジェット設定・LIFO スケジューリング・内部キューサイズ削減・優先度制御・負荷遮断(Circuit Breaker)パターン。適応ポリシーの課題は、再試行・フェイルオーバー判断が各クライアント分散で行われるため協調が困難な点。 持続的過負荷とスパイクを区別する手法として、内部作業キューの最小キューイングレイテンシをスライディングウィンドウで計測する(CoDel に類似)。ウィンドウ内の最小値が小さければスパイク → 通常ポリシー継続。大きければ持続的過負荷 → グッドプット最大化ポリシーに切り替え。 ### 優先度制御(Prioritization) 再試行に低優先度を付与することでフィードバックループを断ち切る。ただし全リソースをカバーするわけではなく、ワーク増幅が大きい設計では最悪 100 倍以上の増幅を招くことがある。ソフトウェア構造自体が暗黙の優先度を符号化している(例: リクエストを可能な限りデシリアライズしてから処理するステージドアーキテクチャは「デシリアライズ > 処理」の優先度を表す)。 **ルックスルーキャッシュの優位性**: ルックサイドキャッシュはメタ安定状態でのキャッシュ充填に高優先度を付けることが構造的に不可能だが、ルックスルーキャッシュは DB クエリにルーズなタイムアウトを設定してウェブアプリ側のリクエストよりキャッシュ充填を優先できる。 ### ストレステスト・組織的インセンティブ・高速エラーパス・外れ値管理・オートスケール - **ストレステスト**: 小規模では本番のフィードバックループ強度を再現できない。Kraken のように本番トラフィックを安全に移動させる方法が有効 - **組織的インセンティブ**: キャッシュ立退きアルゴリズム改善 → DB リソース削減 → 見かけの容量向上だが、冷キャッシュからの回復力を失う「偽の経済」になりうる - **高速エラーパス**: 成功パスと同様にエラーパスも最適化する。有界サイズのロックフリーキューでエラーを専用スレッドに送るパターン - **外れ値管理(Outlier Hygiene)**: メタ安定障害は本番で事前にレイテンシ外れ値やエラークラスタとして現れることが多い - **オートスケール**: キャパシティバッファを維持してほとんどのトリガーへの脆弱性を下げるが、メタ安定障害耐性の保証にはならない(§4) ## 研究課題と新しい概念 本論文はビジョン論文として、以下の研究方向を提示する。 **ワーク増幅(Work Amplification)**: 持続効果の共通テーマ。システム設計時にワーク増幅の上限を定め、システマチックに管理する必要がある。 **フィードバックループ(Feedback Loops)**: 複雑なシステムには多くの潜在的フィードバックループが存在するが、問題になるのは少数。ループの強度はキャッシュヒット率など環境の定数に依存。すべてを排除する必要はなく、最も強いループを弱めることが目標。 **特性メトリクス(Characteristic Metric)**: 本番で観察された特性メトリクスの例: キューイング遅延、リクエストレイテンシ、負荷水準、ワーキングセットサイズ、キャッシュヒット率、ページフォルト、スワップ、タイムアウト率、スレッド数、ロック競合、コネクション数、操作ミックス。 **警告サイン(Warning Signs)**: 特性メトリクスの安全値範囲を定め、逸脱時にアラームを発する。メタ安定フレームワークで「正しいメトリクスとしきい値」を学習できる可能性。 **隠れキャパシティ(Hidden Capacity)**: 安定状態と脆弱状態の境界。広告キャパシティ(advertised capacity)= 脆弱状態に入るしきい値。隠れキャパシティ = システムが自己回復できる上限。ルックアサイドキャッシュ例では広告容量 3,000 QPS に対して隠れキャパシティは 300 QPS。 **トリガー強度(Trigger Intensity)**: 脆弱状態での運用負荷が広告容量に近いほど、弱いトリガーでもメタ安定状態に遷移する。 **再構成コスト(Reconfiguration Cost)**: 弾力的クラウドインフラによるスケールアウトは理論上は解決策になりうるが、ステートフルシステムでは状態転送・メタデータ更新のオーバーヘッドが短期的にキャパシティを減少させ、復旧策として間に合わない場合がある。 ## 強み / 弱点・課題 **強み**: - 現象の体系化: 多様に見える本番障害を 3 状態フレームワーク + sustaining effect という統一的枠組みで説明する - 実践的事例: 実際の本番障害(特に Link Imbalance はマルチレイヤー原因で 2 年以上未解決)を具体的に提示 - 研究課題の特定: ワーク増幅・特性メトリクス・隠れキャパシティなど操作可能な概念を提示 **弱点・課題**: - ビジョン論文のため定量的評価なし - 未知のメタ安定障害を事前予測する手法は未解決のまま提示される - スケール依存性: 小規模テストでは本番のフィードバックループ強度を再現できないため、テストによる保証が困難 ## 出典 - Bronson et al. "Metastable Failures in Distributed Systems." HotOS '21, May 31-June 2, 2021, Ann Arbor, MI, USA. ACM. - DOI: https://doi.org/10.1145/3458336.3465286