Valkey Global Datastore障害演習: 2026年のDRゲームデイ実践プレイブック

なぜキャッシュDR演習が必須になったか

キャッシュは「性能向上のための補助」だと見なされがちですが、現在の多くのプロダクトでは可用性の中核です。セッション、レート制御、レコメンド、読み取り負荷分散がキャッシュ前提で設計されているため、リージョン障害時の挙動が崩れると即座にユーザー影響が出ます。

Valkey Global Datastoreのようなクロスリージョン構成を採用していても、図面どおりに復旧するとは限りません。演習でしか見えない差分が必ずあります。

まず「キャッシュSLC」を定義する

演習前にサービスごとの契約（Service-Level Contract）を明文化します。

許容できる古さ（stale window）
許容レイテンシ上昇
キー種別ごとの整合性要求
フォールバック時の振る舞い（DB直読、劣化応答、キュー退避）

この契約がないと、障害時に議論だけ増えて意思決定が遅れます。

RTO/RPOはキー種別で分ける

一律目標は実務では粗すぎます。例えば:

セッション/認証近傍キー: 厳しいRTO、整合性重視
商品一覧等の参照キー: 中程度RTO、一定の古さ許容
派生推論キー: UX許容範囲内で復旧優先度を下げる

キー種別単位の目標にすると、演習の評価が現実的になります。

四半期で回すべき演習シナリオ

最低限、次の4シナリオを回してください。

主リージョンの書き込み経路劣化
トラフィック急増時のレプリケーション遅延
フェイルオーバーAPIの部分失敗
切替後の古いキー再増幅（stale storm）

各シナリオに仮説と合格条件をセットで置くのが重要です。

初回ゲームデイの進め方

T-14日: 設計

影響が見えやすいユーザージャーニーを1つ選ぶ
キースペースを業務重要度で分類
観測ダッシュボードを準備（lag, hit率, miss penalty, fallback）

T-7日: 準備確認

Runbook責任者とエスカレーションを確定
連絡テンプレートと通信経路を検証
ロールバック権限者を明確化

当日: 実行

ベースライン採取
故障注入
Runbookどおりに切替
判断時刻と判断理由を記録

T+2日: 振り返り

期待挙動と実挙動の差分分析
契約違反箇所を抽出
Runbook/設計改善を優先度付きで登録

観測指標の実践セット

レプリケーション遅延の分位値
リージョン別read/write成功率
miss時のオリジン負荷増分
fallback発動時間
ユーザー向け遅延・エラーバジェット消費

キャッシュ内部指標だけ見ても不十分です。必ずユーザー影響に紐づけます。

よくある失敗と対策

失敗1: 切替自体は成功したがアプリ設定が追従しない

対策: エンドポイント解決を集中管理し、切替後検証を自動化。

失敗2: 切替後にstaleデータが雪崩れる

対策: キーバージョニングと段階ウォームアップを実装し、全面無効化を避ける。

失敗3: Runbookと実環境が乖離

対策: CIにRunbook健全性チェックを組み込み、机上演習＋技術演習を定期化。

所有権モデル

Platform/SRE: 制御平面と切替手順
各サービスチーム: 契約遵守とフォールバック実装
インシデントコマンダ: 本番相当判断とGo/No-Go

所有権を暗黙にすると、緊急時に責任が宙に浮きます。

次に自動化すべき項目

フェイルオーバー前の前提チェック
危険条件での実行防止ガード
演習レポートの自動生成
Runbook更新後の回帰確認

自動化の目的は手順隠蔽ではなく、判断負荷の低減です。

まとめ

Valkey Global Datastoreを活かす鍵は、構成の豪華さではなく運用の再現性です。ゲームデイで契約と現実を擦り合わせ、改善サイクルを固定化できたチームほど、実障害で早く復旧できます。