グレースフルデグレーデーション

# グレースフルデグレーデーション ## 定義グレースフルデグレーデーション（graceful degradation）とは、システムの一部が障害を起こした際に、完全にサービスを停止するのではなく、限定的な形で機能を継続する設計原則である。「障害を防ぐ」という目標に並立する「よりよく失敗する（fail better）」という哲学として位置づけられる。データ完全性を部分可視性より優先する設計は通常運用では適切だが、大規模な部分障害（例: ノードの 50〜60% が停止）において、残存するリソースがあるにもかかわらずサービスが 100% 停止しているように見える「スクエアウェーブ障害パターン」を生む。グレースフルデグレーデーションはこのパターンを避け、完全なデータセットが揃わないときも不完全な結果を提供し続けることを目指す。(Source: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]]) ## 対比：フェイルファスト vs. グレースフルデグレーデーション - **フェイルファスト**（[[ソフトウェア耐障害性]]、Jim Gray 1985）: エラーを早期に検知して処理を停止し、不正確な状態の伝播を防ぐ。単一コンポーネント・単一ノード文脈での障害隔離に有効。 - **グレースフルデグレーデーション**: 分散システムの**部分障害**文脈で、フェイルファストによる完全停止の代わりに、限定的な正確性を受け入れてでも継続運用を選ぶ。ユーザー向けの「ゼロか百か」を避ける。二者は対立ではなく**スコープが異なる**。コンポーネント内ではフェイルファストを維持しつつ、システム全体ではグレースフルデグレーデーションを実現するという組み合わせが一般的。 ## 設計パターン（Datadog の実践から） Datadog が 2023 年の大規模障害後に導入した 8 原則： 1. **エンドユーザーニーズの最優先** — 内部の完全性よりも顧客への価値提供を最上位に置く 2. **早期永続化** — パイプライン入口でのディスクベース永続化で、障害中のデータ損失を防ぐ 3. **グローバル制御システムの回避** — 単一障害点となるグローバルな制御機構を避ける 4. **シンプルなデータ優先順位付け** — 複雑なインフラなしにライブデータを優先配信する 5. **リトライ・キャッシュの注意深い設計** — 指数バックオフとデッドレターキューでカスケード障害を防ぐ 6. **技術的負債の削減** — ボトルネック依存（共有 Cassandra キャッシュ等）を除去する 7. **リカバリツールへの投資** — Kubernetes PriorityClass や高速オートスケーリングで復旧を加速する 8. **ブレークグラスによるオペレータ制御** — 循環依存など通常手順では解決できない状況のための手動オーバーライドを用意する ## 横断的知見 - **「全か無か」の二値的な停止を避けるべきだという主張は、データ完全性の文脈(Datadog)とサーバの受付制御の文脈(SRE Book ch.21)の双方で独立に現れる**: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]] は「50〜60% のリソースを失っても 100% 停止に見える」スクエアウェーブ障害パターンをデータ完全性の設計判断の問題として論じるのに対し、[[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]] は「過負荷になったバックエンドは全トラフィックを止めるべきだ、という発想はよくある誤りである」と述べ、処理できる分だけを受理し続け残りを行儀よく棄却することを主張する。両者はドメイン(データ完全性 vs. 受付制御)が異なるにもかかわらず、部分的な機能提供が完全停止より望ましいという同じ設計原則に到達している。(Source: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]], [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]]) - **優先順位に基づく選択的な機能低下を実現する具体的な機構として、SRE Book ch.21 の criticality(重要度)ベースの選択的棄却は、Google の Mayan Apocalypse 事例(ch.6)が示す優先順位づけの副作用に対する備えを明示的には論じていない**: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]] は criticality(CRITICAL_PLUS/CRITICAL/SHEDDABLE_PLUS/SHEDDABLE)に基づき重要度の低いリクエストから機械的に棄却する仕組みを、グレースフルデグレーデーションを実現する一般的な機構として説明するが、[[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] が報告するような「ある優先順位づけが、別の優先順位づけ機構(インシデント対応者自身の可用性)を犠牲にしうる」という相互作用への言及はない。criticality という一般的な選択的棄却の設計を提示するソースと、その設計が実運用で見せた副作用を記録するソースが噛み合っていない点は、両ソースを揃えて初めて見える欠落である。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]]) - **スクエアウェーブ障害パターン**: 50〜60% のリソースが失われてもシステムが 100% 停止に見える現象は、「データ完全性か否か」という二値的な設計判断が生む。部分結果を受け入れる設計判断が、部分障害時の可用性を不連続ではなく連続的にする。(Source: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]]) - **同一書籍内で、教科書的な一般原則(ch.4)と、その原則が現実に破綻しかけた具体的な事例(ch.6)が対をなす**: [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]] はグレースフルデグレーデーションを「全ユーザーに全機能を提供できないなら、全ユーザーに最小限の機能を提供できないか」を問うスロットリング・負荷遮断の戦略として一般論で紹介し、「劣化したサービスはサービスなしより良い」という経験則を示すにとどまる。同じ書籍の第6章("Mayan Apocalypse")は、この一般原則を Google が実際に輻輳時のトラフィック優先順位づけとして実装した結果、優先度の低いトラフィックに割り当てられた側(社内ツール・アラート配信)の対応能力そのものが損なわれるという副作用に直面したことを記録する。第4章の抽象的な推奨(「劣化させてでも継続せよ」)だけを読むと見えない失敗モードを、第6章の一次記録が具体的に補う——同一書籍内の章であっても、原則の提示と原則適用の限界の記録は独立した知見として扱う価値がある。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]], [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]]) - **優先順位づけによるグレースフルデグレーデーションは、優先度の低い側に割り当てられた当事者自身の対応能力を損ないうる**: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] が報告する Google の "Mayan Apocalypse"(2019-06-02)では、輻輳発生時にシステムが「レイテンシに寛容な大口トラフィックを自動ドレインし、レイテンシに敏感な小口トラフィックを維持する」というトリアージ(ある種のグレースフルデグレーデーション)を正しく実行した。しかし同じ障害では、外部ユーザートラフィックを社内トラフィックより優先するという別の優先順位づけ方針が、カスケード障害時に社内ツール自体を巻き添えにしてアラート配信を阻害し、対応そのものを遅らせる副作用を生んだ。Datadog の事例が「データ完全性 vs 部分可視性」という単一システム内のトレードオフを扱うのに対し、Google の事例は**複数の優先順位づけ機構が併存するとき、ある機構(トラフィック種別ごとの優先度)が別の機構(インシデント対応者自身の可用性)を犠牲にしうる**という、単一ソースでは見えない相互作用を示す。Google はこの副作用に対し、インシデント対応と識別されたアクションが通常の優先順位づけを一時的に覆せる専用のアクセス機構で対処した。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]], [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]]) - **「使われないコードパスは(しばしば)動かないコードパス」という原則は、グレースフルデグラデーションの実装そのものに固有のリスクとして SRE Book ch.22 が明示する**: 本ページ既出の知見は「なぜグレースフルデグラデーションが有効か」「優先順位づけがどんな副作用を持つか」を扱ってきたが、[[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]] はこれとは異なる軸——「グレースフルデグラデーションの実装自体をどう健全に保つか」という運用上のリスクを指摘する。グレースフルデグラデーションは過負荷などのまれな状況でのみ発動するトリガー頻度の低いコードパスであるため、平常運用では鍛えられず、いざ発動したときに機構自体が意図通り動かない可能性が高まる。対策として、少数のサーバを恒常的に過負荷寸前で稼働させ、このコードパスを定期的に運動させておくことが挙げられる。これは Datadog・Google の各事例が扱う「優先順位づけの設計」とは独立の問題であり、設計が正しくても実装の練度が保証されなければ機能しないという、実装・運用レベルの新しい留意点を加える。(Source: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]) ## 未解決の問い - データ完全性とグレースフルデグレーデーションのトレードオフをどのように定量的に測定するか。ユーザーが「不完全な結果」をどの程度まで許容できるかの閾値は製品ドメインによってどう異なるか。 - グレースフルデグレーデーションの実装が、通常運用時のシステム複雑性（優先順位付けロジック、ブレークグラス機構の保守）に与えるコストをどう評価するか。 - [[メタ安定障害]]（リカバリ試行が障害を悪化させる循環）との関係：ブレークグラスはメタ安定状態からの脱出手段としてどう機能するか。 - トラフィック種別間の優先順位づけ(グレースフルデグレーデーション)がインシデント対応者自身の可用性を損なうという Mayan Apocalypse 型の副作用は、設計段階でどう予見・検証できるか。ブレークグラス機構(Datadog)とインシデント対応専用アクセス機構(Google)は同じ問題への独立した解と言えるか、両者を比較した設計指針はあるか。 - SRE Book ch.21 の criticality ベースの選択的棄却機構は、Mayan Apocalypse が示したような「優先順位づけ機構同士の相互作用による副作用」をどこまで内在的に防げる設計なのか。criticality を RPC システムに一級市民として組み込み自動伝播させる設計は、そうした副作用を緩和する方向に働くのか、あるいは伝播範囲が広がることでむしろ副作用の射程を広げるのか。 - SRE Book ch.22 が提案する「少数のサーバを恒常的に過負荷寸前で稼働させてグレースフルデグラデーションのコードパスを鍛える」という対策は、通常運用でのユーザー体験劣化という別のコストを払っている。このコストと「発動時に動かないリスク」のトレードオフはどう定量化・最適化すべきか。カオスエンジニアリング的な定期実験(本番の一部での意図的なデグラデーション誘発)との関係はどう整理できるか。 ## 関連 - 概念: [[ソフトウェア耐障害性]] / [[障害緩和]] / [[インシデント管理]] / [[メタ安定障害]] / [[クラッシュリカバリ]] / [[Incident Commander]] / [[過負荷制御]] / [[カスケード障害]] - エンティティ: [[Datadog]] / [[Google]] - ソース: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]] / [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]] / [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]] / [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]] / [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]] - [[@2022__OReilly__Anatomy of an Incident - Chapter 6 The Mayan Apocalypse - A Real-World Example]]（Google の実インシデント "Mayan Apocalypse"。トラフィック種別優先順位づけによる自動トリアージと、その副作用としての社内ツール巻き添え） - [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]](グレースフルデグレーデーションをスロットリング・負荷遮断による一般的な劣化戦略として紹介する教科書的節) - [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]](過負荷になったバックエンドは全トラフィックを止めるべきではなく、処理できる分だけを受理し続け残りを行儀よく棄却すべきだという主張。criticality による選択的棄却) - [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]](「使われないコードパスは動かないコードパス」というグレースフルデグラデーション実装固有のリスクと、鍛え続けるための恒常的な過負荷寸前運用という対策)