Vault Performance Replication実践ガイド: 負荷分散と水平スケールの作り方

Vaultのスループットが地域ごとに頭打ちになってきた、あるいはリージョンを跨いだ待ち時間がボトルネックになっているなら、Performance Replicationは最有力の選択肢です。

本稿では、試験対策（HashiCorp Security Automation系の出題範囲を意識）と実務の両面から、設計判断、セットアップ、運用・監視、トラブルシュートまでを一気通貫で解説します。

Performance Replicationのねらいと前提

Performance Replicationは、Vault Enterpriseが提供するスケールアウト機能で、読み取りを各リージョンのセカンダリでローカル処理し、書き込みはプライマリで一元適用します。これにより、待ち時間の短縮とスループットの安定化が実現できます。

重要な前提は次の3点です。1) レプリケーションは非同期で行われるため、非常に短い複製遅延は発生し得る。2) セカンダリでの認証・トークンは各クラスターにローカルで、グローバルなセッション共有は行わない。3) 障害時のフェイルオーバーはDR Replicationが担い、Performance Replicationは主にスケールとレイテンシ最適化を目的とする、という役割分担です。

ストレージとしてはConsulまたはIntegrated Storage（Raft）が利用可能ですが、近年は運用単純性と一体運用の観点からIntegrated Storageが推奨される傾向です。

• 読み取りは各Performanceセカンダリでローカル処理
• 書き込みは原則プライマリに適用（セカンダリからの書き込みフォワードが可能）
• 認証・トークン・リースは各クラスターで独立
• 障害復旧はDR Replicationの役割（用途を分ける）

トポロジとデータフロー（読み取り分散と書き込み一貫性）

典型構成は1つのPerformanceプライマリと、地域ごとの複数Performanceセカンダリです。各クラスターは内部で高可用（HA）構成を取り、外部からは地域ごとのロードバランサ経由でアクセスします。

クライアント読み取りは最寄りのセカンダリに到達し、書き込みはセカンダリ経由でプライマリへフォワードされ、プライマリでコミット後に応答します。データは非同期で各セカンダリへ複製されます。短いレプリケーション遅延があるため、厳密なローカルのread-after-write一貫性は保証されません（多くのケースで実用上問題はありませんが、要件が厳しい場合は設計で緩和策を取ります）。

ネットワーク要件として、クラスター間のレプリケーションはVaultのclusterアドレス（標準ではTCP 8201/TLS）で疎通が必要です。APIアクセス（8200/TLS）はクライアントとロードバランサに対して公開します。

• 各クラスターはHA（Active + Standby）で構成
• LBのヘルスチェックは /v1/sys/health を活用（performance-standby-ok=true を適用しスタンバイも許可可能）
• クラスター間はTLS相互接続を前提（CAの配布・検証を徹底）

グローバルPerformance Replicationの概念図

モード比較と設計判断（Performance/DR/単一クラスタ）

スケール・可用性・運用コストのバランスを取るには、Replicationモードの役割を正しく理解することが近道です。Performanceはレイテンシ短縮と読み取りスループットのため、DRは災害復旧のため、と覚えておくと試験でも迷いません。

以下の比較表は、要件整理の初期段階で有用です。

• 厳密なRTO/RPO要件があるならDR Replicationを併用
• グローバル読み取り最適化はPerformance Replicationが中心
• トークンとリースは各クラスターで独立(グローバル共有しない)

最小構成のセットアップ手順（CLI中心）

ここでは既にプライマリ/セカンダリともにVault Enterpriseが初期化・アンシール済みで、TLS設定も完了している前提です。ストレージはIntegrated Storage（Raft）例で説明します。

セカンダリ登録はワンタイムのアクティベーション・トークンで行い、登録後にバックグラウンドでフル同期が走ります。

• プライマリでPerformance Replicationを有効化
• セカンダリ用トークンを発行（IDで識別管理）
• セカンダリ側で有効化と参加
• 同期とステータスの確認
• LBのヘルスチェック更新（standby許可の要否を確認）

CLI例: 有効化からステータス確認まで

# 1) プライマリでPerformance Replicationを有効化
vault write -f sys/replication/performance/primary/enable

# 2) セカンダリ参加用のワンタイム・トークンを生成（識別子を付与）
vault write sys/replication/performance/primary/secondary-token id="sec-eu-001"
# 出力の token フィールドを控える（単回使用）

# 3) セカンダリでPerformance Replicationを有効化（プライマリ発行のトークンを利用）
vault write sys/replication/performance/secondary/enable token="s.xxxxx..."

# 4) ステータス確認（両側で確認すると安心）
vault read sys/replication/status
vault read sys/replication/performance/status

# 5) （任意）Integrated Storageのスナップショット取得（退避・検証用）
#   運用上は定期取得と安全な保管が推奨
vault operator raft snapshot save /tmp/vault_raft.snap

運用の勘所（LB、認証、書き込みフォワード、バックアップ）

LB設計: 各リージョンのLBはアクティブノードを優先しつつ、必要に応じてperformance-standby-ok=trueでスタンバイも可とするヘルスチェックを使います。クラスター障害時に他リージョンへ振り向けるポリシーは、Performance単独ではなくDRと組み合わせるのが定石です。

認証・トークン: 各クラスターで独立運用されます。ユーザー/アプリは最寄りのセカンダリでログインし、得たトークンはそのクラスター内でのみ有効です。グローバル共通トークン前提の設計は避けます。

書き込みフォワード: セカンダリに対する書き込み要求はプライマリへフォワードされ、プライマリでコミット後に応答します。返答成功後も、セカンダリへの反映にはわずかな遅延があり得る点を、APIクライアントのリトライや整合性要件に織り込みます。

• LBヘルスチェック: /v1/sys/health?performance-standby-ok=true
• ポート: API 8200/TLS、Cluster 8201/TLS（相互接続）
• トークン/リースはクラスター単位で閉じる設計
• バックアップは別途必須（スナップショットの定期取得）

ヘルスチェック例（curl）とスナップショット

# LBヘルスチェック（スタンバイ許容）
curl -sS "https://vault-eu.example.com:8200/v1/sys/health?standbycode=200&performance-standby-ok=true" -o /dev/null -w "%{http_code}\n"

# Raftスナップショット保存（要認証）
vault login s.xxxxx...
vault operator raft snapshot save /backups/vault-`date +%F`.snap

試験対策ポイントとトラブルシュート

試験対策: Performanceはスケール用、DRはフェイルオーバー用。トークン/リースはクラスターごと。セカンダリ書き込みはフォワードでプライマリに適用。この3点をまず落とさないこと。

初期同期が進まない、遅延が解消しないといった相談はネットワーク/TLS/時刻同期が原因のことが多いです。基本の疎通、証明書チェーン、NTPを確認してから深掘りします。

• 確認コマンド: vault read sys/replication/status
• 疎通: 8201/TLSがクラスター間で双方向に到達するか
• 証明書: SANにclusterアドレスが含まれているか
• 時刻同期: NTPずれはTLS検証やTTLに影響
• レプリケーション遅延: 負荷（WAL/キュー）と帯域の相関を監視

基本ステータスとヘルスのチェック

# レプリケーションの状態
vault read sys/replication/status
vault read sys/replication/performance/status

# ヘルスチェック（プライマリ/セカンダリで）
curl -sS https://vault-primary.example.com:8200/v1/sys/health | jq .
curl -sS "https://vault-eu.example.com:8200/v1/sys/health?performance-standby-ok=true" | jq .

問題で確認

よくある質問