Azure Load Balancer Health Probesを理解するための前提
Standard Load Balancerのhealth probeはTCP/HTTP/HTTPSを使用でき、probe結果は主に新規inbound flowの配布先を決める。 IPv4 probe sourceは168.63.129.16。NSGではAzureLoadBalancer service tagを使って必要portを許可する設計が基本。
probe失敗時、unhealthy instanceへの新規接続は停止する。既存TCP flowの扱いはprobe全体/個別downで異なるため実験で固定する。 Standardでは全probe down時も既存TCP flowは継続する設計。healthを「即座に全sessionを切断する機構」と誤認しない。
HTTP/HTTPS probeはapplication readinessを表すpathを返させる。外部dependencyまで含めるかはfailure domainと連動させる。 HTTPS probeはclient certificateによるmutual authenticationをサポートしない。mTLS専用endpointをそのままprobe targetにしない。
Control plane / Data plane / Observability
Azure platformのprobe sourceからbackend portへ到達する。client pathとはsourceが異なる。
probe成功backendだけが新規inbound flowのcandidateになる。
TCP openだけを見るかHTTP(S) readinessまで見るかでfailover意味が変わる。
Client-to-backend path
- Azure platformが設定intervalでbackend probe portへ接続する。
- TCPならhandshake、HTTP/HTTPSならresponse statusを評価する。
- thresholdに従ってbackend health stateを更新する。
- load-balancing ruleはhealthy backend setを新規flow選択に利用する。
- unhealthy backendへの新規flow配布を停止する。
- recovery後、successful probesを満たしたbackendをhealthy setへ戻す。
仕組みを分解する
health probeは「本番trafficと同じsource/Host/header/dependency」を完全再現するものではありません。probe 200 + user 503なら、probe pathと本番pathの差、NSG source、application routing、TLS/SNIなどを比較します。逆にprobe downでもapp process自体が生きていることはあり、probe contractが過剰にdependencyを抱えていないかを確認します。
運用時はresource configurationだけで完了判定せず、実clientからの名前解決、TCP/TLS handshake、HTTP status、backend側のsource IP/Host/header、health telemetryを同じtimestampで揃えます。load balancer/proxyがhealthyでもapplication dependencyが壊れている場合があり、逆にbackend applicationが正常でもhealth probe条件やrouting ruleが不整合ならtrafficは到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| TCP vs HTTP(S) | process/listenだけでよければTCP、application readinessを判定したければHTTP(S)。 |
| Path | /healthz等は軽量にし、何をhealthyと定義するかSLOと合わせる。 |
| Threshold/interval | 短すぎるflapと長すぎるdetectionを避け、実障害/rolling maintenanceで試験する。 |
| NSG | AzureLoadBalancer service tag→probe portを許可し、Internet全許可で代替しない。 |
確認手順
Read-only verification
- probe protocol/port/interval/thresholdと「Used by」ruleを確認する。
- backendで168.63.129.16からのprobe到達とresponseをpacket/application logで確認する。
- HTTP(S) probe pathをbackend自身からcurlしてstatusを比較する。
- 意図的に1 backendだけreadinessを落とし、新規flow配布停止と復帰を検証する。
Evidence to keep
- resource ID / subscription / region / frontend / backend targetを保存し、同名resource取り違えを防ぐ。
- DNS answer、source IP、destination IP/port、Host/SNI、health status、timestampを同じincident recordへ残す。
- 変更前後で同じclient journeyをnew connectionとして再実行する。
- Portal表示だけでなくCLI/PowerShell/APIまたはlogsを併用し、観測面の一時差を識別する。
az network lb probe list -g <rg> --lb-name <lb> -o jsonc
az network lb rule list -g <rg> --lb-name <lb> --query "[].{name:name,probe:probe.id}" -o table(Get-AzLoadBalancer -ResourceGroupName <rg> -Name <lb>).Probes | Format-List *障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| Probe unhealthy | listener/path/status mismatch | backend log + probe config | direct curl/TCP test |
| Probe packetが来ない | NSG/guest firewall | packet capture/effective NSG | AzureLoadBalancer allow |
| Probe healthyだがuser failure | probeと本番journey差 | Host/path/TLS/application log | L7 dependencyを比較 |
| flapping | threshold/overloaded app | probe latency/CPU/log | interval/threshold/readiness改善 |
| maintenanceでtrafficが来る | probe drain手順不足 | probe state + new connection | readinessを先にdown |
変更時の確認と rollback
- probe変更前のprotocol/port/path/interval/thresholdを保存する。
- readiness endpoint変更はapp releaseと同期し、旧versionとの互換を確認する。
- NSG変更はprobe sourceだけに限定して戻せるようrule単位で管理する。
- rollback後はprobe stateだけでなく新規client flowのbackend分布も再確認する。
Current notes — 2026-09-11
Microsoft Learnの2026-08更新ではStandard probeがTCP/HTTP/HTTPSを扱い、IPv4 source 168.63.129.16、全probe down時の既存TCP flow継続が明記されている。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。