Vault DR Replication 実務と試験対策: 災害復旧クラスタを正しく設計・運用する

Vault の DR Replication は、災害時に業務を継続させるための非同期・一方向のレプリケーション機能です。平常時はセカンダリは待機し、障害時に昇格してプライマリとして稼働します。

本稿は、公式ドキュメントの安定挙動に基づき、設計の基本、セットアップ手順、フェイルオーバー/フェイルバック、監視と演習、そして DR と Performance の比較を、資格対策と実務の両面から整理します。

DR レプリケーションの基本と試験で問われる要点

Vault の DR レプリケーションは、同一のデータセットを別リージョン/別クラスターへ非同期に複製し、平常時は待機、障害時にセカンダリを昇格してサービスを再開する仕組みです。セカンダリは昇格するまでクライアント要求を処理しません。

Ops 観点で重要なのは、役割（DR Primary/DR Secondary）、昇格・降格の操作、RPO/RTO の考え方、TLS と証明書の前提、そして Performance Replication との違いです。試験ではこれらの概念差分が頻出です。

• 目的: サイト障害に備えた事業継続。平常時は待機、障害時のみ切り替え。
• 通信: 非同期・一方向（Primary → Secondary）。
• セカンダリの性質: 昇格するまでクライアント要求は原則不可（待機）。
• RPO/RTO: 非同期ゆえ RPO は数秒〜ネットワーク遅延相当が目安。RTO は昇格・ルーティング切替に依存（手順の自動化で短縮）。
• ストレージ: Integrated Storage（Raft）推奨。Consul を使う設計も可能だが、運用要件を比較して選定。
• 注意: DR と Performance は目的が異なる。DR は災害復旧、Performance は読み取りスケール。

状態確認の最小コマンド（準備段階）

export VAULT_ADDR=https://primary.example.com:8200
export VAULT_TOKEN=<admin_or_appropriate_token>

# DR ステータスの確認（Primary 側）
vault read sys/replication/dr/status

# サーバ状態の確認
vault status

アーキテクチャ設計: リージョン間 DR クラスタの基本形

実運用では、リージョンやデータセンターをまたいで DR セカンダリを配置します。ネットワークは双方向に TLS で疎通可能、かつ API アドレスとクラスターアドレスが証明書の SAN と整合している必要があります。

Integrated Storage（Raft）を用いると、外部 K/V ストアに依存せずシンプルに構成できます。クラスタ内の 8201（cluster_addr）での相互通信と、クライアント向け 8200（api_addr）の正設定が肝要です。

• 必要ポート: 8200/TCP（API）、8201/TCP（クラスタ間 Raft）。
• 証明書: api_addr/cluster_addr のホスト名と SAN の一致、相互 TLS の検討。
• 監視: 後述の /sys/replication/dr/status と /sys/metrics（Prometheus）を活用。
• ルーティング: フェイルオーバー時の DNS/ロードバランサ切替を自動化。
• 演習: 計画停止での昇格・降格を四半期ごとに実施。

DR レプリケーション（リージョン間・Raft）

server.hcl（抜粋・安定パラメータの例）

storage "raft" {
  path  = "/opt/vault/data"
  node_id = "vault-node-1"
}
api_addr     = "https://vault-a.example.com:8200"
cluster_addr = "https://vault-a.example.com:8201"
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = 0
  tls_cert_file = "/opt/vault/tls/tls.crt"
  tls_key_file  = "/opt/vault/tls/tls.key"
}

セットアップ手順（本番想定・安全側）

以下は最小限の手順です。事前に TLS、ポリシー、監査ログ、ストレージ健全性（Raft/Consul）を確認したうえで実施します。二重化された管理者承認フローを用意すると安全です。

セカンダリ有効化トークンは、プライマリで生成し、セカンダリで有効化に使用します。トークンは短期・限定用途として厳重に扱います。

• 前提: 両クラスターが初期化・アンシール済みで正常（vault status が ok）。
• ステップ1: プライマリを DR Primary として有効化。
• ステップ2: セカンダリ有効化トークンを生成し、安全経路で転送。
• ステップ3: セカンダリ側で DR Secondary を有効化。
• ステップ4: 双方向でステータス確認、レプリケーションの収束を待機。
• ステップ5: ルーティング設計の確認（平常時は Primary のみクライアント受付）。

DR レプリケーション有効化コマンド例

# Primary 側
export VAULT_ADDR=https://primary.example.com:8200
export VAULT_TOKEN=<admin_token>

# 1) DR Primary を有効化
vault write -f sys/replication/dr/primary/enable

# 2) Secondary 有効化トークンを生成
DR_TOKEN=$(vault write -field=token -f sys/replication/dr/primary/secondary-token)

# Secondary 側
export VAULT_ADDR=https://secondary.example.com:8200
export VAULT_TOKEN=<admin_token_on_secondary>

# 3) DR Secondary を有効化（primary_api_addr は環境に応じて）
vault write sys/replication/dr/secondary/enable \
  token="$DR_TOKEN" \
  primary_api_addr="https://primary.example.com:8200"

