HashiCorp VaultにおけるPerformance Limits: スループットと上限をOps視点で押さえる

Vaultは各リクエストで認証・ポリシー評価・暗号処理・ストレージI/O・監査出力を行います。どこが律速になるかを把握しないと、台数を増やしてもスループットが伸びません。

本稿は、公式ドキュメントに基づく安定した概念を前提に、Ops試験で狙われやすい観点と、現場で実際に効く設計・設定の落としどころをまとめます。Enterprise専用機能（Performance Replication、Quotas、Namespacesなど）はその旨を明記します。

スループットを決める基本要素と典型的ボトルネック

Vaultの1リクエストは概ね、フロントのTLS終端 → 認証/トークン検証 → ポリシー評価 → シークレットエンジンや認証メソッドの処理 → バリア下のストレージI/O → 監査ログ出力、という経路をたどります。スループット上限は最も遅い段階で決まります。

典型的な律速要素は次の通りです。暗号処理（TransitやPKIの署名/暗号化）、ストレージのfsync遅延（RaftやConsulへの書き込み）、監査デバイスのI/O（auditは同期書き込み）、外部クラウドAPIの応答待ち（AWS/GCP/DB動的クレデンシャル）、ネットワーク遅延（LBやリージョン間）です。OSSのスタンバイは多くの操作をアクティブに転送するため、読取りの拡張性は限定的です。

• CPUバウンド: Transit/PKIはCPUコア数と命令セット（AES-NI等）の恩恵を強く受ける
• I/Oバウンド: 監査ログの遅延は即スループット低下に直結（同期書き込み）
• 外部依存: 動的シークレットは先方APIのレート制限・遅延が支配的になりやすい

ストレージ選択とレプリケーションの上限感

ストレージとレプリケーション設計は、上限とスループットの“伸びしろ”を左右します。Integrated Storage（Raft）は外部依存がなく、一貫性の高い性能を得やすい一方、fsyncの遅延が直撃します。Consulストレージは成熟した選択肢ですが、ネットワークとConsulクラスタの調律がVaultのレイテンシに反映されます。

Vault EnterpriseのPerformance Replicationはグローバルに読み取りレイテンシを下げる主要手段です（書き込みはプライマリに集約）。DR Replicationはフェイルオーバー目的で、通常の読み取り分散には使いません。Raft/Consulいずれも推奨の投票ノード数は3〜5で、過剰な多数による合意コスト増は避けます。

• ディスクは低レイテンシなローカルSSDを基本線に（fsyncの安定化）
• 監査デバイスはアプリデータと分離し、書き込み待ちで本体が詰まらない構成に
• リージョン間で“書き込みを増やして伸ばす”のは非現実的。読む場所を増やす（Performance Replication）発想が安全

リクエストレート、クォータ、バックプレッシャ

Vaultは既定では受けたリクエストを可能な限り速く処理します。突発的なバーストや誤設定により、CPUや監査I/Oが飽和するとテールレイテンシが悪化します。制御手段として、EnterpriseにはRate Limit QuotasとLease Count Quotas（/sys/quotas）があります。これらはパスやネームスペース単位でレートや総リース数を抑制し、意図しない増加を防ぎます。

OSSの場合は、リバースプロキシでのレート制限、クライアント側の指数バックオフ、TransitのバッチAPI活用など、周辺でのバックプレッシャ設計が要点になります。トークン/リース更新の嵐(renew storm)を避けるため、TTLの設計(default/max)とperiodicトークンの活用も効果的です。

• Enterprise: /sys/quotas/rate-limit でレートを、/sys/quotas/lease-count で総リース数を制限
• OSS: LBでのレート制限と、Transitのbatch_inputでの同時処理最適化
• Renew trafficは控えめに。長すぎるTTLはセキュリティ低下、短すぎるTTLは更新過多のトレードオフ

エンジン/認証方式ごとのスループット特性

KV v2はバージョニングによりメタデータ更新が加わるため、ライト集中ワークロードではmax_versionsの調整や定期的なコンパクション/削除計画が必要です。読み取り中心ならキャッシュ（アプリ側）とTTLの設計が効きます。

