KeepalivedとHAProxyで本番L4 HA構成を設計する｜フェイルオーバー動作確認と切り戻し手順

なぜKeepalivedとHAProxyを組み合わせるのか

サービスの可用性を高めるうえで、単一の負荷分散サーバはそれ自体が単一障害点（SPOF）になるというジレンマがあります。この問題を解消する現場の定番構成が、HAProxyによるL4/L7負荷分散とKeepalivedによるVIP（Virtual IP）フェイルオーバーの組み合わせです。

HAProxyはTCP／HTTPセッションの振り分けとヘルスチェックを担い、Keepalivedは複数サーバ間でVIPを管理してActive/Standby構成を実現します。両者はそれぞれ独立して動作するOSSですが、役割が明確に分離されているため、組み合わせが自然に成立します。VRRPプロトコルを使ってVIPの移動を制御するKeepalivedと、接続を受け付けてバックエンドへ振り分けるHAProxyという分業体制が、2026年現在も本番L4 HA構成の事実上の標準として広く採用されています。

本記事では「設計 → 設定 → 動作確認 → 切り戻し」の流れを一本で完結させることを目的とします。読者がそのまま自環境に適用できる手順を提示します。

構成の全体像と前提条件

最もシンプルな構成は、HAProxy + Keepalivedを導入した2台のロードバランサ（LB-1をActive、LB-2をStandby）と、その背後にある複数のバックエンドサーバです。クライアントはVIPのみを参照するため、LBの切り替えはサービス側から透過的に見えます。

前提となる環境は以下のとおりです。

• OS: Ubuntu 24.04 LTS または Rocky Linux 9.x（どちらも同手順で動作確認済み）
• HAProxy: 2.8系（LTS）または3.0系
• Keepalived: 2.2.x
• LB-1: 192.168.10.11 / LB-2: 192.168.10.12 / VIP: 192.168.10.10
• バックエンドサーバ: 192.168.10.21〜23（HTTPサービスをポート8080で提供）
• SELinux / AppArmorは事前にポリシー調整済みであること

VIPはどちらのLBにも静的には割り当てられておらず、Keepalivedが動的に付与します。ip_nonlocal_bindを有効にしておかないと、HAProxyがVIPをバインドしようとして起動失敗するケースがよくあります。両ノードで以下を設定しておきます。

echo "net.ipv4.ip_nonlocal_bind = 1" | sudo tee /etc/sysctl.d/99-haproxy.conf
sudo sysctl --system

HAProxyの設定手順

HAProxyの設定ファイルは/etc/haproxy/haproxy.cfgです。L4（TCP）モードで動作させる場合はmode tcpを指定します。HTTP(S)オフロードまで含めるならmode httpに変更し、フロントエンドでSSL終端を行います。ここではL4 HAの文脈でTCPモードを基本とします。

global
    log /dev/log local0
    maxconn 50000
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode tcp
    option tcplog
    option dontlognull
    timeout connect 5s
    timeout client  30s
    timeout server  30s

frontend web_front
    bind 192.168.10.10:80
    default_backend web_back

backend web_back
    balance roundrobin
    option tcp-check
    server web1 192.168.10.21:8080 check inter 2s fall 3 rise 2
    server web2 192.168.10.22:8080 check inter 2s fall 3 rise 2
    server web3 192.168.10.23:8080 check inter 2s fall 3 rise 2

fall 3 rise 2の意味は、ヘルスチェック3回連続失敗でDOWN判定、2回連続成功でUP復帰です。本番ではinterの間隔とこの閾値のバランスが重要で、短すぎると誤検知が増え、長すぎると障害検知が遅れます。2秒間隔・3回失敗は多くの現場でバランスが取れているとされます。

設定の検証と反映は以下のコマンドで行います。

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy

systemctl reloadはグレースフルリロードであり、既存セッションを維持したまま設定を反映できます。restartは既存接続を切断するため、本番では基本的にreloadを優先します。

KeepalivedのVIP設定とフェイルオーバー設計

Keepalivedの設定ファイルは/etc/keepalived/keepalived.confです。LB-1（Active）とLB-2（Standby）でファイルを用意します。MASTER/BACKUPの違いとpriorityの大小が切り替え判断の基準です。

LB-1（MASTER側）の設定例：

vrrp_script chk_haproxy {
    script "/usr/bin/systemctl is-active haproxy"
    interval 2
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass s3cur3pass
    }
    virtual_ipaddress {
        192.168.10.10/24
    }
    track_script {
        chk_haproxy
    }
}

LB-2（BACKUP側）の設定例：上記と同じ内容でstate BACKUP・priority 90に変更します。

注目すべきはvrrp_scriptブロックです。weight -20の指定により、systemctl is-active haproxyが失敗した場合にLB-1のpriorityを110から90へ引き下げます。これにより、HAProxyが停止した時点でVIPがLB-2に移動します。HAProxyプロセスの障害と物理NICの障害を区別して検知できるこの設計は、実運用上非常に有効です。

設定反映後はKeepalivedをsystemdで管理します。

sudo systemctl enable --now keepalived
sudo systemctl status keepalived

LB-1でip addr show eth0を実行し、192.168.10.10/24が表示されればVIPの付与が正常です。

フェイルオーバー動作確認手順

