【Nginx応用講座 第5回】絶対停止させない高可用性（HA）。KeepalivedによるVIP管理とフェイルオーバー

そのサーバーが「心停止」した時、あなたのサービスは即死しますか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、OpenResty（Lua）を使ってNginxに動的なロジックを組み込む方法を学びました。
これで「賢い」サーバーにはなりましたが、まだ「強い」サーバーではありません。

インフラエンジニアの世界には「SPOF（Single Point of Failure：単一障害点）」という言葉があります。
「ここが壊れたら、システム全体が止まる」という弱点のことです。
もし今、あなたが運用しているNginxサーバーの電源が突然落ちたらどうなりますか？
夜中に叩き起こされ、冷や汗をかきながら復旧作業をする……そんな未来を変えるのが今回のテーマです。

本記事では、Linuxにおける高可用性（HA）構成のデファクトスタンダードであるKeepalivedの導入、VRRPプロトコルの仕組み、Nginxプロセスの死活監視、そしてプロが現場で設定する「自動で切り戻さない（nopreempt）」運用までを徹底解説します。

---

第1章：高可用性（HA）とVIPの仕組み

具体的な設定に入る前に、「どうやってIPアドレスを共有するのか」という仕組みを理解しましょう。

VRRP（Virtual Router Redundancy Protocol）

ネットワーク機器の冗長化のために作られたプロトコルです。
複数のサーバーがグループ（VRRPインスタンス）を作り、その中から1台の「Master（親）」を選出します。残りは「Backup（待機）」となります。

VIP（Virtual IP Address）の動き

1. Masterは定期的に「俺は生きているぞ！」という信号（Advertisement）をマルチキャストで送信します。
2. Backupはこの信号を受信している間は、静かに待機します。
3. Masterが故障して信号が途切れると、Backupは「親が死んだ」と判断し、自分自身をMasterに昇格させます。
4. 新Masterは、自分のNIC（LANカード）にVIPを割り当てます。

ユーザーは常に「VIP」に対してアクセスしているため、裏でサーバーが入れ替わったことに気づきません。
これを「フェイルオーバー（Failover）」と呼びます。

---

第2章：環境準備とKeepalivedのインストール

今回は以下の2台構成で構築します。

• Master機（lb01）: 実IP 192.168.1.101
• Backup機（lb02）: 実IP 192.168.1.102
• 仮想IP（VIP）: 192.168.1.200

インストールの実行（両方のサーバーで実施）

AlmaLinux 9などのRHEL系での手順です。

sudo dnf install keepalived
sudo systemctl enable keepalived

【重要】ファイアウォールの設定

VRRPはTCPでもUDPでもない、プロトコル番号112番を使います。
また、マルチキャスト（224.0.0.18）での通信を許可する必要があります。
ここを忘れて「お互いが見えない（スプリットブレイン）」状態になるのが、初心者の最大のハマりポイントです。

# VRRPプロトコルの許可
sudo firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
sudo firewall-cmd --reload

---

第3章：Keepalivedの設定（基本編）

設定ファイル /etc/keepalived/keepalived.conf を編集します。

Master機（lb01）の設定

global_defs {
    router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER        # 初期状態
    interface eth0      # VIPを割り当てるインターフェース名（ip addrで確認）
    virtual_router_id 51 # グループID（両機で揃える）
    priority 100        # 優先度（数字が大きい方がMasterになる）
    advert_int 1        # 生存報告の間隔（秒）
    
    authentication {
        auth_type PASS
        auth_pass my_secret # パスワード（両機で揃える）
    }
    
    virtual_ipaddress {
        192.168.1.200   # VIP
    }
}

Backup機（lb02）の設定

vrrp_instance VI_1 {
    state BACKUP        # 初期状態
    interface eth0
    virtual_router_id 51
    priority 90         # Masterより小さくする
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass my_secret
    }
    
    virtual_ipaddress {
        192.168.1.200
    }
}

設定後、両方のサーバーで sudo systemctl start keepalived を実行します。
Master機で ip addr show eth0 を叩き、192.168.1.200 が表示されていれば成功です！

---

第4章：Nginxが死んだら切り替える（監視スクリプト）