# 4) ステータス確認（両側で）
vault read sys/replication/dr/status

フェイルオーバーとフェイルバック（計画/緊急）

計画フェイルオーバーは、DR セカンダリが最新まで追従していることを確認後、セカンダリを昇格し、トラフィックを切り替えます。緊急フェイルオーバーでも基本は同様ですが、RPO はネットワーク遅延分の損失があり得ます。

フェイルバックは、新たなプライマリから旧プライマリをセカンダリとして再参加させる流れが実務で安全です。単純な“元戻し”ではなく、降格と再参加の手順を踏みます。

• 計画フェイルオーバーの前提: レプリケーション遅延が極小（DR ステータスで確認）。
• 昇格後: DNS/ロードバランサの切替、クライアントと CI/CD のターゲット更新。
• 旧プライマリの取り扱い: demote 後に、新プライマリのセカンダリとして再構成。
• ロールバック: 新プライマリの健全性を監視し、問題があれば逆方向に同様の手順。
• 監査: 操作ログ（audit device）で昇格/降格イベントを記録・保全。

フェイルオーバー/フェイルバックの代表コマンド

# 1) 計画フェイルオーバー（Secondary を昇格）
export VAULT_ADDR=https://secondary.example.com:8200
export VAULT_TOKEN=<admin_token_on_secondary>
# 昇格（promote）
vault write -f sys/replication/dr/secondary/promote

# 2) 旧プライマリを降格（demote）して再参加準備
export VAULT_ADDR=https://old-primary.example.com:8200
export VAULT_TOKEN=<admin_token_on_old_primary>
# 降格
yes | vault write -f sys/replication/dr/primary/demote

# 3) 新プライマリでセカンダリ用トークンを再発行し、旧プライマリで更新
export VAULT_ADDR=https://new-primary.example.com:8200
export VAULT_TOKEN=<admin_token_on_new_primary>
NEW_TOKEN=$(vault write -field=token -f sys/replication/dr/primary/secondary-token)

export VAULT_ADDR=https://old-primary.example.com:8200
export VAULT_TOKEN=<admin_token_on_old_primary>
# 新プライマリを指すよう更新（enable ではなく update-primary を使用）
vault write sys/replication/dr/secondary/update-primary \
  token="$NEW_TOKEN" \
  primary_api_addr="https://new-primary.example.com:8200"

# 4) 双方でステータス確認
vault read sys/replication/dr/status

監視・演習・セキュリティの勘所

監視は、レプリケーションの健全性（状態、ラグ、接続エラー）と、証明書/時刻同期の健全性が中心です。Prometheus 形式のメトリクス出力を収集し、しきい値でアラート化します。

演習は、計画フェイルオーバー→フェイルバックを定期的に実施し、RTO の実測と手順書の鮮度を保つことが重要です。スナップショット取得は DR の代替ではありませんが、障害解析や最悪時の復旧に有用です。

• 状態取得: vault read sys/replication/dr/status（mode/state/known secondaries 等）を定期収集。
• メトリクス: /sys/metrics?format=prometheus をスクレイプ（ネットワーク/証明書に注意）。
• 監査: audit device を両クラスタで有効化し、昇格/降格を追跡可能に。
• 証明書: 期限アラート、CA 変更のロールオーバープランを用意。
• バックアップ: Raft スナップショットは DR の補助として定期取得。

監視とバックアップの実用スニペット

# DR ステータス（JSON 出力）
vault read -format=json sys/replication/dr/status | jq .

# Prometheus メトリクス（要適切なトークン/ヘッダ設定）
curl -s -H "X-Vault-Token: $VAULT_TOKEN" \
  "$VAULT_ADDR/v1/sys/metrics?format=prometheus" | grep replication

# Raft スナップショット（補助バックアップ）
vault operator raft snapshot save /backup/vault-$(date +%Y%m%d%H%M%S).snap

DR と Performance の違い（試験頻出の落とし穴）

DR は災害復旧のための待機系、Performance は読み取りスケールのための分散系です。設計目的が異なるため、クライアントの可用性、書き込み可否、切替操作が根本的に違います。

試験では、セカンダリが平常時にリクエストを処理できるか、どの操作が昇格なのか、といった設問がよく出ます。下表で差分を明確にしておきましょう。

• DR Secondary は昇格までクライアント要求を処理しない。
• Performance Secondary は読み取りを提供するが、書き込みはプライマリへプロキシする。
• 切替操作: DR は secondary/promote、Performance は通常不要（トポロジ維持）。

（参考）Performance レプリケーション有効化の最小例

# Primary で Performance Primary を有効化
vault write -f sys/replication/performance/primary/enable

# Secondary 用トークンを生成
P_TOKEN=$(vault write -field=token -f sys/replication/performance/primary/secondary-token)

# 別クラスタで Performance Secondary を有効化
vault write sys/replication/performance/secondary/enable \
  token="$P_TOKEN" \
  primary_api_addr="https://primary.example.com:8200"

問題で確認

よくある質問