2026年6月6日

Azure Load Balancer でヘルスチェック（正常性プローブ）を設定する方法

ネットワーク・接続

Azure Load Balancer のヘルスチェックは「正常性プローブ」と呼ばれ、バックエンドの仮想マシンへ定期的に接続し、応答があるものだけに新しい通信を振り分けます。設定で迷いやすいのは、プローブの種類（TCP か HTTP か）、確認用のURL、そしてプローブの送信元 168.63.129.16 を通す設定の3点です。この記事では、WordPress を複数の仮想マシンで動かす構成を例に、プローブの作り方、つまずきやすい点、動作の確認方法を説明します。

正常性プローブの基本

Azure Load Balancer はレイヤー4（TCP/UDP）のロードバランサーです。プローブの結果をもとに、バックエンドプールのどのインスタンスへ新しい接続を送るかを決めます。プローブには次の種類があります。

TCP: 指定したポートで接続が確立できれば正常とみなします。Webサーバーのプロセスが動いているかだけを見ます。
HTTP: 指定したパスへリクエストを送り、ステータスコード200が返れば正常とみなします。200以外は、リダイレクトの301や302も含めて異常扱いになります。
HTTPS: HTTP と同じ判定を TLS 経由で行います。証明書の検証は行われません。

Basic SKU のロードバランサーは提供が終了しているため、これから作る場合は Standard SKU が前提です（2026年10月現在）。間隔や失敗とみなす回数などの既定値、ポータルの項目名は更新で変わることがあるため、設定時には Microsoft Learn の正常性プローブのページで現在の値を確認してください。

URLのパスで振り分け先を変えたい、ロードバランサーで HTTPS を終端したい、といった要件はレイヤー7の機能なので、Azure Application Gateway や Azure Front Door の領域です。Load Balancer のプローブは「そのインスタンスに通信を送ってよいか」の判定だけを担います。

WordPress 向けの確認用URLを用意する

WordPress のページをそのまま使わない理由

HTTP プローブでトップページや /wp-login.php を指定すると、多くの場合うまく動きません。プローブはインスタンスのIPアドレス宛てに送られるため、WordPress は「サイトのURLと違うホスト名で来た」と判断して、正規のURLへリダイレクトします。リダイレクトは200ではないので、プローブは異常と判定し、すべてのインスタンスが外されてしまいます。HTTP から HTTPS へのリダイレクトを設定している場合も同じです。

また、PHP やデータベースの処理を伴うページは、プローブのたびにサーバーへ負荷をかけます。

Webサーバーで軽い確認用URLを返す

nginx を使う場合、IPアドレス宛てのリクエストを受ける既定のサーバーブロックに、確認用のURLを用意します。設定を変える前に現在の設定ファイルを控えておいてください。

server {
    listen 80 default_server;
    server_name _;

    location = /healthz {
        access_log off;
        allow 168.63.129.16;
        allow 127.0.0.1;
        deny all;
        default_type text/plain;
        return 200 "ok\n";
    }

    location / {
        return 444;
    }
}

/healthz はロードバランサーのプローブとサーバー自身からだけ応答し、それ以外の IP アドレス直打ちのアクセスは接続を閉じます。WordPress 本体の server ブロック（サイトのドメイン名を server_name に書いたもの）はそのまま残します。

sudo nginx -t && sudo systemctl reload nginx
curl -i http://127.0.0.1/healthz

HTTP/1.1 200 OK と ok が返れば準備できています。

データベースまで確認するかどうか

PHP からデータベースへの接続まで確認するプローブにすると、「Webサーバーは動いているがDBにつながらない」インスタンスを外せます。一方で、データベースそのものが止まった場合は全インスタンスが同時に異常となり、ロードバランサーがどこにも通信を送れなくなります。データベースの障害は別の監視で検知し、プローブはインスタンス単体の状態だけを見る、と役割を分けるほうが扱いやすい構成です。

プローブを作成して負荷分散規則に割り当てる

ポータルでは、ロードバランサーの「正常性プローブ」の画面から追加し、負荷分散規則でそのプローブを選びます。Azure CLI では次のように作成します。リソース名は例なので置き換えてください。

# HTTP プローブを作成する
az network lb probe create \
  --resource-group wp-rg \
  --lb-name wp-lb \
  --name http-healthz \
  --protocol Http \
  --port 80 \
  --path /healthz \
  --interval 5

# 負荷分散規則にプローブを割り当てる
az network lb rule create \
  --resource-group wp-rg \
  --lb-name wp-lb \
  --name http-rule \
  --protocol Tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name wp-frontend \
  --backend-pool-name wp-backend \
  --probe-name http-healthz

プローブのポートは、負荷分散規則のバックエンドポートと同じである必要はありません。たとえば 443 で通信を受けるサイトでも、プローブは 80 の /healthz で行う、という設定ができます。

つまずきやすい点

NSG でプローブを止めている

プローブは 168.63.129.16 から届きます。ネットワークセキュリティグループ（NSG）には、サービスタグ AzureLoadBalancer からの受信を許可する既定の規則がありますが、それより優先度の高い規則で受信をまとめて拒否していると、プローブも止まります。NSG の有効な規則を確認し、AzureLoadBalancer からのプローブ用ポートへの受信が許可されているかを見ます。

OS のファイアウォールで止めている

仮想マシン内の ufw や firewalld、Windows Defender ファイアウォールで、プローブのポートを閉じていることもあります。

sudo ufw allow from 168.63.129.16 to any port 80 proto tcp

バックエンドプールに入っていない

仮想マシンのネットワークインターフェース（またはIP構成）がバックエンドプールに登録されていないと、プローブの対象になりません。プールの一覧に対象のインスタンスが表示されているかを確認します。

動作を確認する方法

Azure Monitor のロードバランサーのメトリクスに、正常性プローブの状態を示す項目があります（ポータルでの表示名は更新で変わることがあります）。バックエンドのIPアドレスごとに分割して表示すると、どのインスタンスが外れているかが分かります。

切り替わりを確かめるには、1台の仮想マシンで Webサーバーを止め、そのインスタンスが異常になり、残りのインスタンスへ通信が送られることを確認します。この試験は本番の通信が少ない時間帯か、検証用の環境で行ってください。

# 1台で nginx を止め、プローブの状態が変わるかを見る
sudo systemctl stop nginx
# 確認後に戻す
sudo systemctl start nginx

アクセスログに /healthz が大量に記録されると分析の邪魔になるため、上の設定例では access_log off; で記録を止めています。

まとめ

Azure Load Balancer の正常性プローブは TCP・HTTP・HTTPS の3種類で、HTTP系は200だけを正常とみなします。
WordPress のページをプローブに使うと、IPアドレス宛てのリクエストがリダイレクトされて失敗しやすいため、Webサーバーで軽い確認用URLを用意します。
プローブの送信元 168.63.129.16 を、NSG と OS のファイアウォールの両方で許可します。
データベースまで確認するかは、全台が同時に外れる危険と合わせて判断します。
メトリクスで状態を確認し、1台を止めて切り替わりを試してから本番で使います。