Onboarding Guide
デプロイメント

高可用性構成

Vaultの高可用性クラスターの構築
最終更新: 2026/4/13

高可用性構成

Vaultの高可用性（HA）構成により、単一障害点を排除し、サービスの可用性を向上させることができます。

高可用性とは

**高可用性（High Availability）**は、システムの障害時でもサービスを継続できる構成です。

HAの利点

✅ 可用性の向上

  • サーバー障害時でもサービス継続
  • メンテナンス時のダウンタイム削減

✅ 負荷分散

  • 読み取りリクエストの分散
  • パフォーマンスの向上

✅ 災害対策

  • データセンター障害への対応
  • ビジネス継続性の確保

Vaultのアーキテクチャ

アクティブ/スタンバイ構成

┌─────────────────────────────────────┐
│      ロードバランサー                │
└──────────┬──────────────────────────┘
           │
    ┌──────┴──────┐
    │             │
┌───▼────┐   ┌───▼────┐   ┌─────────┐
│ Active │   │Standby │   │Standby  │
│ Node 1 │   │ Node 2 │   │ Node 3  │
└───┬────┘   └───┬────┘   └────┬────┘
    │            │             │
    └────────────┴─────────────┘
              │
         Raftストレージ

特徴:

  • 1つのアクティブノード
  • 複数のスタンバイノード
  • アクティブノードのみが書き込みを処理
  • スタンバイノードは読み取りのみ（Performance Standby）

Raftストレージを使用したHA構成

ノード1の設定

/etc/vault.d/vault.hcl:

storage "raft" {
  path    = "/vault/data"
  node_id = "node1"
  
  retry_join {
    leader_api_addr = "https://vault-1.example.com:8200"
  }
  
  retry_join {
    leader_api_addr = "https://vault-2.example.com:8200"
  }
  
  retry_join {
    leader_api_addr = "https://vault-3.example.com:8200"
  }
}

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

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

ui = true
disable_mlock = false

ノード2の設定

/etc/vault.d/vault.hcl:

storage "raft" {
  path    = "/vault/data"
  node_id = "node2"
  
  retry_join {
    leader_api_addr = "https://vault-1.example.com:8200"
  }
  
  retry_join {
    leader_api_addr = "https://vault-2.example.com:8200"
  }
  
  retry_join {
    leader_api_addr = "https://vault-3.example.com:8200"
  }
}

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

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

ui = true
disable_mlock = false

ノード3の設定

/etc/vault.d/vault.hcl:

storage "raft" {
  path    = "/vault/data"
  node_id = "node3"
  
  retry_join {
    leader_api_addr = "https://vault-1.example.com:8200"
  }
  
  retry_join {
    leader_api_addr = "https://vault-2.example.com:8200"
  }
  
  retry_join {
    leader_api_addr = "https://vault-3.example.com:8200"
  }
}

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

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

ui = true
disable_mlock = false

クラスターの初期化

ノード1の初期化

# ノード1でVaultを起動
sudo systemctl start vault

# 初期化
vault operator init \
  -key-shares=5 \
  -key-threshold=3

# アンシール
vault operator unseal <key1>
vault operator unseal <key2>
vault operator unseal <key3>

ノード2とノード3の参加

# ノード2でVaultを起動
sudo systemctl start vault

# アンシール
vault operator unseal <key1>
vault operator unseal <key2>
vault operator unseal <key3>

# ノード3でも同様に実行

クラスターの確認

# Raftピアの確認
vault operator raft list-peers

出力例:

Node     Address                    State       Voter
----     -------                    -----       -----
node1    vault-1.example.com:8201   leader      true
node2    vault-2.example.com:8201   follower    true
node3    vault-3.example.com:8201   follower    true

ロードバランサーの設定

HAProxyの例

/etc/haproxy/haproxy.cfg:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000

frontend vault_frontend
    bind *:8200 ssl crt /etc/haproxy/certs/vault.pem
    default_backend vault_backend

