Vault Integrated Storage (Raft) の推奨構成と特徴：Ops試験・実務で外せない要点

VaultのIntegrated StorageはRaftベースの内蔵ストレージで、外部のキー・バリューストア無しでHAを実現します。小中規模〜標準的な構成では第一選択肢になり得ます。

Ops観点では、奇数ノードの配置、アドレス(api_addr/cluster_addr)の整合、スナップショット運用、障害時のクォーラム復旧フローが頻出論点です。

Raft統合ストレージの概要と選定基準

Integrated Storage (Raft) はVaultプロセスに内蔵された分散ログ複製エンジンです。リーダーが書き込みを直列化し、フォロワーへレプリケーションすることで一貫性を担保します。外部のConsulなどに依存しないため、構成要素が少なくデプロイが容易です。

選定の考えどころは「外部依存を減らしたい」「標準的な可用性(3または5ノード)を確保したい」「データセンター内での低レイテンシ通信が見込める」ケースです。多目的KVとしてConsulを既に運用しているならConsulバックエンドも候補になりますが、新規にVault専用で組むならRaftが実務的にシンプルです。

• HA要件: 奇数ノード(3または5)でクォーラムを満たす
• ネットワーク: 低レイテンシ(同一リージョン/AZ間)推奨
• ストレージ: 永続ディスク、fsync保証、十分なIOPS
• 外部依存: 追加のKVクラスター不要(Consul不要)
• 資格試験の狙い目: api_addrとcluster_addrの違い、奇数ノード原則、スナップショットの取得/復元手順

推奨トポロジとネットワーク設計

基本は同一リージョン内の複数AZに3ノード分散です。5ノードはより高可用ですがコストとレイテンシが上がります。コントロールプレーン(クラスタ通信: 8201/TCP)はノード間で相互到達、データプレーン(API: 8200/TCP)はクライアント/LBから到達可能にします。

クォーラムは3ノードなら2、5ノードなら3が必要です。ノードは同一のVaultバージョンで揃え、時刻同期(NTP)とTLSを必須化します。APIアドレス(api_addr)はクライアント向け、クラスタアドレス(cluster_addr)はRaftピア間で使用される点を混同しないことが重要です。

• ノード数: 3(標準) or 5(高可用)。2は非推奨(クォーラム喪失リスク)
• AZ配置: 分散(例: 3AZで各1台)、LBはAPI(8200)のヘルスチェックを使用
• ポート: 8200(API)と8201(クラスタ)を双方向許可
• ディスク: 永続ブロックストレージ、障害時のアタッチ切替要件も考慮
• 証明書: SANにapi_addr/cluster_addrのFQDN/IPを含める

3ノードRaftクラスタ (3 AZ, LB経由アクセス)

代表的な設定例と初期化フロー

設定はserver.hclでapi_addr/cluster_addr、listener(8200/8201, TLS)、storage "raft"(path、node_id、retry_join)を定義します。初期化は最初のノードでvault operator init、以降のノードはvault operator raft joinで参加します。

join後はunsealを行い、peersが揃っていることを確認します。スナップショットはリーダーから取得するのが安全です。

• 1台目: init→unseal→ポリシー/認証方式の最小設定
• 2台目以降: raft join→unseal→peer確認
• 検証: vault operator raft list-peers と sys/health
• 注意: api_addrはクライアント/LBから到達可能な可用アドレス、cluster_addrはピア間で解決可能なアドレス

Vault server.hcl (Raft) と初期化コマンド例

# /etc/vault.d/server.hcl
ui = true
api_addr    = "https://vault-1.example.com:8200"
cluster_addr= "https://vault-1.example.com:8201"

listener "tcp" {
  address         = "0.0.0.0:8200"
  tls_disable     = 0
  tls_cert_file   = "/etc/vault.d/certs/vault.crt"
  tls_key_file    = "/etc/vault.d/certs/vault.key"
}

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
  # 複数エントリ可。いずれかのリーダーに到達できれば自動参加を試行
  retry_join {
    leader_api_addr = "https://vault-1.example.com:8200"
    # tls_servername や ca_cert_file などを必要に応じて指定
  }
  retry_join {
    leader_api_addr = "https://vault-2.example.com:8200"
  }
}

