2026年7月26日

Azure Load Balancer と HAProxy の比較：WordPress の負荷分散でどちらを選ぶか

ネットワーク・接続

Azure Load Balancer は TCP/UDP を振り分ける L4 のマネージドサービスで、HAProxy は L4 と L7（HTTP）の両方を扱える自前運用のソフトウェアです。WordPress で HTTPS の終端や URL ごとの振り分け、Cookie によるセッション固定が必要なら HAProxy（または Azure の L7 サービス）、TCP レベルで冗長化できれば十分で運用の手間を減らしたいなら Azure Load Balancer が向いています。この記事では、両者の違いを機能・運用・障害時の挙動の観点で整理し、Azure 上でよく採られる組み合わせ構成まで説明します。

それぞれの位置づけ

Azure Load Balancer

Azure Load Balancer は Azure が提供するレイヤー4のロードバランサーです。受け取った TCP/UDP の接続を、バックエンドプールの仮想マシンへ転送します。パケットの中身（HTTP のヘッダーやパス）は見ないため、TLS の終端や URL での振り分けは行いません。そのぶん処理は単純で、可用性やスケールは Azure 側が担います。

SKU は現在 Standard が基本で、以前あった Basic SKU は 2025年9月30日に提供終了が予告されていました。Basic のまま残っている環境は移行が必要です（2026年10月現在、詳細は Microsoft Learn の移行ガイドを参照してください）。

HAProxy

HAProxy はオープンソースのロードバランサー兼リバースプロキシです。Azure 上では仮想マシンにインストールして使います。TCP モードでは L4、HTTP モードでは L7 として動作し、TLS の終端、ホスト名やパスによる振り分け、Cookie を使ったサーバー固定、細かいヘルスチェック、レート制限などを設定ファイルで制御できます。自由度が高い反面、仮想マシンの OS 更新、HAProxy 自体の冗長化、証明書の更新はすべて自分で面倒を見る必要があります。

機能の比較

違いが大きい項目だけを表にまとめます。

観点	Azure Load Balancer（Standard）	HAProxy（VM 上で運用）
動作レイヤー	L4（TCP/UDP）	L4 と L7（HTTP）
TLS 終端	しない	できる
パス・ホスト名での振り分け	できない	できる
セッション固定	送信元 IP のハッシュ	Cookie、送信元 IP など
ヘルスチェック	TCP / HTTP / HTTPS プローブ	詳細な HTTP チェックを設定可能
冗長化	サービス側で提供	自分で複数台構成にする
運用作業	設定のみ	OS・ソフト更新、監視、証明書管理

振り分けとセッション固定

Azure Load Balancer の既定の振り分けは、送信元 IP・送信元ポート・宛先 IP・宛先ポート・プロトコルの5つを使ったハッシュです。セッション固定（ポータルでは「セッション永続化」などの表記）を有効にすると、送信元 IP（とプロトコル）だけで振り分け先を決めるようになります。Cookie は扱えないため、携帯回線や社内プロキシのように多数の利用者が同じ IP から来る環境では偏りが出やすくなります。

HAProxy は balance roundrobin や leastconn などの方式を選べ、cookie 設定で特定のサーバーに固定できます。ただし WordPress はログイン状態を Cookie とデータベースで管理するため、全サーバーで wp-config.php の認証キーとソルトをそろえ、アップロードファイルを共有していれば、セッション固定は多くの場合不要です。

ヘルスチェック

Azure Load Balancer の正常性プローブは、HTTP/HTTPS の場合、指定したパスが 200 を返すかで判定します。プローブは特定の Azure 基盤アドレスから届くため、ネットワークセキュリティグループ（NSG）で AzureLoadBalancer サービスタグからの受信を拒否しないようにします。既定の NSG ルールで許可されていますが、独自のルールで上書きしているとプローブが失敗し、全台が切り離されます。

HAProxy では、Host ヘッダー付きのリクエストや期待するステータス・本文の内容まで指定でき、失敗回数と復帰回数（fall / rise）も細かく調整できます。WordPress のトップページをチェック先にすると負荷が高く、DB 障害で全台が外れるので、どちらの場合も軽いヘルスチェック用のエンドポイントを用意するのが実務的です。

TLS と証明書