backend vault_backend
    balance roundrobin
    option httpchk GET /v1/sys/health
    http-check expect status 200
    server vault1 vault-1.example.com:8200 check ssl verify none
    server vault2 vault-2.example.com:8200 check ssl verify none
    server vault3 vault-3.example.com:8200 check ssl verify none

Nginxの例

/etc/nginx/conf.d/vault.conf:

upstream vault_backend {
    least_conn;
    server vault-1.example.com:8200 max_fails=3 fail_timeout=30s;
    server vault-2.example.com:8200 max_fails=3 fail_timeout=30s;
    server vault-3.example.com:8200 max_fails=3 fail_timeout=30s;
}

server {
    listen 443 ssl http2;
    server_name vault.example.com;

    ssl_certificate /etc/nginx/ssl/vault.crt;
    ssl_certificate_key /etc/nginx/ssl/vault.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass https://vault_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /v1/sys/health {
        proxy_pass https://vault_backend;
        access_log off;
    }
}

フェイルオーバー

自動フェイルオーバー

Raftストレージを使用している場合、フェイルオーバーは自動的に行われます。

# アクティブノードの停止
sudo systemctl stop vault  # node1

# 新しいリーダーの選出（自動）
vault operator raft list-peers

出力例:

Node     Address                    State       Voter
----     -------                    -----       -----
node2    vault-2.example.com:8201   leader      true
node3    vault-3.example.com:8201   follower    true

手動フェイルオーバー

# リーダーのステップダウン
vault operator step-down

ノードの追加と削除

ノードの追加

# 新しいノードでVaultを起動
sudo systemctl start vault

# アンシール
vault operator unseal <key1>
vault operator unseal <key2>
vault operator unseal <key3>

# クラスターへの参加（自動）
# retry_join設定により自動的に参加

ノードの削除

# ノードを停止
sudo systemctl stop vault

# リーダーノードでピアを削除
vault operator raft remove-peer node4

スナップショットとリストア

スナップショットの作成

# スナップショットの作成
vault operator raft snapshot save backup.snap

スナップショットのリストア

# すべてのノードを停止
sudo systemctl stop vault

# リーダーノードでリストア
vault operator raft snapshot restore -force backup.snap

# すべてのノードを起動
sudo systemctl start vault

# アンシール
vault operator unseal <key1>
vault operator unseal <key2>
vault operator unseal <key3>

Performance Standby（Enterprise版）

Enterprise版の機能Performance Standbyは、Vault Enterprise版でのみ利用可能な機能です。

概要

Performance Standbyノードは、読み取りリクエストを処理できるスタンバイノードです。通常のスタンバイノードは待機状態ですが、Performance Standbyノードはアクティブに読み取りリクエストを処理します。

アーキテクチャ

┌─────────────────────────────────────┐
│      ロードバランサー                │
└──────────┬──────────────────────────┘
           │
    ┌──────┴──────┐
    │             │
┌───▼────┐   ┌───▼────────┐   ┌─────────────┐
│ Active │   │Performance │   │Performance  │
│ Node   │   │Standby     │   │Standby      │
│(R/W)   │   │(Read Only) │   │(Read Only)  │
└───┬────┘   └───┬────────┘   └────┬────────┘
    │            │                  │
    └────────────┴──────────────────┘
              │
         Raftストレージ

設定

config.hcl:

storage "raft" {
  path    = "/vault/data"
  node_id = "node1"
}

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

# Performance Standbyの有効化
disable_performance_standby = false

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

利点

✅ 読み取りパフォーマンスの向上

  • 複数のノードで読み取りリクエストを処理
  • 負荷分散による高速化
  • アクティブノードの負荷軽減

✅ スケーラビリティ

  • 読み取り専用ノードの追加が容易
  • 水平スケーリング
  • 地理的に分散した読み取り

✅ 可用性の向上

  • アクティブノード障害時の高速フェイルオーバー
  • 読み取りリクエストの継続処理

動作確認

# Performance Standbyステータスの確認
vault status