# 初期化(1台目)
$ export VAULT_ADDR=https://vault-1.example.com:8200
$ export VAULT_CACERT=/etc/vault.d/certs/ca.crt
$ vault operator init -key-shares=5 -key-threshold=3 > init.txt
$ vault operator unseal  # しきい値回数実施

# 2台目以降(例: vault-2)
$ export VAULT_ADDR=https://vault-2.example.com:8200
$ vault operator raft join https://vault-1.example.com:8200
$ vault operator unseal

# ピア確認(どのノードでも)
$ vault operator raft list-peers

可用性・パフォーマンス設計の勘所

Raftは強整合リーダー方式です。書き込みはリーダーで受け付け、過半数にレプリケートされてコミットされます。スタンバイはリクエストをリーダーへ転送します。したがって、リーダーと各ピア間のレイテンシがスループットと待ち時間に直結します。

スナップショットはログ肥大化を防ぎ、再起動や再参加時の復元時間を短縮します。高IOPS/低レイテンシの永続ディスクを選び、CPU/メモリはワークロード(トークン発行・暗号操作)に見合うように見積もります。

• 奇数ノードでのクォーラム維持が最優先(3/5構成)
• リーダーの所在を観測し、LBはヘルスチェックでスタンバイへも疎通可とする
• スナップショットしきい値と保持数を計画し、夜間や負荷低い時間帯に取得
• ディスクは書き込み整合性(fsync)が保証されるクラスを選択
• 監視: Raftのピア数、レプリケーション遅延、プロメトリクス(telemetry)を可視化

バックアップ、ローリングアップグレード、DR対応

バックアップはRaftスナップショットで取得します。原則リーダーから取得し、安全なストレージに世代管理します。復元は新規またはクリーンなデータディレクトリに対して行います。

アップグレードは一度に1ノードずつのローリングで実施し、常にクォーラムを維持します。ノードを停止→アップグレード→起動→安定化を確認し、次ノードへ進みます。リリースノートの互換性事項に従います。

クォーラム喪失やハード障害でノードを除去する場合、peer一覧を確認し、該当ノードをremoveし、必要であればスナップショットから再構築します。

• 取得: vault operator raft snapshot save backup.snap
• 復元: 停止状態でデータディレクトリを空に→vault operator raft snapshot restore backup.snap
• 確認: vault operator raft list-peers / vault operator raft autopilot state
• 除去: vault operator raft remove-peer -peer-id=<ID>
• ローリング: 常に過半数が稼働する順序で実施

比較表と試験ひっかけポイント

Raft統合ストレージは外部依存を排しHAを実現しますが、既存のConsul運用資産やKVを兼用したい場合はConsulバックエンドも合理的です。Fileバックエンドは単一ノード向けでHA用途には不適です。

試験では、奇数ノード原則、api_addrとcluster_addrの混同、スナップショットの取得先、クォーラム喪失時の対処(ピア除去と再参加)が狙われます。

• api_addrはクライアント向け、cluster_addrはピア間向け
• 2ノードは避ける(1台故障で書き込み不能)
• スナップショットは原則リーダーから取得
• 障害ノードはremove-peerで整理→再構築/再参加

セキュリティと監視の勘所

Raftピア通信とAPIの双方でTLSを必須化し、証明書のSANにapi_addr/cluster_addrのFQDNまたはIPを含めます。TLS検証が失敗するとjoinやレプリケーションが不安定になります。

保存データはVaultのストレージバリアにより暗号化されます。スナップショットも機微情報を含むため、取得権限の厳格化と保管先の暗号化・アクセス制御が必要です。監視はヘルスエンドポイントとtelemetryを組み合わせ、ピア数、リーダー遷移、レプリケーション遅延を継続観測します。

• listenerのTLS必須化とCA配布、ピア間SNI一致を確認
• 監査ログ(audit device)の永続化・転送を有効化
• telemetryのエクスポートとダッシュボード整備
• 証明書ローテーション手順を事前検証

問題で確認

よくある質問