Vault Enterprise Replication の概要 — DR と Performance の運用整理

Vault Enterprise の Replication は大きく DR（Disaster Recovery）と Performance の2系統。前者は可用性確保、後者はレイテンシ低減とスケールアウトが目的です。両者は役割が異なり、併用が基本です。

本稿では、公式ドキュメントの安定した挙動をベースに、設計と運用に必要な最低限の判断材料とコマンドをまとめます。Ops 観点の手順・監視・切替手順、試験で問われやすい要点も併せて確認します。

Enterprise Replication の全体像と用語

Replication は Enterprise 機能で、同一クラスターの状態を別クラスターに非同期で複製します。DR Replication はフェイルオーバー前提の待機系、Performance Replication は読み取りスケールと地理分散を目的とした系統です。多くのエンタープライズ環境では、1つの Primary に対して複数の Performance Secondary と1つ以上の DR Secondary を組み合わせます。

ストレージは Integrated Storage（Raft）または Consul をサポートしますが、新規構築は Integrated Storage が推奨です。いずれの場合もクラスター間は TLS で保護され、セカンダリ有効化時のワンタイム・アクティベーション・トークンで相互接続を確立します。

• Primary: 複製のソース（書き込みの正）
• Secondary: 複製の宛先。DR は待機系、Performance は読取系（複製対象への書き込みは不可）
• Local マウント: レプリケーション対象外のローカル専用マウント（Performance Secondary でよく使う）
• Namespace: Enterprise のマルチテナンシ単位。Replication は Namespace を含めて扱う

DR Replication の設計と動作

DR Secondary は通常クライアント要求を処理しません。Primary の状態（ポリシー、Secrets、トークン、リースなどクラスター全体）を非同期で受け取り、障害時に迅速に昇格できます。昇格後は新しい Primary となり、クライアントの読み書きを受け付けます。

DR は“全体の保護”が原則で、選択的に一部のみを除外する設計ではありません。RPO はネットワーク状況と負荷に依存し、秒〜数十秒程度の非同期を前提にします。

• 平常時: DR Secondary は待機。API にはヘルス関連以外応答しないのが基本
• 障害時: DR Secondary を昇格して業務再開
• 計画停止: DR へ切替→元サイト復旧後に再同期間を行い戻す（フェイルバック）

代表構成（Primary + Performance Secondaries + DR Secondary）

Performance Replication の設計と動作

Performance Secondary はクライアントの読み取り要求を近接拠点で処理し、レイテンシを抑えます。複製対象のマウントやデータに対しては原則読み取り専用です。書き込みトランザクションは Primary で完結させる設計にします。

レプリケーション対象にしたくないデータは local フラグ付きマウントとして分離します。たとえば、拠点固有の短期データやメトリクス用トークンなどは Local マウントに置くと、セカンダリごとに独立運用できます。

• 複製対象は読取専用（書き込みは Primary 側で実施）
• Local マウントは複製されず、各セカンダリで独立して読書き可
• Namespace 単位の整合性に注意（同一の論理構成を前提に設計）

セットアップ手順と主要コマンド（安定動作の範囲）

以下は最小限の有効化手順の一例です。いずれも TLS が正しく設定され、クラスター同士が到達可能であることが前提です。実環境では RBAC、ネットワーク制約、監査設定を合わせて行います。

コマンドは公式ドキュメントの安定 API を使用しています。検証環境での手順確認後に本番適用してください。

• DR と Performance は同一 Primary 上で併用可
• セカンダリ有効化はワンタイム・トークンで紐付ける
• Local マウントは secrets enable で -local を付与

DR/Performance の有効化と昇格（例）

# 1) DR Primary を有効化（Primary クラスターにて）
vault write -f sys/replication/dr/primary/enable

# 2) DR Secondary 用のアクティベーション・トークンを発行（Primary）
DR_TOKEN=$(vault write -field=token -f sys/replication/dr/primary/secondary-token)

# 3) DR Secondary を有効化（Secondary クラスターにて）
vault write sys/replication/dr/secondary/enable token="${DR_TOKEN}"

# 4) DR ステータス確認（任意のクラスターで）
vault read sys/replication/dr/status

# 5) 障害時に DR Secondary を昇格（Secondary 側で実行）
vault write -f sys/replication/dr/secondary/promote

# 6) Performance Primary を有効化（Primary クラスター）
vault write -f sys/replication/performance/primary/enable

# 7) Performance Secondary 用トークンを発行（Primary）
PERF_TOKEN=$(vault write -field=token -f sys/replication/performance/primary/secondary-token)

# 8) Performance Secondary を有効化（Secondary クラスター）
vault write sys/replication/performance/secondary/enable token="${PERF_TOKEN}"

# 9) Performance ステータス確認
vault read sys/replication/performance/status

# 10) Local マウントの例（セカンダリ上で複製しないマウントを作成）
# 例: 各拠点専用の kv マウント
vault secrets enable -path=kv-local -version=2 -local kv

運用・監視・変更管理の勘所

監視は Replication のラグ、リンク状態、再シード要求の有無を中心に。公式の Telemetry と Prometheus エクスポートを使って遅延や失敗率を可視化します。ヘルスチェック API と sys/replication/*/status を合わせてダッシュボード化しておくと切替判断が早くなります。

変更管理では、Primary のローリングアップグレードとセカンダリの順序、証明書更新時の相互接続維持、障害訓練の定例化が重要です。スナップショット（Integrated Storage の raft snapshot）を計画的に取得し、復旧パスを二重化しておきます。

• ラグ監視: replicated ops/sec、キュー長、秒単位の遅延を継続監視
• リンク状態: status API の connected, mode, last_heartbeat などを見る
• 証明書更新: cluster_addr と相互 TLS の更新手順を標準化
• バックアップ: vault operator raft snapshot save を定期実行（Integrated Storage）
• 切替訓練: DR 昇格→フェイルバックのリハーサルを四半期ごとに

試験対策の要点と実務の落とし穴

試験では、DR と Performance の目的・動作差、どちらがクライアント要求を扱えるか（DR は待機、Performance は読取のみ）、Local マウントの使い所、昇格手順の基本が頻出です。実務では、DR と Performance の併用、Local と複製対象の境界設計、ネットワーク遅延下での期待整合性の読み違いに注意します。

• DR は全体保護、Performance は読取スケール。役割が違う
• Performance Secondary は複製対象への書き込み不可。Local は可
• DR Secondary は通常リクエストを受付けない。昇格後に受付ける
• アクティベーション・トークンでセカンダリをひも付けるのが定石
• 新規は Integrated Storage 推奨。Consul 併用環境は互換性と手順を事前検証
• RPO/RTO は非同期を前提に評価する（ゼロは前提にしない）

問題で確認

よくある質問