# 出力例
Sealed: false
Key Shares: 5
Key Threshold: 3
Unseal Progress: 0
Version: 1.15.0+ent
Build Date: 2024-01-15T10:30:45Z
Storage Type: raft
Cluster Name: vault-cluster-abc123
Cluster ID: 12345678-1234-1234-1234-123456789abc
HA Enabled: true
HA Cluster: https://vault-cluster
HA Mode: standby
Performance Standby Node: true
Performance Standby Last Remote WAL: 12345
Active Node Address: https://vault-1.example.com:8200

ロードバランサー設定

Performance Standbyを活用するには、ロードバランサーで読み取りリクエストを分散します。

HAProxy設定例:

backend vault_backend
    balance roundrobin
    option httpchk GET /v1/sys/health?perfstandbyok=true
    http-check expect status 200
    server vault1 vault-1.example.com:8200 check ssl verify none
    server vault2 vault-2.example.com:8200 check ssl verify none
    server vault3 vault-3.example.com:8200 check ssl verify none

Performance Replication（Enterprise版）

Enterprise版の機能Performance Replicationは、Vault Enterprise版でのみ利用可能な機能です。

概要

Performance Replicationは、複数のVaultクラスター間でデータをレプリケートし、読み取りパフォーマンスを向上させる機能です。Primaryクラスターで書き込まれたデータが、複数のSecondaryクラスターに自動的にレプリケートされます。

アーキテクチャ

┌─────────────────────────────────────────┐
│         Primary Cluster                 │
│  (Read/Write)                           │
│  ┌────────┐  ┌────────┐  ┌────────┐   │
│  │ Node 1 │  │ Node 2 │  │ Node 3 │   │
│  └────────┘  └────────┘  └────────┘   │
└──────────────────┬──────────────────────┘
                   │ Replication
        ┌──────────┴──────────┐
        │                     │
┌───────▼─────────┐   ┌───────▼─────────┐
│ Secondary       │   │ Secondary       │
│ Cluster (Asia)  │   │ Cluster (EU)    │
│ (Read Only)     │   │ (Read Only)     │
│  ┌────────┐     │   │  ┌────────┐     │
│  │ Node 1 │     │   │  │ Node 1 │     │
│  └────────┘     │   │  └────────┘     │
└─────────────────┘   └─────────────────┘

特徴

  • 書き込み: Primaryクラスターのみ
  • 読み取り: すべてのクラスター
  • レプリケーション: 非同期（準リアルタイム）
  • 独立性: 各Secondaryクラスターは独立して動作

設定手順

1. Primaryクラスターの設定

# Performance Replicationの有効化
vault write -f sys/replication/performance/primary/enable

# 確認
vault read sys/replication/performance/status

出力例:

Key                     Value
---                     -----
mode                    primary
cluster_id              12345678-1234-1234-1234-123456789abc
known_secondaries       0

2. Secondaryトークンの生成

# Asia用のSecondaryトークン生成
vault write sys/replication/performance/primary/secondary-token \
  id=secondary-asia

# EU用のSecondaryトークン生成
vault write sys/replication/performance/primary/secondary-token \
  id=secondary-eu

出力例:

Key              Value
---              -----
wrapping_token   hvs.CAESIJ...（長いトークン文字列）

3. Secondaryクラスターの設定

# Secondaryとして有効化
vault write sys/replication/performance/secondary/enable \
  token=<wrapping-token>

# 確認
vault read sys/replication/performance/status

出力例:

Key                     Value
---                     -----
mode                    secondary
cluster_id              12345678-1234-1234-1234-123456789abc
primary_cluster_addr    https://vault-primary.example.com:8201
state                   stream-wals

利点

✅ グローバルスケーリング

  • 地理的に分散した読み取り
  • レイテンシの削減
  • ローカルアクセスの高速化

✅ 負荷分散

  • 読み取りリクエストの分散
  • Primaryクラスターの負荷軽減
  • 地域ごとの最適化

