フレームワーク活用ガイドひとことで言うと#
システムの一部が故障しても全体を停止させず、機能を段階的に落としながらコアな価値を提供し続ける設計手法。「100点か0点か」ではなく「70点でも動き続ける」ことを目指す。
押さえておきたい用語#
- フォールバック（Fallback）
- 主要な処理が失敗した場合に自動的に切り替わる代替の処理や応答のこと。キャッシュ返却やデフォルト値表示などが典型例。
- サーキットブレーカー（Circuit Breaker）
- 障害が発生しているサービスへのリクエストを自動的に遮断する仕組みを指す。電気回路のブレーカーと同じ発想で、連鎖障害を防ぐ。
- 縮退運転（Degraded Mode）
- 一部の機能を無効化または簡略化してサービス全体は維持する運転状態のこと。グレースフルデグラデーションの中核概念。
- フィーチャーフラグ（Feature Flag）
- コード内で特定の機能を動的に有効・無効にできるスイッチのこと。障害時に手動で機能をOFFにする「キルスイッチ」としても使える。
- カオスエンジニアリング（Chaos Engineering）
- 本番環境で意図的に障害を注入してシステムの回復力を検証する手法である。Netflixの「Chaos Monkey」が有名。
グレースフルデグラデーションの全体像#
こんな悩みに効く#
- レコメンドエンジンが落ちただけで、商品一覧ページ全体がエラーになる
- 外部サービスの障害が自社サービスの全面停止につながる
- 障害時に「全く使えない」か「完全に使える」の二択しかない
基本の使い方#
システムの機能を重要度に応じて3段階に分類する。
- Critical（必須）: この機能が止まるとサービスの存在意義がなくなる（例: ECサイトの商品表示・決済）
- Important（重要）: なくても困らないが、体験が劣化する（例: レコメンド、口コミ表示）
- Nice-to-have（あれば嬉しい）: なくてもユーザーは気づかない（例: アクセス解析、パーソナライズバナー）
ポイント: 障害時にNice-to-haveから順に落としていくことで、Criticalな機能を守る。
各機能が利用不能になった場合の代替動作を定義する。
- キャッシュフォールバック: 最新データが取れない場合、キャッシュされた前回のデータを返す
- デフォルト値: レコメンドが動かない場合、人気ランキングを代わりに表示
- 機能の非表示: 障害中のUIコンポーネントを非表示にし、残りの部分は正常に表示
- 静的コンテンツ: 動的生成ができない場合、事前に用意した静的ページを返す
ポイント: フォールバックは事前に設計・実装しておくこと。障害発生後に慌てて考えるのでは遅い。
障害を検知して自動的に縮退モードに切り替わる仕組みを構築する。
- サーキットブレーカーと連携: 外部サービスの障害を検知したら自動的にフォールバック
- フィーチャーフラグ: 手動で特定機能を無効化できるスイッチを用意
- ヘルスチェック: 依存サービスのヘルス状態を監視し、異常を検知
ポイント: 自動切り替え + 手動のキルスイッチの両方を用意する。自動判定が誤る場合に手動でも対応できるようにする。
縮退モードが実際に正しく動作するかを定期的に検証する。
- カオスエンジニアリング: 意図的に依存サービスを落として縮退動作を確認
- ゲームデー: チーム全体で障害シナリオを想定した訓練を実施
- 縮退状態のモニタリング: どの機能が縮退中かをダッシュボードで可視化
ポイント: テストしていない縮退モードは動かないと考えるべき。本番障害で初めて動かすのはギャンブル。
具体例#
状況: 月間PV 500万の中規模ECサイト。商品詳細ページが5つのマイクロサービスに依存しており、1つでも落ちるとページ全体が500エラーになっていた。
機能分類と縮退設計:
| 機能 | 依存サービス | 優先度 | 縮退時の動作 |
|---|---|---|---|
| 商品情報 | 商品サービス | Critical | CDNキャッシュ（1時間前のデータ） |
| 価格・在庫 | 在庫サービス | Critical | 「在庫確認中」と表示 |
| レコメンド | レコメンドサービス | Important | 人気ランキングTOP5を表示 |
| 口コミ | 口コミサービス | Important | 「口コミを読み込めません」と表示 |
| パーソナライズ | 分析サービス | Nice-to-have | セクションごと非表示 |
結果: レコメンドサービスが15分間ダウンした際、ページ全体はエラーにならず、レコメンド欄だけが人気ランキングに切り替わった。ユーザーからの問い合わせゼロ、売上損失もゼロ。以前なら500エラーで推定45万円の売上が消失していた。
以前なら500エラーで推定45万円の売上損失。縮退設計後は問い合わせゼロ、売上損失ゼロ。5つのサービスに優先度をつけてフォールバックを用意しただけ。
状況: 会員数80万人の動画配信サービス。人気アニメの最終回配信時に通常の12倍のアクセスが集中し、サイト全体がダウンした過去がある。
縮退設計:
| 段階 | トリガー | 縮退内容 |
|---|---|---|
| Level 0 | 通常 | 全機能有効 |
| Level 1 | CPU 70%超 | 視聴履歴レコメンドを停止、汎用ランキングに切替 |
| Level 2 | CPU 85%超 | コメント・評価機能を読み取り専用に |
| Level 3 | CPU 95%超 | 新規会員登録を一時停止、既存会員の動画再生を最優先 |
結果: 次の人気作品配信時（通常の8倍アクセス）にLevel 2まで自動縮退が発動。動画再生の成功率は**99.7%**を維持し、コメント機能は15分間読み取り専用になったが、SNSでの苦情はほぼゼロだった。
通常の8倍アクセスでも動画再生成功率99.7%。コメント機能は15分間読み取り専用になったが、SNSでの苦情はほぼゼロ。「コア機能を守る」という発想転換が効いた。
状況: 口座数35万の地方銀行。オンラインバンキングが全銀システム、クレジットカード会社API、為替レートAPIなど7つの外部サービスに依存。為替レートAPIの障害時に外貨預金ページだけでなく、ログイン後のトップページ全体がエラーになっていた。
縮退設計:
- 為替レートAPI障害 → 直近のキャッシュレート（最大30分前）を表示し「※参考レートです」を付記
- カード会社API障害 → カード利用明細の「取得中」表示。振込・残高照会は通常通り
- 全銀システム障害 → 振込予約のみ受付（即時振込は停止）、残高照会は行内DBから提供
結果: 為替レートAPI障害（年間平均4.2回発生）時に、以前は毎回約2時間の全面停止だったが、縮退設計後はトップページの正常表示率が100%に。年間の障害影響時間が合計8.4時間→0時間に削減された。
年間の障害影響時間、合計8.4時間→0時間。参考値やキャッシュを活用した縮退運転で、「完璧に動くか全く動かないか」の二択から脱却できた。
やりがちな失敗パターン#
- すべてをCriticalに分類する — 「全部大事」は何も分類していないのと同じ。本当にサービスが成り立たない機能だけをCriticalにする。勇気を持って優先度を下げる
- フォールバックのテストをしない — フォールバック処理自体にバグがあり、障害時にかえって事態が悪化する。定期的にフォールバック経路のテストを実行する
- 縮退状態からの復帰を忘れる — 障害が回復した後も縮退モードのままになっていた。自動復帰の仕組みとモニタリングを必ず組み込む
- フォールバックのデータ鮮度を考慮しない — キャッシュフォールバックで3日前の在庫データを表示し、注文が入ったが在庫がなかった。キャッシュの有効期限と「参考値」表示のルールを事前に決めておく
まとめ#
グレースフルデグラデーションは「障害をゼロにする」のではなく 「障害の影響を最小化する」 ための設計哲学。機能の優先度を分類し、フォールバック戦略を事前に設計し、自動切り替えの仕組みを構築する。そして何より、定期的にテストして 「縮退モードが確実に動く」 ことを証明しておくことが、本番障害時の命綱になる。