Azure Load Balancer は TLS を終端しないため、証明書は各 VM の Web サーバー（Nginx や Apache）に置きます。VM が増えるほど、証明書の配布と更新の手間が増えます。HAProxy なら証明書を HAProxy だけに置き、バックエンドとは HTTP で通信する構成にできます。この場合、WordPress に HTTPS と判定させるために X-Forwarded-Proto ヘッダーを付け、wp-config.php で受け取る設定が必要です。

Azure の中で L7 の機能がほしい場合は、Application Gateway（WAF 機能や Cookie ベースのアフィニティあり）や Azure Front Door というマネージドの選択肢もあります。「HAProxy か Azure Load Balancer か」の二択ではなく、「L7 を自前で持つか、マネージドに任せるか」という比較になる点も意識しておくとよいでしょう。

運用と障害時の違い

冗長化の作り方

Azure Load Balancer はサービス自体が冗長化されており、可用性ゾーンをまたいだ構成も設定で選べます（リージョンによって対応状況が異なります）。

HAProxy を VM で動かす場合、HAProxy の VM が1台だとそこが単一障害点になります。オンプレミスでよく使う Keepalived（VRRP）による仮想 IP の引き継ぎは、Azure の仮想ネットワークでは前提となる L2 の仕組み（マルチキャストや Gratuitous ARP による IP の移動）が通常どおりには動かないため、オンプレミスと同じ手順では使えません。そのため Azure では次のような構成がよく採られます。

インターネット
   │
Azure Load Balancer（Standard, L4）
   │  TCP 443 を振り分け
   ├─ HAProxy VM #1（ゾーン1）── TLS 終端・L7 振り分け
   └─ HAProxy VM #2（ゾーン2）
            │
       WordPress VM 群（プライベートサブネット）

L4 の冗長化を Azure Load Balancer に任せ、L7 の細かい制御を HAProxy が担う形です。手間は増えますが、両方の長所を使えます。

タイムアウトと長い処理

Azure Load Balancer にはアイドルタイムアウトがあり、既定は4分程度です。設定で延長でき、タイムアウト時に TCP リセットを送るオプションもあります。WordPress の管理画面で重いインポート処理を行う、長時間の接続を保つ機能を使う、といった場合は、HAProxy の timeout server や PHP の max_execution_time とあわせて経路全体で見直します。上限値や設定画面の表記は変わることがあるため、Microsoft Learn で確認してください。

監視とログ

Azure Load Balancer は Azure Monitor のメトリック（データパスの可用性、正常性プローブの状態など）で監視します。HTTP のステータスコード単位のログは取れないので、エラー率を見たい場合は Web サーバー側のログが頼りになります。HAProxy はリクエストごとに応答時間や終了ステータスを記録でき、障害の切り分けがしやすい一方、ログの収集・保管も自分で用意する必要があります。

どちらを選ぶかの目安

条件によって答えが変わるため、判断材料を整理します。

Azure Load Balancer が向いているケース

各 VM で TLS を終端しても運用できる台数である
URL ごとの振り分けや Cookie によるサーバー固定が不要
ロードバランサー自体の OS 更新や監視に手をかけたくない

HAProxy が向いているケース

証明書を一か所にまとめたい、HTTP/2 の終端やヘッダー操作をしたい
/wp-admin/ だけ別のサーバー群やタイムアウトにしたい
リクエスト単位の詳細なログで障害を切り分けたい
自前で VM を運用・更新できる体制がある

組み合わせが向いているケース

L7 の制御は必要だが、HAProxy の単一障害点は避けたい

どの構成でも、WordPress を複数台で動かす前提として、メディアファイルの共有、オブジェクトキャッシュの共有、wp-config.php の同期が必要になります。ロードバランサーの選択より先に、ここが整っているかを確認してください。切り替え作業はバックアップを取ったうえで、ステージング環境の検証を経てから行います。

まとめ

Azure Load Balancer は L4 のマネージドサービスで、TLS 終端や URL での振り分けは行わない
HAProxy は L4/L7 を細かく制御できるが、冗長化・更新・証明書管理は自分で担う
セッション固定は Azure Load Balancer では送信元 IP ベース、HAProxy では Cookie も使える。WordPress は設定をそろえれば固定なしで動かせることが多い
Azure では Keepalived による仮想 IP の引き継ぎがそのまま使えないため、Azure Load Balancer の後ろに HAProxy を複数台置く構成がよく使われる
L7 をマネージドで済ませたい場合は Application Gateway や Front Door も比較対象に入れる

Azure で仮想マシンを構築する手順