✅ 可用性の向上

  • 複数のクラスターで読み取り可能
  • 地域障害への対応

監視とメンテナンス

# レプリケーションステータスの確認
vault read sys/replication/performance/status

# Secondaryの一覧
vault list sys/replication/performance/primary/secondaries

# 特定Secondaryの詳細
vault read sys/replication/performance/primary/secondary/secondary-asia

Secondaryの削除

# Secondaryの無効化（Secondaryクラスター側）
vault write -f sys/replication/performance/secondary/disable

# Primaryからの削除（Primaryクラスター側）
vault write -f sys/replication/performance/primary/revoke-secondary \
  id=secondary-asia

Disaster Recovery Replication（Enterprise版）

Enterprise版の機能DR Replicationは、Vault Enterprise版でのみ利用可能な機能です。

概要

DR（Disaster Recovery）Replicationは、災害対策のためのレプリケーション機能です。Primaryクラスターの完全なコピーをDR Secondaryクラスターに保持し、災害時にはDR SecondaryをPrimaryに昇格させることができます。

アーキテクチャ

┌─────────────────────────────────────────┐
│         Primary Cluster                 │
│  (Active - すべての操作)                │
│  ┌────────┐  ┌────────┐  ┌────────┐   │
│  │ Node 1 │  │ Node 2 │  │ Node 3 │   │
│  └────────┘  └────────┘  └────────┘   │
└──────────────────┬──────────────────────┘
                   │ DR Replication
                   │ (すべてのデータ)
┌──────────────────▼──────────────────────┐
│         DR Secondary Cluster            │
│  (Standby - 災害時にPromote)            │
│  ┌────────┐  ┌────────┐  ┌────────┐   │
│  │ Node 1 │  │ Node 2 │  │ Node 3 │   │
│  └────────┘  └────────┘  └────────┘   │
└─────────────────────────────────────────┘

Performance ReplicationとDR Replicationの違い

特徴Performance ReplicationDR Replication
目的パフォーマンス向上災害対策
Secondaryでの読み取り✅ 可能❌ 不可
Secondaryでの書き込み❌ 不可❌ 不可
レプリケート内容データのみすべて（設定含む）
Secondaryの昇格❌ 不可✅ 可能
用途グローバル展開バックアップ

設定手順

1. Primaryクラスターの設定

# DR Replicationの有効化
vault write -f sys/replication/dr/primary/enable

# 確認
vault read sys/replication/dr/status

2. DR Secondaryトークンの生成

# DR Secondaryトークンの生成
vault write sys/replication/dr/primary/secondary-token \
  id=dr-secondary

3. DR Secondaryクラスターの設定

# DR Secondaryとして有効化
vault write sys/replication/dr/secondary/enable \
  token=<wrapping-token>

# 確認
vault read sys/replication/dr/status

出力例:

Key                     Value
---                     -----
mode                    secondary
cluster_id              12345678-1234-1234-1234-123456789abc
primary_cluster_addr    https://vault-primary.example.com:8201
state                   stream-wals

フェイルオーバー手順

災害発生時、DR SecondaryをPrimaryに昇格させます。

1. DR Secondaryの昇格

# DR SecondaryをPrimaryに昇格
vault write -f sys/replication/dr/secondary/promote

# 確認
vault read sys/replication/dr/status

出力例:

Key                     Value
---                     -----
mode                    primary
cluster_id              12345678-1234-1234-1234-123456789abc

2. アプリケーションの切り替え

# アプリケーションの接続先を新しいPrimaryに変更
export VAULT_ADDR=https://vault-dr.example.com:8200

3. 元のPrimaryの復旧（オプション）

元のPrimaryが復旧した場合、DR Secondaryとして再設定できます。

# 元のPrimaryをDR Secondaryとして再設定
vault write sys/replication/dr/secondary/enable \
  token=<new-wrapping-token>

利点

✅ 災害対策

  • データセンター障害への対応
  • ビジネス継続性の確保
  • RPO（目標復旧時点）の最小化