ここまでの設定では、「OSが落ちた時」しか切り替わりません。
もし「OSは生きているけど、Nginxプロセスだけがエラーで停止した」場合はどうなるでしょうか？
Master機はVIPを持ち続け、ユーザーには「接続エラー」が返され続けます。
これを防ぐために、「Nginxの死活監視」を追加します。

監視スクリプトの設定

keepalived.conf に追記します（両機共通）。

# Nginx監視スクリプトの定義
vrrp_script check_nginx {
    script "/usr/bin/killall -0 nginx"  # プロセスが存在するか確認
    interval 2   # 2秒ごとに実行
    weight -20   # 失敗したらPriorityを20下げる
}

vrrp_instance VI_1 {
    ...
    # スクリプトの適用
    track_script {
        check_nginx
    }
}

仕組み解説

1. 通常時、MasterのPriorityは 100 です。
2. Nginxが停止すると、スクリプトが失敗（終了コード1）します。
3. weight -20 が発動し、MasterのPriorityが 80 に下がります。
4. BackupのPriorityは 90 なので、Backupの方が強くなり、主導権を奪います（フェイルオーバー）。

これで、Nginxがコケただけでも瞬時に予備機へ切り替わるようになります。

---

第5章：プロの運用ノウハウ「自動切り戻しを防ぐ（nopreempt）」

デフォルト設定では、旧Masterが復旧すると、Priorityが高いため再びMasterの座を奪い返します（フェイルバック）。
しかし、現場ではこれを嫌うことが多いです。

なぜ自動フェイルバックが危険なのか？

「復旧したと思ったらまたすぐ落ちた」という不安定な状態（フラッピング）の場合、MasterとBackupを行ったり来たりしてしまい、通信断が頻発するからです。
一度Backupに切り替わったら、エンジニアが安全を確認して手動で戻すまで、そのまま運用したいケースが多々あります。

nopreemptの設定

この挙動を実現するには、両方のサーバーを state BACKUP に設定し、優先度が高い方（元Master）に nopreempt を付けます。

Master機（lb01）の設定変更：

vrrp_instance VI_1 {
    state BACKUP      # あえてBACKUPにする
    priority 100
    nopreempt         # 自分の方が強くても、奪い取らない
    ...
}

Backup機（lb02）の設定変更：

vrrp_instance VI_1 {
    state BACKUP
    priority 90
    # こちらには nopreempt を書かない
    ...
}

この設定にしておけば、lb01がダウンしてlb02がMasterになった後、lb01が復旧してもMasterはlb02のまま維持されます。
メンテナンス時に非常に役立つ設定です。

---

第6章：ユニキャストモードへの対応

最後に、AWSやAzureなどのクラウド環境や、マルチキャストが禁止されているネットワークでの設定方法です。
相手のIPを指定して、1対1（ユニキャスト）で死活監視を行います。

vrrp_instance VI_1 {
    ...
    # マルチキャストを使わない
    unicast_src_ip 192.168.1.101  # 自分のIP
    
    unicast_peer {
        192.168.1.102  # 相方のIP
    }
}

これにより、リッチなL2ネットワーク機能がない環境でもKeepalivedを動かすことができます。

---

まとめ：サービスを止めない責任と技術

お疲れ様でした！
今回は、インフラの信頼性を担保する最後の砦、HA構成について解説しました。

今回の重要ポイント：

• Keepalivedを使えば、VIPによる自動フェイルオーバーが実現できる。
• OS監視だけでなく、track_script でNginxプロセスの生死も監視する。
• フラッピングを防ぐために nopreempt 設定を検討する。
• クラウド環境ではマルチキャストが通らないため、ユニキャスト設定を使う。

これで、あなたのNginxサーバーは1台が故障してもサービスを継続できる「不死身のインフラ」になりました。
しかし、動いているからといって放置してはいけません。
「今どれくらいアクセスが来ているのか？」「エラー率は？」「リソースの余裕は？」
これらを可視化して初めて、プロの運用と言えます。

次回、第6回は「可観測性（Observability）の確保。Prometheus/Grafana連携とカスタムメトリクス」です。
ログファイルを見るだけの監視はもう古い。
Nginxの内部状態を数値化し、かっこいいダッシュボードでリアルタイム監視する、DevOps時代のモニタリング環境を構築します。お楽しみに！