Valkey Global DatastoreのDR演習を実運用化する手順

マネージド構成でもDRは自動で完成しない

Global Datastoreを導入すると「DRは解決した」と思いがちですが、実際はそう単純ではありません。リージョン間複製には遅延、整合性、切替順序、アプリ側の再試行戦略など複数の可変要素があり、実障害で初めて露出する問題が多くあります。

最近のValkey検証事例が示す通り、信頼性は設定値ではなく演習回数と検証密度で決まります。

演習前に「許容値」を明文化する

まず以下を数値で決めます。

• 許容できる陳腐データ参照時間
• フェイルオーバー開始から復旧までの許容時間
• リージョン分断時の書き込み損失許容範囲
• セッション/レート制御/フラグ配信への影響許容

この定義がないと、演習後の評価が感覚論になります。

最低限試すべき3シナリオ

1. Primaryリージョン完全停止
2. リージョン間の断続的パケット損失
3. 制御系は生きているがデータ系が劣化

多くのチームは1のみ実施しますが、実害が出やすいのは2です。とくにトークンやクォータ管理では、微妙な遅延がビジネス不整合に直結します。

アプリ側キャッシュ契約を先に定義する

障害時に何を許容するかをサービス単位で決めます。

• stale許容可能キー
• 強整合チェックが必要なキー
• キューイング再送できる書き込み
• 必ずfail-closeすべき操作

この契約がないまま切替ると、復旧後に整合崩れを検知できません。

DRで見るべき観測指標

平均値だけでなく分布を見ます。

• 複製遅延の分布
• 切替中コマンド別エラー率
• ホットキーのミス急増
• 接続張り直しと再試行ストーム
• リージョン別p95/p99遅延

さらに、ログイン成功率や購入完了率と関連付けることで、ユーザー影響を定量化できます。

安全な切替シーケンス

以下の順序を推奨します。

1. 非必須書き込みを停止
2. 複製状態が閾値内か確認
3. フェイルオーバー実施
4. 書き込みクラスを段階再開
5. キースペース乖離兆候を監視
6. 重点データ整合チェック

切替直後に全面書き込み再開すると、二次障害を誘発しがちです。

DRを「要件」としてリリースに組み込む

Global Datastore依存サービスには、リリースゲートとして次を設定します。

• 直近演習の成功日
• ロールバック手順の検証有無
• キャッシュ契約のオンコール責任者
• 未解決DRリスクの一覧

これを満たせないなら、高可用性を名乗るべきではありません。

まとめ

Global Datastore機能は強力ですが、信頼できる運用にするには定期DR演習が不可欠です。2026年のSRE実務では、DRを年次行事ではなく継続的なエンジニアリング作業として扱うチームが生き残ります。