Vault Filesystem ストレージ: 開発用途とスケール限界を実務目線で整理

Vault はストレージバックエンドを差し替え可能ですが、現在の推奨は本番では Integrated Storage (Raft) です。Filesystem バックエンドは単一ノード前提で、主に開発・検証向けの選択肢です。

この記事では、Filesystem バックエンドの設定、開発での実用ポイント、スケーリング時の限界、運用と移行の判断軸を、試験で問われやすい観点と実務の勘所を揃えて解説します。

Filesystem バックエンドの位置づけ

Filesystem バックエンドは、ローカルディスク上のディレクトリに Vault の暗号化済みデータを保存します。外部サービスへの依存がなく、セットアップが最も簡単です。一方で、HA 構成やクラスタリングはできません。単一ノードでの開発・個人検証・短命な PoC での利用が主な適用範囲です。

Vault は保存前にデータを暗号化します。したがって、基盤のファイルシステムが暗号化されていなくても、保存されるオブジェクトは平文ではありません。ただし、権限管理やディスク障害対策は OS/インフラ側の責務です。

• HA/クラスタ: 非対応。複数ノード運用は不可。
• 共有ストレージ (NFS/SMB 等) 経由の多重接続はサポート外。ロック整合性を満たせないためです。
• データは Vault により暗号化されて保存されるが、OS 権限やディスク冗長性は別途必要。
• 用途の目安: 単一ノードの開発・CI の一時環境・PoC。
• 試験TIP: Filesystem は本番推奨ではない。HA が必要なら Integrated Storage (Raft) か Consul を選ぶ、が基本。

基本セットアップと最小構成

設定はシンプルで、storage "file" の path を指定します。開発ではローカルディレクトリを用意し、Vault 実行ユーザに対して適切な所有権とパーミッションを設定します。TLS は本番では必須ですが、開発では簡便のために無効化するケースもあります (試験では本番での TLS 必須を意識)。

ディレクトリは安定したローカルブロックデバイス上に置き、コンテナ使用時はホストの永続ボリュームにマウントします。ネットワーク共有は避けます。

• ディレクトリ権限: 所有 vault:vault、パーミッション 700 程度を推奨。
• 開発の TLS 無効化は一時的措置。本番は必ず TLS を有効化。
• systemd 運用時は LimitMEMLOCK など OS 設定も見直す。
• 試験TIP: storage の選択は seal の仕組みとは独立。オートアンシールは別機能。

最小の Vault 設定例 (開発向け)

# /etc/vault.d/vault.hcl
storage "file" {
  path = "/opt/vault/data"
}

# 開発では簡便のために TLS 無効化 (本番では必ず TLS 有効化)
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}

disable_mlock = true

# 実行例:
# sudo mkdir -p /opt/vault/data && sudo chown -R vault:vault /opt/vault
# vault server -config=/etc/vault.d/vault.hcl

開発ユースケースと実務ワークフロー

CI の統合テストやローカル開発で、Vault を素早く起動しシークレットを投入・検証する用途に向きます。In-memory の dev モードと異なり、プロセスを再起動してもデータが保持されるため、短期的な状態保持が必要な検証に便利です。

アプリ側のクライアント認証 (AppRole、Kubernetes Auth など) の結線テストにも使用できます。ただしパフォーマンステストや可用性評価には不適です。

• 起動〜初期化: vault operator init → unseal キーでアンシール → ポリシー作成 → シークレット投入。
• 再現性確保: 初期化と投入をスクリプト化 (CLI/API)。ディレクトリは Git 管理から除外。
• クリーンアップ: 状態を捨てるときは Vault 停止後にデータディレクトリを削除。
• 試験TIP: dev モードは in-memory。Filesystem は永続だが単一ノード。用途の違いを区別。

スケール限界とボトルネックの具体像

Filesystem バックエンドは、多数の小さなオブジェクトをファイルとして扱うため、メタデータ操作や同期的な書き込みが増えるワークロードで性能劣化が顕在化しやすいです。特に高頻度の書き込みや大量のリスト操作、ディレクトリ・inode の枯渇に注意します。

HA 非対応のため、スループットを上げる手段はスケールアップに限られます。I/O レイテンシが p99 で長い環境では、認証パスやシークレットの取得遅延がアプリの SLO を直撃します。

• 典型ボトルネック: ディスク IOPS、メタデータ更新、fsync 相当の同期負荷、inode/ディレクトリ深さ。
• ワークロード感度: 書き込み頻度が高いトークン/リース更新系は影響が大きい。読み取り偏重でもリスト操作が多いと遅延しやすい。
• アンチパターン: 共有ストレージを介して複数 Vault を同一パスに接続して HA 代替とすること (非対応)。
• 経験則: 単一ノードで軽量な開発負荷に留める。増加傾向が見えたら早期に Raft/Consul 構成へ移行検討。
• 試験TIP: Filesystem = 非 HA、単一ノード。NFS 共有で HA は不可、が定番の正解。

単一ノードと共有 FS 非対応のイメージ

運用: バックアップ、復旧、監視の勘所

バックアップは、整合性のとれたスナップショットを取得するのが原則です。もっとも安全なのは Vault を停止またはシール状態にしてから、データディレクトリをファイルシステムのスナップショット機能やブロックレベルで取得する方法です。稼働中の単純なファイルコピーは部分書き込みのリスクがあります。

監視はディスクレイテンシと IOPS、空き容量、inode 使用率を最優先に。Vault 側は監査ログの出力可否、HTTP 5xx 増加、リース更新エラー率などを継続監視します。

• バックアップ: 停止/シール → FS スナップショット or ボリュームスナップショット。
• 復旧: 新しい同一バージョンの Vault にデータディレクトリを戻し、アンシールして整合性を確認。
• 監視: ディスクの p95/p99 レイテンシ、IOPS、容量/inode、Vault のヘルスエンドポイント。
• 容量計画: 小さなファイルが多いため inode 枯渇に注意。十分な inode を確保してフォーマット。
• 試験TIP: Filesystem にはネイティブなスナップショット/レプリケーション機構はない。整合スナップショットは基盤側で確保。

いつ Raft/Consul へ切り替えるか (比較と判断軸)

可用性要件が生じた時点、またはスループット/レイテンシがボトルネック化した時点が切り替えの合図です。既存に Consul を標準運用している組織は Consul バックエンドの選択肢もありますが、現在の推奨は Integrated Storage (Raft) を用いた自己完結クラスタです。

移行は新クラスタを用意し、計画停止のうえで必要なシークレットを API 経由で再投入する方法が一般的です (エクスポートできない種類もあるため事前棚卸必須)。本番要件があるなら早めに Raft/Consul 設計へ移行を検討しましょう。

• 判断軸: 可用性/SLO、外部依存ポリシー、運用標準、将来のノード増。
• 小規模 PoC/単一ノード: Filesystem
• 本番/中〜大規模: Integrated Storage (Raft)
• 既存に安定運用の Consul クラスタがある場合: Consul も選択肢
• 試験TIP: 現行ベストプラクティスは Raft を第一候補。

問題で確認

よくある質問