可用性設計と冗長化戦略
可用性を数値で設計する――SLO/SLIとエラーバジェット
まず「どれだけ落ちてよいか」を決めます。稼働率99.9%は月あたり最大43.2分の停止を許容するという意味です。SLOは「外形的に測れる指標」で定義します。例として「P95レイテンシ200ms以下」「エラー率0.1%未満」「結合テスト用エンドポイントの成功率99.95%」のように、ユーザー体験に直結するSLIを選びます。MTTR（平均復旧時間）とMTBF（平均故障間隔）も併せて追い、停止時間＝MTTR/（MTTR+MTBF）で稼働率を見積もります。
エラーバジェットを運用意思決定に使う
許容停止時間＝エラーバジェットです。消費速度（Burn Rate）で監視します。例えば月間99.95%（21.6分）のとき、Burn Rateが2倍以上で1時間継続したらリリース凍結、14倍が5分続いたら即時エスカレーション、と段階を決めます。数字が曖昧だと議論が感情戦になります。アラート閾値、当番の起床条件、リリース可否までSLO連動にすると、チーム合意が取りやすくなります。
- RTO（復旧目標時間）：例 2分。フェイルオーバー自動化の有無で現実化。
- RPO（復旧時点目標）：例 0〜60秒。同期/非同期レプリケーション選択に直結。
- バックアップは「取得」より「復元」手順の実測時間で評価。
冗長化パターンの選び方――RTO/RPOと依存性で分岐
N+1とActive-Standbyは一歩目の定番
単体構成からの脱出はN+1（1台余剰）かActive-Standbyです。ヘルスチェックで自動昇格し、RTOを60秒以内に抑えます。ステート保持が必要なら、セッションはアプリ外部（Redis等）に出し、LBのスティッキー依存を避けます。
Active-Activeの採否はRTOと一貫性要求で決める
- RTOが1分未満、突発トラフィックに強くしたい：Active-Active＋L4/L7ロードバランサで分散。整合性要件が緩い層（キャッシュ、検索）は特に相性良。
- RPO=0が必須：同期コミット（マルチAZ）を選択。ただし遅延とコスト上昇は受け入れ前提。地理的に離すほど待ち時間が増える点に注意。
- 地理冗長：まずはマルチAZ（同地域の独立設備）で大半の障害をカバー。マルチリージョンはDNSフェイルオーバー（TTL 30秒前後）とデータの整合戦略（単一書き込み/コンフリクト解決）を先に決めてから。
依存切り離しと耐障害の作法
- サーキットブレーカで下流の遅延伝播を遮断、フォールバック応答を用意。
- キューイングでスパイクを平滑化。冪等性キーを設計して再試行を安全に。
- スロットリングとバックプレッシャで自衛。全体停止より優雅な劣化を選ぶ。
観測しやすい構成にする
LB/アプリ/DBそれぞれにヘルスチェックとメトリクスを持たせます。ブラックボックス（合成監視）でユーザー視点を担保し、ホワイトボックス（内部メトリクス）で原因特定を早めます。SLIはダッシュボードで一枚に集約し、SLO偏差を色で即把握できるようにします。
監視と演習を設計に組み込む
冗長化は作って終わりではなく、切替が「いつ・どう」動くかを監視と演習で固めます。アラートはSLO準拠（Burn Rate 2x/6h、14x/5mなど）とし、ページングは1跳びで当番へ。Runbookは「検知→判断→操作」の3段で書き、スクリーンショットとタイムスタンプ記録欄をつけます。文章整形やテンプレ化にはChatGPTやClaudeが手早く、IaCの変更レビューにはCopilot、需要予測の粗推定にはGeminiの時系列回帰が役立ちます（最終判断は人が行う前提）。
フェイルオーバー演習（GameDay）の型
- SLOとRTO/RPOを掲示し、成功条件を数値で定義。
- 依存関係マップ（外部API/DB/キャッシュ/DNS）を更新。
- 障害注入（ノード停止、ネットワーク分断、遅延追加）を段階的に実施。
- 検知時刻・自動切替時刻・復旧完了時刻を計測し、RCAと改善Issueを即起票。
- 次回までにRunbookと自動化を1つ以上更新してクローズ。
身近な企業活用例：しろくまコーヒーECの失敗と改善
地方発の中堅EC「しろくまコーヒー」（従業員50名、月間MAU3万）。11月のセール初日に障害が発生。単一AZにWeb/DBが同居、L7 LBも同一設備。AZ障害で45分停止、注文ロストも発生。SLO未定義でエスカレーションも遅れ、売上機会を逃しました。
改善では、SLOを99.95%、RTO 2分、RPO 0に設定。Webは2AZにオートスケール、クロスゾーンLBで分散。セッションは外部ストアへ移し、スティッキー無効でも問題ない設計に。DBはマルチAZ同期レプリケーション＋読み取りレプリカを用意し、手動昇格Runbookを整備。DNSはヘルスチェック付きでフェイルオーバーし、TTLは30秒。合成監視を3地域から30秒間隔で実施し、Burn Rateアラートを導入。当番表とエスカレーションを明文化し、月次でGameDayを開催。Runbookの文面整理にChatGPTとClaude、IaCの差分レビューにCopilot、セール負荷の粗見積にGeminiを活用しました。
結果、次のセールではRTO実測68秒、RPO 0を達成。在庫APIの遅延時もサーキットブレーカと簡易在庫キャッシュで優雅な劣化に抑制。コストは18%増でしたが、離脱率改善で粗利はプラス転換しました。意思決定は「SLO→パターン選定→演習→監視改善」の循環でブレなく前進しました。
可用性設計は図面だけでなく、監視・運用の現場に落として初めて機能します。サーバ監視運用事業の文脈では、SLO起点の監視設計、Burn Rate型アラート、Runbookと自動化、定期演習の運用ループが要です。冗長化の投資対効果は、日々の検知と復旧の確かさでのみ回収されます。
