IT女子 アラ美お疲れ様です！IT業界で働くアライグマです！
「本番でAPIが落ちて、連鎖的にシステム全体が止まった」「1つのサービスの障害が全画面に波及して、復旧に半日かかった」。マイクロサービスや分散システムを運用していると、こうした障害の連鎖は避けて通れません。
本記事では、障害を「起きないようにする」のではなく、「起きても被害を最小限に抑える」ためのレジリエンスパターン7選を、実装例とともに解説します。
レジリエンスパターンとは：本番障害を「想定内」にする設計思想
IT女子 アラ美レジリエンス（Resilience）とは、障害が発生しても、システム全体として機能を維持し続ける能力のことです。「壊れないシステム」を目指すのではなく、「壊れても大丈夫なシステム」を設計する考え方です。
従来のモノリシックアーキテクチャでは、アプリケーション内部のメソッド呼び出しが失敗することは稀でした。しかしマイクロサービスでは、ネットワーク越しのHTTP/gRPC呼び出しが日常的に失敗します。タイムアウト、接続エラー、502/503エラーは「異常」ではなく「日常」です。
この「日常的に失敗する」前提に立って設計するのがレジリエンスパターンです。障害発生時の初動対応についてはインシデント初動対応テンプレートも参考にしてください。
IT女子 アラ美
ITアライグマ前提条件と適用判断基準
7つのパターンを全て実装する必要はありません。システムの特性に応じて必要なパターンを選択するのが現実的です。
適用すべきシステムの特徴
- マイクロサービス構成：サービス間通信が存在するシステム
- 外部API依存：サードパーティのAPIを呼び出しているシステム
- 高可用性要件：SLA 99.9%以上が求められるシステム
優先度の考え方
- まず入れるべき：Timeout（設定するだけ）、Health Check（監視の基本）
- 次に入れるべき：Circuit Breaker、Retry（障害の連鎖防止）
- 必要に応じて：Bulkhead、Fallback、Rate Limiter（高度な制御）
Docker環境でのマイクロサービス構築についてはDocker開発環境セットアップガイドで基礎を解説しています。
IT女子 アラ美ITアライグマパターン1〜4：即効性のあるレジリエンスパターン
パターン1：Circuit Breaker（サーキットブレーカー）
電気のブレーカーと同じ原理です。連続して失敗が発生したら、一定時間そのサービスへのリクエストを遮断します。これにより、障害が発生したサービスへの無駄なリクエストを止め、連鎖的な障害を防ぎます。
import circuitbreaker
@circuitbreaker.circuit(failure_threshold=5, recovery_timeout=30)
def call_payment_service(order_id):
response = requests.post(
f"{PAYMENT_API}/charge",
json={"order_id": order_id},
timeout=3
)
response.raise_for_status()
return response.json()
5回連続で失敗したら30秒間リクエストを遮断し、その間は即座にエラーを返します。
パターン2：Retry（リトライ）
一時的な障害に対して、一定間隔で再試行するパターンです。ネットワークの瞬断やサーバーの一時的な過負荷に有効です。
from tenacity import retry, stop_after_attempt, wait_exponential
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=1, max=10)
)
def fetch_user_data(user_id):
response = requests.get(f"{USER_API}/users/{user_id}", timeout=5)
response.raise_for_status()
return response.json()
指数バックオフ（1秒→2秒→4秒と間隔を広げる）にすることで、障害中のサービスに負荷をかけすぎないようにします。
パターン3：Timeout（タイムアウト）
最もシンプルで最も重要なパターンです。全てのHTTPリクエストにタイムアウトを設定します。タイムアウトがないと、障害中のサービスへのリクエストがスレッドを占有し続け、呼び出し元のサービスまで応答不能になります。
パターン4：Bulkhead（バルクヘッド）
船の水密隔壁と同じ原理です。リソースを分離して、1つのサービスの障害が他に波及しないようにするパターンです。スレッドプールやコネクションプールをサービスごとに分けることで実現します。
Kubernetesでの実装についてはKubernetesセキュリティ強化ガイドでPod単位のリソース分離を解説しています。
IT女子 アラ美ITアライグマパターン5〜7：組織・アーキテクチャレベルのパターン
パターン5：Fallback（フォールバック）
メインの処理が失敗した場合に、代替手段に切り替えるパターンです。例えば、リアルタイムの推薦APIが落ちたら、キャッシュされた人気ランキングを返す設計です。
パターン6：Rate Limiter（レートリミッター）
一定時間内のリクエスト数を制限するパターンです。DDoS攻撃の防御だけでなく、突発的なトラフィック増加からシステムを守る目的でも使います。
パターン7：Health Check（ヘルスチェック）
各サービスが自身の状態を報告するエンドポイントを持つパターンです。ロードバランサーやオーケストレーターが異常なインスタンスを自動的にトラフィックから外す仕組みと連動させます。
モニタリングとの連携についてはPrometheusモニタリングガイドで詳しく解説しています。
IT女子 アラ美ITアライグマケーススタディ：マイクロサービスの障害連鎖を止めた事例
IT女子 アラ美ここでは、村田さん（仮名・33歳・SREエンジニア・経験8年）のチームがレジリエンスパターンを導入した事例を紹介します。
状況（Before）
- システム構成：ECサイトのマイクロサービス（商品・注文・決済・在庫・通知の5サービス）
- 障害頻度：月平均3回のサービス間通信障害が発生
- 影響範囲：1つのサービスが落ちると、平均して3つのサービスに連鎖し、全画面が応答不能に
- 復旧時間：障害発生から復旧まで平均45分
- 心境：「金曜の夕方に決済サービスが落ちた時は、週末が吹き飛んだ」
行動（Action）
- Phase 1（1週目）：全APIクライアントにTimeout（3秒）を設定。設定変更のみでコード変更なし
- Phase 2（2〜3週目）：決済サービスへの呼び出しにCircuit Breaker + Retryを導入。Python circuitbreakerライブラリを採用
- Phase 3（4週目）：在庫サービスにFallbackを実装。在庫APIが落ちた場合、直近のキャッシュデータを返す設計に変更
- Phase 4（5〜6週目）：各サービスにHealth Checkエンドポイントを追加。KubernetesのLiveness/Readiness Probeと連動
結果（After）
- 障害の連鎖：平均3サービス波及 → 1サービスで止まる（連鎖率67%削減）
- 復旧時間：45分 → 8分（82%短縮。Health Checkによる自動切り離しが効いた）
- ユーザー影響：全画面応答不能 → 該当機能のみ「一時的に利用できません」表示
- 週末出勤：月1回 → 0回
村田さんは振り返ります。「最初にTimeoutだけ入れたのが正解だった。1行の設定変更で連鎖障害の半分が防げた。全パターンを一度に入れようとしていたら、何ヶ月もかかっていた」。
障害対応ログの設計についてはログ監視のベストプラクティスも参考にしてください。
IT女子 アラ美ITアライグマさらなる実践・活用に向けて
レジリエンスパターンを導入したら、次のステップとして以下を検討してみてください。
カオスエンジニアリングの導入
Netflixが提唱した「意図的に障害を起こしてシステムの耐障害性を検証する」アプローチです。レジリエンスパターンが正しく機能しているかを、本番に近い環境で継続的にテストします。
SLO/エラーバジェットの設計
「99.9%の可用性を目指す」と定義し、残りの0.1%を「使っていいダウンタイム」として計画的に消費する考え方です。レジリエンスパターンの導入優先度を、SLOとの乖離で判断できます。
障害設計ができるSRE/インフラエンジニアの市場価値は高く、ハイクラス転職エージェント3社比較で紹介しているようなハイクラス求人でも高く評価されます。
IT女子 アラ美ITアライグマよくある質問
小規模なサービスでもレジリエンスパターンは必要ですか？
外部APIを1つでも呼び出しているなら、最低限Timeout + Retryは入れるべきです。小規模でも外部サービスの障害は起きます。設定1行で防げる障害を放置する理由はありません。
Circuit Breakerの閾値はどう決めればいいですか？
一般的には失敗5回で遮断、30秒後にリトライが出発点です。本番のトラフィック量とエラー率を観察しながら調整してください。閾値が低すぎると正常時にも遮断が発動し、高すぎると障害の連鎖を防げません。
Retryを入れると障害を悪化させることはありませんか？
リトライ上限と指数バックオフを設定しないと悪化させるリスクがあります。必ず最大3回程度の上限と、1秒→2秒→4秒の指数バックオフをセットで使ってください。
さらなる年収アップやキャリアアップを目指すなら、ハイクラス向けの求人に特化した以下のサービスがおすすめです。
| 比較項目 | TechGo | レバテックダイレクト | ビズリーチ |
|---|---|---|---|
| 年収レンジ | 800万〜1,500万円ハイクラス特化 | 600万〜1,000万円IT専門スカウト | 700万〜2,000万円全業界・管理職含む |
| 技術スタック | モダン環境中心 | Web系に強い | 企業によりバラバラ |
| リモート率 | フルリモート前提多数 | 条件検索可能 | 原則出社も多い |
| おすすめ度 | 技術で稼ぐならここ | A受身で探すなら | Bマネジメント層向け |
| 公式サイト | 無料登録する | - | - |
IT女子 アラ美ITアライグマまとめ
本番障害の影響を最小限に抑えるためのレジリエンスパターン7選を解説しました。
- まず入れるべき：Timeout（設定1行で連鎖障害の半分を防げる）とHealth Check
- 次に入れるべき：Circuit Breaker + Retry（障害の連鎖を自動で止める）
- 段階的に導入：Timeoutから始めて、効果を確認しながら追加していく
- 実績：ケーススタディでは復旧時間45分→8分、週末出勤月1回→0回を実現
「障害は起きる」を前提にして、起きた時にどう振る舞うかを設計しておく。これがレジリエンスパターンの本質です。まずは全APIクライアントにTimeoutを設定するところから始めてみてください。
IT女子 アラ美ITアライグマ
