Vault Raft Autopilot徹底ガイド: 安定性と自動運用をOps視点で固める

Raft Autopilotは、Vaultの統合ストレージ(Raft)を自律的に健全化し、障害や運用イベント時のヒューマンエラーを減らす仕組みです。

本稿は、公式ドキュメントに基づく安定した概念を中心に、試験で狙われやすい要点と、日々の運用手順に直結する実務的な設定・確認方法を一体で解説します。

Raft Autopilotの概要と前提

Vaultの統合ストレージはRaftコンセンサスを用いてデータを複製・整合させます。Autopilotは、このRaftクラスタの健全性監視と自動的な是正アクション（例: 長期不健康ノードのクリーンアップ）を担います。目的は、可用性の維持とオペレーション負荷の低減です。

Autopilotは、リーダー選出を含むRaftの基本挙動を壊さない範囲で動作し、しきい値に基づいて安全にアクションします。設定はAPI/CLIで変更でき、段階的に適用可能です。ゾーン冗長性に配慮した意思決定も可能で、マルチAZ/マルチラック運用で効果を発揮します。

• 主な役割: 健康診断、しきい値判定、自動クリーンアップ
• 狙い: クォーラム維持と分断回避、オペレーション自動化
• 基本要件: 3台以上の奇数ノード構成（推奨は5台）
• 適用範囲: 統合ストレージ(Raft)クラスタ

健康診断と整合性の見方

Autopilotは、ノードの到達性、レプリケーション遅延、安定時間などの観点でクラスタを評価します。評価は即時ではなく、一定時間の観測に基づきます。短期スパイクで誤動作しないための設計です。

試験や実務で押さえるべきは、しきい値の意味と副作用です。過度に厳しい設定は誤検知、緩すぎる設定はクリーンアップ遅延のリスクになります。ネットワーク特性（LAN/WAN）とノード台数を前提に、段階的に調整してください。

• last_contact_threshold: リーダーへの最終到達からの許容遅延。小さすぎると一時的な輻輳で不健康判定になりやすい。
• max_trailing_logs: フォロワがどれだけログ適用から遅れて良いかの上限。過小だと大規模復旧で不健康扱いになりやすい。
• server_stabilization_time: 追加・復帰後に安定と見なすまでの観測時間。大きすぎると自動化が鈍くなる。
• cleanup_dead_servers: 長期不健康ノードを自動的に退役させるフラグ。クォーラムを崩さない範囲で実行。
• redundancy_zone_tag: ゾーン情報のタグ名。ゾーン偏りのある退役を避けるためのヒントとして用いられる。

自動リーダー遷移とサーバーライフサイクル

リーダーはRaftの選挙により自動選出され、Autopilotはそれを補助するメタ機能（健全性維持とクリーンアップ）を提供します。運用としては、計画メンテ時にリーダーを自発的に降格させる（step-down）と、再選出は直ちに行われます。

長期間にわたり連絡不能やログの遅延がしきい値を超えるノードは、不健康ノードとしてマーキングされ、cleanup_dead_serversが有効であれば退役の候補になります。redundancy_zone_tagを設定しておけば、単一ゾーンに偏るリスクを下げられます。

• 計画停止時: 先にstep-downしてからメンテ開始（クライアント影響を最小化）。
• 復帰時: server_stabilization_timeを待ってからトラフィック増に備える。
• 退役時: Autopilotの自動退役を基本に、クォーラム低下を招く場合は手動で抑制。

5ノード・マルチAZ構成でのAutopilot動作イメージ

設定パラメータとチューニングの勘所

まずは観測から。状態を可視化したうえで、しきい値は小さく刻んで調整します。LAN前提の低遅延クラスタと、AZ/地域を跨ぐクラスタでは適正値が異なります。

設定変更はオンラインで行えます。変更後は、Autopilotの状態とクラスタログで効果を検証し、過剰な自動退役や誤検知がないか確認します。

• LAN目安: last_contact_threshold=150–300ms, server_stabilization_time=5–15s
• マルチAZ目安: last_contact_threshold=300–800ms, server_stabilization_time=10–30s
• max_trailing_logsはスナップショット頻度と復旧時間のバランスで決定
• redundancy_zone_tagはメタデータ（例: node_meta.az）と合わせて一貫性を保つ

Autopilot状態の確認と設定（API/CLI例）

# 状態確認（CLI）
vault operator raft autopilot state

# ピア一覧（健全性と投票可否の確認）
vault operator raft list-peers

# 状態確認（API）
curl -sS \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  "$VAULT_ADDR/v1/sys/storage/raft/autopilot/state" | jq .

# 設定の取得（API）
curl -sS \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  "$VAULT_ADDR/v1/sys/storage/raft/autopilot/configuration" | jq .

# 設定の更新（API）
curl -sS -X PUT \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "cleanup_dead_servers": true,
    "last_contact_threshold": "400ms",
    "max_trailing_logs": 250,
    "server_stabilization_time": "12s",
    "redundancy_zone_tag": "az"
  }' \
  "$VAULT_ADDR/v1/sys/storage/raft/autopilot/configuration"

# 計画停止前にリーダーを降格（影響最小化）
vault operator step-down

Autopilot有効化と手動運用の比較

Autopilotは、障害・復旧の多い現場ほど効果があります。とはいえ、すべてを任せきりにせず、しきい値の根拠と例外手順（緊急時の手動介入）を明文化しておくと安全です。試験では、クォーラムを崩さない前提での自動退役の可否、ゾーン配慮、しきい値の意味がよく問われます。

• Autopilotはクォーラムやゾーン冗長性を意識した自動化を提供
• 手動運用は柔軟だが、判断ミスや夜間対応の負担が増える
• Consulバックエンドは運用分離のメリットがある一方でデプロイ複雑度が上がる

運用シナリオ別ベストプラクティス

よくある運用イベントごとに、Autopilot前提での手順を最短で示します。例外系でもクォーラムを崩さないことを常に優先してください。

本節は試験の実務連動問題にも直結しやすい内容です。

• 単一ノード故障: まず状態確認（autopilot state, list-peers）。復旧見込みが薄く、cleanup_dead_serversが有効な場合は自動退役を待つ。クォーラム逼迫時は手動退役は避ける。
• ゾーン障害: redundancy_zone_tagを有効化しておくと自動退役の偏りを抑制。クォーラム維持が不明確なら、cleanupを一時的に無効化して安定化を優先。
• 計画メンテ(パッチ/再起動): 事前にstep-down、復帰後はserver_stabilization_time経過まで監視強化。
• 水平拡張: 1台ずつ追加→安定化待ち→観測→次の追加。max_trailing_logsが過小だと復旧中に不健康判定が出やすいので注意。
• 残骸ピアの整理: ネットワーク的に二度と戻らないピアは、Autopilotに任せるのが原則。手動削除はクォーラム影響のリスクを理解したうえで最終手段として実施。

問題で確認

よくある質問