Vault Performance Standbyで実現する読取スケーラビリティ

Vaultを本番で運用すると、読み取りが圧倒的多数というケースが一般的です。そこで効くのがEnterpriseのPerformance Standby。スタンバイノードが読取系APIを自前で処理し、アクティブノードの負荷を大幅に削減します。

この記事では、Production運用に耐える設計ポイントと、Ops系の資格対策で問われやすい比較・ヘルスチェック・フォワーディング周りの注意点をまとめます。

基礎整理：HAとPerformance Standbyの位置づけ

VaultはHA構成で1台がアクティブ、残りがスタンバイになります。通常スタンバイはリクエストをアクティブへフォワードする役割ですが、EnterpriseではPerformance Standby機能により、読取系の多くをスタンバイ自身が処理可能になります。

これにより、シークレット参照やトークン情報の参照・更新（更新といってもストレージ変更を伴わない性質のもの）が分散され、アクティブのCPU/IOホットスポット化を防げます。書き込み（シークレットの作成・更新・有効化/無効化・ポリシー変更など）は引き続きアクティブが一元処理します。

• 対象: Vault Enterpriseの単一クラスタ内での読取スケール
• 前提: HA対応ストレージ（ConsulまたはRaft/Integrated Storage）と正しいcluster_addr設定
• 目的: 読取の局所処理、アクティブ負荷と待ち時間の低減、スループット向上

リクエスト処理の流れと整合性モデル

Performance Standbyは、対象となる読取系エンドポイントを自ノードで処理します。対象外や整合性上ローカル完了できないものは、リクエストフォワーディングでアクティブへ中継します。適切なcluster_addr/TLSが設定されていれば、クライアントはリダイレクトを意識せず1つのVIPに送るだけで成立します。

整合性は、同一ストレージを共有しつつ、必要に応じて無効化・同期を行う設計です。直前に行われた書き込み直後の読み取りなど、タイミング次第では安全側に倒してアクティブへフォワードされることがあります。これは観測されるデータの一貫性を優先するための挙動です。

• 読取対象の代表例: シークレットの読み取り/一覧、一部のトークン/リースの参照・更新（ストレージ変更を伴わない範囲）
• 対象外の代表例: システム設定変更、ポリシー/エンジン有効化・ローテーション、明示的な書き込み系
• クライアント側はLBの単一点終端でOK。内部でスタンバイがローカル完結 or フォワードを選択

Performance Standbyのリクエスト経路（単一クラスタ）

機能の使い分け：Standard Standby / Performance Standby / Performance Replication

似た用語が多いため、Ops視点での使い分けを整理します。単一クラスタ内の読取スケールはPerformance Standby。マルチクラスタでリージョン間レイテンシとスループットを最適化したいならPerformance Replication Secondary（別クラスタ）。スタンダードなスタンバイは基本的にフォワーダです。

DR Replicationは復旧目的であって、通常の読取分散とは目的が異なります。本記事の主眼はあくまでクラスタ内の読取スケール（Performance Standby）です。

• 単一クラスタの読取スケール → Performance Standby
• リージョン分散・近接読取 → Performance Replication Secondary
• 単純HAでよい/小規模 → Standard Standbyでも可（ただし読取はフォワード中心）

導入と設定：cluster_addr・LB・ヘルスチェック

最重要はリクエストフォワーディングを正しく動かす基盤設定です。各ノードのcluster_addrとTLSを正しく揃え、ノード間で相互到達・証明書検証が成立するようにします。これが欠けると、スタンバイがフォワードできず、クライアントはリダイレクトに巻き込まれます。

LBは単一VIPに全ノード（アクティブ＋スタンバイ）をぶら下げる設計が実務で扱いやすいです。ヘルスチェックは/sys/healthにstandbyok=trueとperfstandbyok=trueを付けて、スタンバイやPerformance Standbyも“健全”とみなすのが定石です。書き込みはスタンバイに当たっても内部フォワードされるため、クライアント側での経路分離は必須ではありません。

• cluster_addrとapi_addrを全ノードで適切に設定（SAN含むTLS整合）
• LBヘルスチェック例: /v1/sys/health?standbyok=true&perfstandbyok=true
• EnterpriseではPerformance Standbyは既定で有効。無効化が必要ならサーバ設定で明示的にオフ

例: Integrated Storageを使う最小構成（抜粋）

# /etc/vault.d/server.hcl
api_addr    = "https://vault.example.com:8200"
cluster_addr = "https://10.0.0.1:8201"
disable_mlock = true

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/tls/server.crt"
  tls_key_file  = "/etc/vault/tls/server.key"
}

# EnterpriseではPerformance Standbyは既定で有効
# 無効化したい場合のみ:
# disable_performance_standby = true

運用：監視・テスト・キャパシティの考え方

監視では、ノードの役割（active/performance standby）と、リクエストがローカル処理かフォワードかの割合を追いかけます。Prometheus等のテレメトリでエンドポイント別の応答時間分布とフォワード比率を採ると、ボトルネックと効果測定がしやすくなります。

負荷試験は“読取9:書込1”のような実態に近い比率で行い、LBを介した実配線で遅延・スループットを確認します。アクティブ停止のフェイルオーバ試験では、スタンバイ昇格後の暖機（キャッシュ無効化/再収束）による一時的な遅延スパイクも計測対象に入れると良いです。

• 可観測性: ローカル処理/フォワード比、p95/p99レイテンシ、エラー率、sys/healthの状態推移
• テスト: 実LB経由、読取主導のワークロード、アクティブ切替の影響を測定
• キャパシティ: ノード数とvCPU/メモリは読取集中を前提にサイジング。スケールアウトで段階的に検証

試験対策チェックリスト（Ops）

Performance Standbyは“単一クラスタ内の読取スケール”という一言で要点を思い出せるように。関連機能との境界と、LB/ヘルスチェック/フォワーディングの基本を押さえておくと得点に直結します。

• Performance Standby: 読取の多くをスタンバイで処理。書き込みはアクティブで一元処理
• リクエストフォワーディングにはcluster_addrと正しいTLSが必須
• LBヘルスチェックは/sys/health?standbyok=true&perfstandbyok=trueを利用
• Standard Standbyは基本フォワーダ。Performance Replicationは別クラスタでの読取最適化
• 機能の目的がDRではない点に注意（DR Replicationは別目的）
• アクティブ障害時はスタンバイが昇格。クライアントはVIPに送るだけで透過的に継続

問題で確認

よくある質問