🐱 うさねこ教室 Python と可観測性の教室

可用性と信頼性

🐱 この章の目次

可用性ターゲット

可用性(availability) は、システムが正常に応答できる時間の割合で表されます。 業界では「ナイン」で表現され、99.9%(スリーナイン)は年間約 8.7 時間のダウンタイムを許容します。 『インフラ大全』第 2 章では、可用性ターゲットをビジネス要件から逆算して設定するプロセスが解説されています。

可用性年間ダウンタイム月間ダウンタイム
99%(ツーナイン)3.65 日7.3 時間
99.9%(スリーナイン)8.7 時間43.8 分
99.99%(フォーナイン)52.6 分4.4 分
99.999%(ファイブナイン)5.3 分26.3 秒

可用性は直列構成のコンポーネントを掛け合わせて算出するため、依存サービスが増えるほど全体の可用性は下がります。

冗長化パターン

冗長化(redundancy) は、コンポーネントの障害に備えて予備を用意する設計です。 アクティブ-スタンバイ構成では障害時にフェイルオーバーが発生し、切り替え時間分のダウンタイムが生じます。 アクティブ-アクティブ構成では複数ノードが同時にリクエストを処理し、1 台の障害が即座にサービス停止につながりません。

ヘルスチェック

ヘルスチェック(health check) は、ロードバランサやオーケストレータがインスタンスの正常性を定期的に確認する仕組みです。 Liveness チェックはプロセスの生存を確認し、Readiness チェックはトラフィックを受け入れ可能かを判定します。 ヘルスチェックの間隔と閾値を適切に設定しないと、フラッピング(頻繁な ON/OFF)が発生します。

サーキットブレーカー

サーキットブレーカー(circuit breaker) は、下流サービスの障害が上流に波及するのを防ぐパターンです。 連続したエラーが閾値を超えると回路を「オープン」にし、一定時間はリクエストを送らず即座にエラーを返します。 DDIA 第 1 章でも信頼性の文脈でカスケード障害の危険性が強調されています。

# サーキットブレーカーの設定例(概念)
circuit_breaker:
  failure_threshold: 5
  recovery_timeout: 30s
  half_open_max_requests: 3

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

グレースフルデグラデーション(graceful degradation) は、システムの一部が障害を起こしても、コア機能を維持しつつ縮退運転する設計です。 たとえばレコメンデーションサービスが落ちても、商品一覧は表示し続けるという方針です。 機能ごとに優先度を定義し、障害時にどの機能を落とすかを事前に決めておくことが重要です。

参考文献

  • 『インフラ大全』第 2 章 — 可用性と信頼性の設計
  • DDIA 第 1 章 — 信頼性・スケーラビリティ・保守性