HashiCorp Vault の HA クラスタ構成を運用目線で整理: Active/Standby の役割

Vault を本番運用するなら、Active/Standby の役割と振る舞いを正確に押さえることが第一歩です。本稿では公式ドキュメントの安定概念に基づき、Ops 目線で要点を詰め込みました。

資格対策としては、Active が唯一の書き込み点であること、Standby のリクエスト取り扱い、ヘルスチェックの使い分け、フェイルオーバー時の挙動と手順化が頻出です。

Active/Standby の基本と HA 構成の全体像

Vault の HA クラスタでは、常に 1 台が Active（リーダー）となり、書き込みを一手に引き受けます。残りは Standby として待機し、Active の状態を監視しながら追従します。障害時には多数決（クォーラム）で新しい Active が選出されます。

Standby は基本的にクライアント要求を Active へリダイレクト（またはフォワード）します。Enterprise では Performance Standby を追加でき、読み取り系の処理や一部の API をローカルで高速に処理できます（書き込みは依然として Active のみ）。

• Active: 唯一の書き込み点。クラスタ全体の状態変更を担う。
• Standby: Active の監視と待機。要求を Active へ中継または転送。
• Performance Standby（Enterprise）: 読み取りのスケールアウト用。
• HA ストレージ: Integrated Storage（Raft）または Consul を用いる設計が一般的。

Vault HA（Active/Standby）概念図

代表的な状態確認コマンド（抜粋）

# 現在のリーダー確認
curl -s http://vault.service:8200/v1/sys/leader | jq .

# Raft ピアの確認（Integrated Storage 使用時）
vault operator raft list-peers

# ステップダウン（計画メンテ時など）
vault operator step-down

リクエスト処理の流れとヘルスチェック設計

クライアントが Standby に到達した場合、Vault はリダイレクト（または要求の転送）で Active に処理を集約します。アプリが再試行やリダイレクトを扱えない場合は、ロードバランサ側で Active のみを選別するのが定石です。

ヘルスチェックには /v1/sys/health や /v1/sys/leader を使います。特に /v1/sys/health はクエリパラメータで挙動を制御でき、Active のみを UP とみなすか、Standby も許容するかを切り替えられます。スタンバイを許容すると可用性は高まりますが、クライアントが転送/再試行に耐えられる設計が前提です。

• Active のみを通す: /v1/sys/health で Standby を UP とみなさない設定を使用。
• Standby も許容: リクエストフォワーディングを有効化し、LB は全ノードを振り分け対象に。
• ヘルス/リーダー API は監視・自動化（フェイルオーバー検知）にも活用できる。

ヘルスとリーダー確認の具体例

# Active のみを UP とみなす（例）
curl -sf http://vault.service:8200/v1/sys/health

# Standby を許容したヘルス確認（例）
# standbyok=true 等のパラメータで許容範囲を広げられる
curl -sf "http://vault.service:8200/v1/sys/health?standbyok=true"

# リーダー情報（転送先 URL の把握に有用）
curl -s http://vault.service:8200/v1/sys/leader | jq '{ha_enabled, is_self, leader_address}'

フェイルオーバーの流れと選出の考え方

Active が応答不能になると、Standby 間で選挙が行われ、新しい Active が選出されます。選出には過半数（クォーラム）の到達が必要です。これはストレージの整合性を守るための前提で、ノード数は奇数配置（3, 5, 7 ...）が推奨されます。

計画メンテナンスでは、手動でリーダーを降格（step-down）し、Standby へ役割を移してから作業すると中断時間を抑えられます。選挙やログ適用の収束時間はネットワーク遅延や負荷に左右されるため、SLO を満たすように監視と待機手順を標準化しましょう。

• クォーラム確保のため、偶数構成より奇数構成が推奨。
• 計画停止は step-down → LB 切替 → 作業 → 復帰の順で安全に。
• 監視はリーダー API とストレージの健全性を併用。

フェイルオーバー運用に使う代表コマンド

# 計画フェイルオーバー（リーダー降格）
vault operator step-down

# Raft ピアの健全性（到達性/投票権の確認に）
vault operator raft list-peers

# 最新ログ適用状況（例: 監視/点検での参照）
vault operator raft snapshot save /tmp/vault.snap

構成パターン: Integrated Storage（Raft）と Consul

現行の推奨は Integrated Storage（Raft）です。外部依存を減らし、自己完結した HA を構成できます。リーダー選出も内蔵の Raft が担い、シンプルな構成で高信頼を実現できます。

一方、既存で Consul を標準化している環境では、storage に Consul を用いる構成も引き続き有効です。ネットワーク設計や障害ドメインの分離方針に合わせて選択します。

• Integrated Storage: 依存が少なく構築・運用が簡素化されやすい。
• Consul: 既設のサービスメッシュ/カタログとの統合が容易。
• どちらの方式でも Active/Standby の基本は同じ（書き込みは Active のみ）。

Vault サーバ設定例（Raft と Consul の比較）

# Raft（Integrated Storage）例
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}
api_addr = "http://vault-node1:8200"
cluster_addr = "http://vault-node1:8201"
storage "raft" {
  path = "/opt/vault/data"
  # retry_join 等でピア合流を設定可能
  # retry_join { leader_api_addr = "http://vault-nodeA:8200" }
}

# Consul 例（既存 Consul を利用する場合）
# storage "consul" {
#   address = "consul.service:8500"
#   path    = "vault/"
# }

ロードバランサ設計とローリングアップグレード手順

クライアントがリダイレクトや再試行に未対応なら、LB は Active のみを通す設計が安全です。ヘルスチェックで Standby を除外し、Active が交代したらすぐに新 Active に切り替えるようにします。リクエストフォワーディングを活用する場合は、LB は全ノードを均等配分しても実質的に Active へ集約されます。

ローリングアップグレードは Standby から順に行い、最後に Active を step-down して更新します。各ステップでヘルス・リーダー・機能テストを挟み、SLO/ウィンドウ内に収まることを確認してください。

• LB 健全性判定は /v1/sys/health を活用（Active 限定 or Standby 許容）。
• アップグレード順: Standby → Standby → Active(step-down) の流れが基本。
• 自動化: ヘルス安定待ち、エラーバジェット監視、ロールバック手順を事前定義。

HAProxy による Active のみ通過させる例（概略）

backend vault
  option httpchk GET /v1/sys/health
  http-check expect status 200
  server node1 vault-node1:8200 check
  server node2 vault-node2:8200 check
  server node3 vault-node3:8200 check

# 備考: 200 を Active の指標として扱う想定（環境に合わせて調整）

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

書き込みは常に Active のみ。Standby は転送/中継するか、Enterprise の Performance Standby で一部読み取りをさばく、という役割分担をまず暗記してください。DR レプリケーション（プライマリ/セカンダリ）と HA（Active/Standby）は別概念で、出題で混同させるパターンに注意。

ノードは初期化とアンシールを済ませないとクラスタに正常参加できません。自動アンシールの採用、アンシールキーの厳格運用、リーダー降格とアップグレードの標準手順化は、運用・試験の双方で頻出の論点です。

• Active は唯一の書き込み点。Standby は転送主体。
• LB 設計: リダイレクト不可なら Active のみ通過。可なら転送を活用。
• DR と HA を混同しない（試験のひっかけ）。

試験準備でよく使うコマンド（ラボ環境）

# 初期化（ラボ用途の例。実運用では閾値設計/自動アンシール推奨）
vault operator init -key-shares=1 -key-threshold=1

# アンシール（複数回実行して閾値に達する）
vault operator unseal

# ステータス確認
vault status

問題で確認

よくある質問