構成が整ったら、意図的に障害を起こしてフェイルオーバーが正しく機能するか確認します。テストはサービス影響の少ない時間帯に、段階的に実施することが重要です。

HAProxyプロセス停止によるVIP移動の確認

LB-1でHAProxyを停止します。

sudo systemctl stop haproxy

その直後、LB-2側のジャーナルを確認します。

sudo journalctl -u keepalived -f

数秒以内にEntering MASTER STATEのログが出力され、ip addr show eth0でLB-2にVIPが移動していれば正常です。この切り替え時間（RTO）はKeepalived設定のadvert_intとvrrp_scriptのinterval・fallの積で概算できます。上記設定ではおよそ4〜6秒が目安です。

クライアント側の疎通確認

クライアント端末から継続的にVIPへリクエストを送り、切り替え中の影響を計測します。

while true; do
  curl -s -o /dev/null -w "%{http_code} %{time_total}\n" http://192.168.10.10/
  sleep 0.5
done

フェイルオーバー中に数回の接続失敗または遅延が出るのは想定内です。重要なのはVIP移動後に正常応答が安定して再開することです。TCPセッションは切り替え時に一度リセットされるため、アプリケーション側でリトライロジックが実装されているかどうかも確認観点に含めます。

バックエンドサーバのヘルスチェック確認

HAProxyのソケットを通じてバックエンドの状態をリアルタイムに確認できます。

echo "show stat" | sudo socat stdio /var/run/haproxy/admin.sock | cut -d',' -f1,2,18,19 | column -t -s ','

出力のstatus列がUPであれば正常です。バックエンドサーバ1台を意図的に停止し、HAProxyが自動的にDOWN判定してセッションを残り2台に振り分けることも合わせて確認します。

切り戻し手順と運用上の注意点

メンテナンスや障害対応後にLB-1をActiveに戻す場合、設定によってはVIPが自動で戻る（preemptモード）か手動操作が必要か（nopreemptモード）が変わります。

デフォルトはpreemptモードであり、LB-1が復帰してHAProxyが正常化すると、priorityが再び110に戻るためVIPがLB-1に自動で移動します。この再移動は再度サービス断を引き起こします。本番運用では意図しないVIP移動を避けるため、nopreemptをvrrp_instanceブロックに追記することが多いです。

vrrp_instance VI_1 {
    state BACKUP   # nopreemptを使う場合、両ノードをBACKUPにする
    nopreempt
    ...
}

nopreemptを使う場合、両ノードをstate BACKUPにしたうえでpriorityだけで優先順位を決定します。VIPを意図的にLB-1に戻したい場合は、LB-2のKeepalived一時停止もしくはpriorityの手動変更後にサービス再起動する方法を採ります。

もう一点、現場でよく見落とされる注意点があります。Keepalivedが使用するVRRPマルチキャスト（宛先224.0.0.18）は、クラウド環境や一部のデータセンタースイッチでデフォルトブロックされています。その場合はユニキャストVRRPへの切り替えが必要です。

unicast_src_ip 192.168.10.11
unicast_peer {
    192.168.10.12
}

上記をvrrp_instanceブロック内に追記するだけでユニキャストVRRPに切り替わります。AWS・GCP・Azureなどパブリッククラウド上でKeepalived + HAProxyを使う場合はこの設定が必須です。

2026年現行環境での差分と追加考慮点

2026年時点で本構成を組む際に意識しておきたい環境差分を整理します。

HAProxy 3.0系の変更点：HAProxy 3.0はLTS（2.8）の次世代安定版として位置づけられており、quic（HTTP/3）サポートが本格化しています。L4構成であれば2.8と設定ファイルの互換性はほぼ維持されますが、globalセクションのnbthread自動設定の挙動が変わっているため、コア数を明示的に指定する旧設定は動作確認が必要です。

Ubuntu 24.04でのKeepalived：Ubuntu 24.04ではKeepalived 2.2.8がaptで提供されています。以前のバージョンで問題になっていたvrrp_scriptのscript実行ユーザ権限まわりのバグが修正されており、script_userの明示指定なしでも期待どおり動作します。ただし、Ubuntu 22.04からアップグレードした環境では古い設定ファイルが残存するケースがあるため、設定の棚卸しを推奨します。

Rocky Linux 9 / RHEL 9系：RHEL 9.x環境ではnftablesがデフォルトのファイアウォールバックエンドです。VRRPパケットを許可するfirewall-cmdのルールをマスカレードやrich-ruleで追加する際、iptablesとnftablesの混在は設定競合を起こしやすいため、どちらかに統一することが重要です。

sudo firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
sudo firewall-cmd --reload

コンテナ環境との共存：KubernetesやDockerを同一ホストで動かしている場合、CNIプラグインが設定するiptables/nftablesルールがVRRPの送受信を意図せずブロックすることがあります。Keepalivedを専用の物理ホストもしくはベアメタルVMで動かす設計が、トラブルを最小化するうえで依然として堅実な選択です。

KeepalivedとHAProxyによるL4 HA構成は、設定の明快さと実績の豊富さから、クラウドネイティブな環境が進んだ現在でも有力な選択肢であり続けています。動作確認と切り戻し手順を事前に整備しておくことが、本番での信頼性を支える実務上の核心です。