Vault Storage Backends の概要: 選択肢と整合性を軸にした運用判断

Vault の可用性や障害時のふるまいは Storage Backend に大きく依存します。特に Ops 観点では、整合性モデルを理解したうえで、組織の運用標準に合う選択が要です。

本記事は公式ドキュメントの安定的な挙動に基づき、実務と資格対策の両立を意識して、Integrated Storage (Raft) と Consul の現実的な比較・設計ポイントを解説します。

Storage Backend の役割と前提整理

Vault は暗号化済みの状態でデータを Storage Backend に保存します。対象はシークレット、トークン、リース、認証情報、メタデータなどです。Storage の選定は、耐久性・整合性・可用性・運用コストに直結します。

本番用途では高可用性と強整合を満たすバックエンドが必要です。現行の推奨は主に Integrated Storage (Raft) または Consul です。旧来の一部バックエンドは非推奨やサポート縮小の対象が含まれるため、新規構築では避けるのが無難です。

• Vault 自体がデータを暗号化し、Storage 側は暗号文を保持
• HA ロックとリーダー選出により一貫した書き込み経路を確保
• バックアップ手段はバックエンドごとに異なる（Raft スナップショット、Consul スナップショットなど）
• ネットワーク分断時の挙動は整合性モデルに依存。設計段階でクォーラム要件を明確化

選択肢の全体像と推奨シナリオ

Integrated Storage (Raft) は Vault プロセス内に組み込まれた Raft により強整合とシンプルな運用を提供します。外部依存を減らしたい、クラスタを自己完結させたい場合に適します。

Consul は成熟したサービスメッシュ/サービスディスカバリの一部として KV ストアを持ち、Vault のストレージとして長く実績があります。すでに信頼できる Consul 運用基盤があり、チームがノウハウを持つなら依然として有力です。

• 新規構築で外部依存を最小化するなら Integrated Storage
• 既存の安定した Consul 基盤があるなら Consul
• 旧来バックエンドは長期運用・サポート観点から新規採用を避ける判断が安全

整合性モデルを設計に落とし込む

Raft は単一リーダー方式でログレプリケーションを行い、過半数の合意でコミットします。これにより書き込みは常に強整合を維持します。読み取りもリーダーまたはコミット済みインデックスに基づき強整合です。

Consul も内部で Raft を用い、Vault からの書き込みは強整合です。読み出しの一部で整合性/遅延のトレードオフが設定可能ですが、Vault はデータ競合を避けるため強整合パスを前提とするのが一般的です。設計では、クォーラム成立に必要なノード数、ネットワーク分断時の振る舞い、読み取りの一貫性を明示します。

• N 台構成時のクォーラムは 過半数（floor(N/2)+1）
• ネットワーク分断時は少数派で書き込み不可（強整合の代償）
• 遅延が大きいリージョン間で単一クラスタを引き伸ばさない（クォーラム不安定化）
• 読み取り性能を上げるにはノード数・CPU・IOPS・ネットワークの総合設計が必要

Vault クラスタ（Raft）の整合性とクォーラム

               ┌────────────────┐
               │   Client Write │
               └───────┬────────┘
                       │
                  +────▼────+
                  │ Leader  │  Node A
                  +────┬────+
           AppendEntries│
     ┌──────────────────┼──────────────────┐
 +───▼────+         +───▼────+         +───▼────+
 │Follower│         │Follower│         │Follower│
 │ Node B │         │ Node C │         │ Node D │
 +────────+         +────────+         +────────+
     │                   │                  │
     └────── ack ────────┴────── ack ───────┘
             Quorum reached -> commit

可用性と運用設計の要点

可用性は単にノード数を増やせば良いわけではなく、クォーラムと障害ドメイン（AZ/ラック）を意識した配置が必要です。ストレージ IO の安定性はレイテンシ増大やリーダー交代の誘発要因になるため、特に重視します。

バックアップはバックエンドに合わせて準備します。Integrated Storage は Vault の Raft スナップショット、Consul は Consul のスナップショット機能が基本です。復元手順は定期的にリハーサルし、復旧時間目標とデータ一貫性を検証します。

• 3 ノード以上で奇数台構成（例: 3, 5）。AZ を跨いで配置し独立電源/ネットワークで分散
• Disk/IOPS は安定性重視。書き込み遅延はクラスタ全体のスループットに直結
• 監視は Raft/Consul のヘルス、リーダー、レプリケーション遅延、スナップショット成否まで含める
• 計画停止やアップグレードは一度に 1 ノードずつ。クォーラムを崩さない順序で実施
• DR・クロスリージョンはエンタープライズ機能の利用可否を事前に判断（要件と予算に応じて）

設定例と構成チェックリスト

代表的な server.hcl の例です。実運用では TLS、オートアンシール、監査ログ、リソース制限などを含めて構成します。アドレスやパスは環境に合わせて調整してください。

構成後は、起動前に設定検証、起動後にクラスタヘルス、リーダー、スナップショット取得可否まで確認します。

• 起動前: ストレージパス権限、ディスク空き、ネットワーク到達性、TLS 証明書
• 起動後: リーダー選出、API/Cluster アドレス、スナップショットの取得・復元テスト
• 障害演習: ノード停止・ネットワーク分断・ディスク高遅延を模擬し、SLO を検証

Vault server.hcl の例（Integrated Storage と Consul）

# Integrated Storage (Raft) 例
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = 0
  tls_cert_file = "/etc/vault/tls/tls.crt"
  tls_key_file  = "/etc/vault/tls/tls.key"
}

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
  retry_join {
    leader_api_addr = "https://10.0.0.1:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.2:8200"
  }
}

api_addr     = "https://vault-1.example.local:8200"
cluster_addr = "https://10.0.0.11:8201"

# Consul 例（既存の安定した Consul を利用する場合）
# Consul 側は ACL/TLS/スナップショット設定を適切に
# address はローカルエージェント経由など運用標準に合わせる
#
# storage "consul" {
#   address = "127.0.0.1:8500"
#   path    = "vault/"
#   scheme  = "https"
#   token   = "<consul-acl-token>"
# }

Ops 試験対策ポイントと現場の落とし穴

Ops の設計・運用問題は「整合性と可用性のトレードオフをどう具体化したか」を問われがちです。Storage の選定理由、クォーラム設計、バックアップとリストアの手順、障害時のふるまいを一貫して説明できるように準備します。

試験・実務ともに、開発用バックエンドや単一ノード構成を本番に流用しないこと、ネットワーク分断時の書き込み停止が正しい挙動であることを理解しているかがチェックされます。

• 本番では強整合なバックエンド（Integrated Storage or Consul）を採用
• 奇数台・過半数クォーラム・障害ドメイン分散を明言
• バックアップはバックエンド準拠（Raft スナップショット / Consul スナップショット）で定期検証
• file や inmem は本番非推奨。HA を満たさない
• ネットワーク分断時に少数派が書けないのは設計通り（データ保護）

問題で確認

よくある質問