2026年9月2日

Keepalived と GCP Load Balancing の比較：冗長化と SSL 終端をどこで担うか

ネットワーク・接続

Keepalived は VRRP で仮想 IP を引き継ぐ「サーバー同士のフェイルオーバー」の仕組みで、GCP（Google Cloud）の Cloud Load Balancing はトラフィックの分散・ヘルスチェック・SSL 終端までをまとめて提供するマネージドサービスです。GCP 上で WordPress を冗長化するなら、基本は Cloud Load Balancing を使い、Keepalived はオンプレミスや VPS、L2 ネットワークを自由に扱える環境で使う、と考えると判断しやすくなります。この記事では、両者の仕組みの違い、SSL 終端の担い方、GCP で Keepalived を使う場合の制約と代替策を整理します。

仕組みの違い

Keepalived

Keepalived は主に2つの機能を持つソフトウェアです。

VRRP：複数のサーバーで1つの仮想 IP（VIP）を共有し、マスターが停止したらバックアップが VIP を引き継ぐ
IPVS（LVS）の管理：Linux カーネルの L4 ロードバランサーを設定し、実サーバーのヘルスチェックを行う

よくある使い方は、HAProxy や Nginx を2台用意し、その前に Keepalived の VIP を置く構成です。HAProxy が落ちたら VIP がもう1台に移り、利用者は同じ IP のまま接続を続けられます。Keepalived 自身は TLS を扱わないため、SSL 終端は背後の HAProxy や Nginx が担当し、証明書もそれぞれのサーバーに配置して更新します。

GCP Cloud Load Balancing

Cloud Load Balancing は Google が運用するロードバランサー群で、用途によって種類が分かれています（2026年10月現在の名称。名称や構成は過去に何度か整理されているため、公式ドキュメントで確認してください）。

Application Load Balancer：L7（HTTP/HTTPS）。URL マップによる振り分け、SSL 終端、Cookie などによるセッションアフィニティ、Cloud CDN や Cloud Armor との連携
プロキシ Network Load Balancer：TCP をプロキシする L4。TLS をロードバランサーで終端する構成も取れる
パススルー Network Load Balancer：パケットをそのまま転送する L4。TLS はバックエンドで終端する

外部向け・内部向け、グローバル・リージョンといった区分もあり、組み合わせによって使える機能が異なります。ロードバランサー自体の冗長化は Google 側が担うため、「ロードバランサーが単一障害点になる」問題を自分で解く必要はありません。

SSL 終端の違い

WordPress の HTTPS 化で比べると、運用の差がはっきりします。

Keepalived 構成では、VIP の背後にある HAProxy や Nginx の各サーバーに証明書を置き、certbot などで更新します。2台構成なら2台とも同じ証明書を持ち、更新もそろえる必要があります。片方だけ更新に失敗していると、フェイルオーバーした瞬間に期限切れの証明書が配信される、という事故が起こり得ます。

Application Load Balancer では、Google マネージド SSL 証明書や Certificate Manager を使うと、証明書の発行と更新を GCP に任せられます。DNS がロードバランサーの IP を向いていることなどが発行の条件になるため、切り替え手順の順番には注意が必要です。バックエンドとの間は HTTP でも HTTPS でも構成でき、いずれの場合も WordPress には X-Forwarded-Proto ヘッダーで元のプロトコルが伝わります。wp-config.php でこのヘッダーを見て $_SERVER['HTTPS'] = 'on'; を設定しないと、リダイレクトループや混在コンテンツの原因になります。バックエンドの VM はロードバランサー以外から到達できないようにしておくことが前提です。

GCP で Keepalived を使う場合の制約

Keepalived の VRRP は、マルチキャストで広告を送り、Gratuitous ARP で VIP の移動を周囲に知らせるという L2 ネットワークの仕組みに依存しています。GCP の VPC はこうした L2 の動作をそのままサポートしていないため、オンプレミスと同じ設定では VIP が移りません。

それでも仮想 IP の引き継ぎが必要な場合、Google Cloud のドキュメントでは「フローティング IP アドレス」のパターンとして、次のような方法が紹介されています。

内部パススルー Network Load Balancer を VIP の代わりに使う
Keepalived をユニキャストで動かし、状態が変わったときのスクリプトで gcloud を実行して、静的ルートやエイリアス IP を付け替える

後者は API 呼び出しに数秒以上かかることがあり、サービスアカウントの権限設計やスクリプトの失敗時の扱いも自分で用意する必要があります。多くのケースでは、前者のようにマネージドのロードバランサーに任せるほうが、運用の負担と事故の可能性を下げられます。

オンプレミスや VPS での Keepalived の基本設定

L2 を扱える環境で HAProxy を冗長化する場合の、Keepalived の設定例です。値は環境に合わせて書き換え、ステージングで切り替え試験をしてから本番に入れてください。

# /etc/keepalived/keepalived.conf（マスター側）
global_defs {
    enable_script_security
    script_user root
}

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1

    # マルチキャストが使えないネットワークではユニキャストを指定
    unicast_src_ip 192.0.2.11
    unicast_peer {
        192.0.2.12
    }

    virtual_ipaddress {
        192.0.2.100/24
    }

    track_script {
        chk_haproxy
    }
}

バックアップ側は state BACKUP、priority を小さく（例：100）し、unicast_src_ip と unicast_peer を入れ替えます。virtual_router_id は同じネットワーク内の他の VRRP グループと重ならない値にします。VRRP の簡易パスワード認証は保護としては弱いため、VRRP の通信は信頼できるネットワーク内に閉じることを優先してください。

切り替えの確認は次の手順で行います。

# VIP がどちらにあるかを確認
ip -brief address show eth0

# マスター側で HAProxy を止めて、VIP の移動をログで見る
sudo systemctl stop haproxy
sudo journalctl -u keepalived -n 30 --no-pager

バックアップ側に VIP が現れ、利用者側からサイトが表示され続ければ成功です。HAProxy を戻したときに VIP がマスターへ戻る（プリエンプト）かどうかも確認しておきます。戻る瞬間にも短い切断が起こるため、戻さない設定（nopreempt）を選ぶ運用もあります。

どちらを選ぶかの目安

GCP Cloud Load Balancing が向いているケース

GCP 上で WordPress を動かしている
証明書の発行・更新や、ロードバランサー自体の冗長化を任せたい
Cloud CDN や Cloud Armor など周辺サービスと組み合わせたい

Keepalived が向いているケース

オンプレミス、データセンター、L2 を扱える VPS で動かしている
既存の HAProxy や Nginx を、構成を大きく変えずに冗長化したい
外部のマネージドサービスに依存しない構成が求められる

どちらの構成でも、WordPress 自体を複数台にするなら、wp-config.php の認証キーとソルトの統一、アップロードファイルの共有、データベースの冗長化が別途必要です。ロードバランサーやフェイルオーバーの仕組みだけでは、サイト全体の可用性は上がりません。構成変更の前にはバックアップを取り、切り戻し手順を用意してから作業してください。

まとめ

Keepalived は VRRP による VIP の引き継ぎが中心で、SSL 終端は背後の HAProxy や Nginx が担う
GCP Cloud Load Balancing は分散・ヘルスチェック・SSL 終端・証明書管理までを提供するマネージドサービス
GCP の VPC では VRRP の前提となる L2 動作がそのまま使えず、内部パススルー Network Load Balancer などで代替するのが一般的
Keepalived を使うなら、ユニキャスト設定、ヘルスチェックスクリプト、切り替え試験までを用意する
どちらを選んでも、WordPress 側の複数台対応（認証キー・アップロード・DB）が別に必要