Transitは計算中心のためCPUコア数と暗号アルゴリズム選択が支配的です。楕円曲線（例: ECDSA/Ed25519）はRSAより高速になりやすく、batch_inputでの一括処理がスループットを伸ばします。PKIはCAキーの種類と鍵長に比例して重くなります。動的シークレット（AWS/GCP/DB）は先方APIのレート制限/遅延が上限を決めるケースが多く、必要に応じてTTLを短くしてキャッシュを抑制するか、逆にTTLを延ばして発行頻度を下げるかを選びます。

• Transit高速化: EC系キー採用 + batch_input活用 + 十分なCPUコア
• KV v2: 版数と削除運用を明示。不要なバージョンをため込まない
• 動的シークレット: 先方APIのレート制限を前提に、発行頻度をTTLでコントロール

ノード構成とスケールパターン

基本形はアクティブ1 + スタンバイNです。OSSのスタンバイは多くの操作をアクティブに転送します。EnterpriseのPerformanceスタンバイは読み取りの多いワークロードをローカルでさばけるため、読む場所を増やしてスケールさせます。書き込みは引き続きアクティブ（プライマリ）に集約されます。

グローバル分散は、EnterpriseのPerformance Replicationで各リージョンにセカンダリを配置して読み取りを近づけるのが定石です。コンテナ配備では、実効コア数に合わせたGOMAXPROCS（Goランタイムのスレッド上限）調整や、LBのヘルスチェック/接続プーリングが実効スループットに響きます。

• LBはアクティブ/スタンバイの昇格に即応できるヘルスチェックと最短TTLのDNSを
• 監査ログは専用ディスク/デバイスに分離。ここが詰まると全体の処理速度が落ちる
• ネットワークは低遅延・高PPSを優先（小さな応答を高頻度で返す特性のため）

典型的なEnterprise構成とスループット経路（読み取り分散）

上限設定と安全なチューニング手順

TTLはdefault_lease_ttlとmax_lease_ttl（グローバルおよび各マウントのtune）で制御します。短すぎるTTLはrenewトラフィックを増やし、長すぎるTTLはセキュリティとリーク時の影響範囲を広げます。periodicトークンは定期更新で長寿命を実現できますが、max_ttlの上限は守られます。

監査は同期書き込みです。遅い監査デバイスやネットワークファイルシステムはスループット低下の原因になります。高速なローカルディスクやシステムロガーを選択し、OSのファイルディスクリプタ上限（ulimit）を十分に確保します。

HTTPボディサイズや同時接続の制限は、多くの場合LB/リバースプロキシ側の設定に依存します。Vaultの前段で制限を適切に設け、クライアントのリトライ・バックオフを組み合わせて全体最適を図ります。

• 変更は段階適用 → 可観測性で確認（メトリクス/ログ/プロファイル）
• Transitの負荷試験はbatch_inputを使い現実的な1リクエスト多件処理を再現
• 障害注入（遅い監査/ストレージ）でボトルネックの当たりを付けてから増設

実務で使う最小構成例（Raft + TTL調整 + 監査 + Telemetry）とEnterprise Quotas/Transitバッチの例

# vault.hcl (抜粋)
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 0
  # 既定のTLS終端。LBと責務を分ける場合は相応に調整
}

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

api_addr     = "https://vault.example.com:8200"
cluster_addr = "https://10.0.0.10:8201"

# TTLはグローバル既定。個別マウントで上書き可能
default_lease_ttl = "1h"
max_lease_ttl     = "24h"

# 監査（ローカル高速ディスク推奨）
audit "file" {
  path = "/var/log/vault/audit.log"
  log_raw = true
}

# Telemetry（Prometheusスクレイプ）
telemetry {
  prometheus_retention_time = "24h"
}

# --- Enterprise: Quotas の例（CLI） ---
# レート制限（秒間100リクエスト、対象パスprefix）
# vault write sys/quotas/rate-limit/myrl rate=100 path_prefix="transit/"

# リース数上限（最大10万）
# vault write sys/quotas/lease-count/myleasecount max_leases=100000

# --- Transit: batch_input 例（1リクエストで複数暗号化） ---
# curl --header "X-Vault-Token: $TOKEN" \
#      --request POST \
#      --data '{"batch_input": [{"plaintext":"aGVsbG8="},{"plaintext":"d29ybGQ="}]}' \
#      https://vault.example.com/v1/transit/encrypt/mykey

問題で確認

よくある質問