✅ 高速リカバリ

  • 自動レプリケーション
  • 迅速なフェイルオーバー
  • ダウンタイムの最小化

✅ 完全なバックアップ

  • すべての設定を含む
  • 認証方法も含む
  • ポリシーも含む

監視

# DR Replicationステータスの確認
vault read sys/replication/dr/status

# レプリケーション遅延の確認
vault read sys/replication/dr/status | grep last_wal

Performance ReplicationとDR Replicationの併用

両方のレプリケーションを同時に使用できます。

┌─────────────────────────────────────────┐
│         Primary Cluster                 │
│  (Read/Write)                           │
└──────────┬─────────────────┬────────────┘
           │                 │
           │ Performance     │ DR
           │ Replication     │ Replication
           │                 │
┌──────────▼─────────┐   ┌──▼─────────────┐
│ Performance        │   │ DR Secondary   │
│ Secondary (Asia)   │   │ (Standby)      │
│ (Read Only)        │   │                │
└────────────────────┘   └────────────────┘

設定例:

# Primaryクラスターで両方を有効化
vault write -f sys/replication/performance/primary/enable
vault write -f sys/replication/dr/primary/enable

# Performance Secondaryトークン生成
vault write sys/replication/performance/primary/secondary-token \
  id=perf-secondary-asia

# DR Secondaryトークン生成
vault write sys/replication/dr/primary/secondary-token \
  id=dr-secondary

レプリケーションのベストプラクティス

1. 適切なレプリケーション方式の選択

シナリオ推奨
グローバル展開Performance Replication
災害対策DR Replication
両方必要併用

2. ネットワーク要件

  • 安定した低レイテンシ接続
  • 十分な帯域幅
  • TLS/暗号化通信

3. 監視

# レプリケーション遅延の監視
vault read sys/replication/performance/status | grep last_remote_wal
vault read sys/replication/dr/status | grep last_remote_wal

4. 定期的なフェイルオーバーテスト

DR Replicationの場合、定期的にフェイルオーバーテストを実施します。

詳細はレプリケーションをご覧ください。

モニタリング

ヘルスチェック

# アクティブノードのチェック
curl https://vault.example.com:8200/v1/sys/health

# スタンバイノードのチェック
curl https://vault.example.com:8200/v1/sys/health?standbyok=true

Raftステータス

# Raftピアの確認
vault operator raft list-peers

# Raft設定の確認
vault operator raft configuration

トラブルシューティング

クラスターに参加できない

確認事項:

# ネットワーク接続を確認
ping vault-1.example.com

# ポート8201が開いているか確認
telnet vault-1.example.com 8201

# ログを確認
sudo journalctl -u vault -f

リーダー選出に失敗

解決策:

# すべてのノードを停止
sudo systemctl stop vault

# データディレクトリをクリア（注意：データが失われます）
sudo rm -rf /vault/data/*

# スナップショットからリストア
vault operator raft snapshot restore backup.snap

スプリットブレイン

予防策:

  • 奇数個のノード（3, 5, 7）を使用
  • ネットワークの冗長化
  • 適切なクォーラム設定

ベストプラクティス

1. ノード数

  • 最小: 3ノード（推奨）
  • 推奨: 5ノード
  • 最大: 7ノード

2. 地理的分散

データセンター1: node1, node2
データセンター2: node3, node4
データセンター3: node5

3. 定期的なバックアップ

# 毎日スナップショットを作成
0 2 * * * vault operator raft snapshot save /backup/vault-$(date +\%Y\%m\%d).snap

4. モニタリング

  • ヘルスチェックの監視
  • Raftステータスの監視
  • ログの監視

次のステップ

高可用性構成を理解したら、次はバックアップとリカバリでデータ保護の詳細を学びましょう。

高可用性の重要性本番環境では、高可用性構成が必須です。単一障害点を排除し、サービスの継続性を確保してください。
© 2026 IBM Corporation. Licensed under CC BY 4.0.