Azure Load Balancer正常性プローブ設計を徹底解説！障害検知の設定術

1. Azure Load Balancerと正常性プローブの基本

1. Azure Load Balancerと正常性プローブの基本

Azure Load Balancer（アジュール ロード バランサー）は、インターネットからの通信を複数の仮想マシン（VM）に均等に振り分ける「負荷分散装置（ふかぶんさんそうち）」です。これにより、一つのサーバーにアクセスが集中してパンクするのを防ぎます。

しかし、振り分け先のサーバーが故障して動かなくなっていたらどうでしょうか？ロードバランサーがそれを知らずに通信を送り続けると、ユーザーにはエラー画面が表示されてしまいます。ここで登場するのが正常性（せいじょうせい）プローブです。

正常性プローブは、バックエンドにあるサーバー群に対して「生きていますか？」と定期的に信号を送ります。返事があれば「正常」、返事がなければ「異常」と判断し、異常なサーバーには通信を送らないように自動で制御してくれるのです。この仕組みにより、システムの可用性（かようせい）、つまり「止まらない仕組み」が維持されます。

2. 正常性プローブの種類と選び方

2. 正常性プローブの種類と選び方

正常性プローブには、主に「TCP」と「HTTP/HTTPS」の二種類があります。どちらを選ぶべきかは、監視したいアプリの内容によって決まります。

例えば、Webサーバー（IISやApacheなど）を動かしている場合、サービス自体は起動していても、プログラムのエラーで画面が表示されないことがあります。TCPプローブでは「接続ができる」ので正常と判断してしまいますが、HTTPプローブであれば「エラー画面（500エラーなど）」を検知して異常と判断できるため、より高度な障害検知が可能です。

3. 障害検知の精度を決める三つの設定値

3. 障害検知の精度を決める三つの設定値

正常性プローブの設定画面には、初心者が迷いやすい三つの項目があります。これらの数値をどう設定するかで、障害検知のスピードと安定性が決まります。

• 間隔（Interval）： 何秒ごとにチェックを行うか。規定値は5秒です。
• 異常しきい値（Unhealthy Threshold）： 何回連続で失敗したら「故障」とみなすか。規定値は2回です。
• プローブパス： HTTP/HTTPSの場合に、どのページをチェックするか（例：/healthcheck.html）。

例えば、間隔を5秒、しきい値を2回に設定した場合、5秒 × 2回 ＝ 10秒 で障害を検知します。最短で10秒以内に異常なサーバーを切り離せる計算になります。

4. 精度を高めるための最適な設計術

4. 精度を高めるための最適な設計術

「とにかく早く障害を見つけたいから、間隔を1秒にしよう！」と考えるかもしれませんが、注意が必要です。チェックの間隔を短くしすぎると、サーバーに負荷がかかり、通常のユーザー通信に影響が出る「プローブによる自爆」が起こる可能性があります。

一般的には、以下のバランスが推奨されます。

監視対象に重いプログラム（データベースに接続して複雑な計算をするページなど）を指定すると、監視そのものが原因でサーバーが重くなるため、監視専用の軽いファイルを用意するのがプロの技です。

5. C#で正常性チェック用APIを作成する例

5. C#で正常性チェック用APIを作成する例

最近のモダンな開発では、ASP.NET Coreの「Health Checks」機能を使って、プログラム側で自分の健康状態を報告する仕組みを作ることが多いです。以下は、簡単な正常性チェック用のエンドポイントを作成する例です。

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("[controller]")]
public class HealthController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        // データベース接続チェックなどのロジックをここに書く
        bool isDatabaseHealthy = CheckDatabase();

        if (isDatabaseHealthy)
        {
            return Ok("Healthy"); // 200 OKを返す
        }
        else
        {
            return StatusCode(503, "Service Unavailable"); // 503エラーを返す
        }
    }

    private bool CheckDatabase()
    {
        // 簡易的なチェック
        return true;
    }
}

このように、単に「サーバーが動いているか」だけでなく、「データベースと通信できているか」まで含めてチェック結果を返すように設計すると、より信頼性の高いシステムになります。

6. ログを確認して正常性プローブの状態を把握する

6. ログを確認して正常性プローブの状態を把握する

設定が終わったら、実際にどのようにチェックされているかを確認しましょう。Azureのリソースログ（診断設定）を有効にすると、プローブの成功・失敗の履歴を見ることができます。もしサーバーが頻繁に切り離されているなら、ネットワークの瞬断やサーバーの負荷を疑う必要があります。

LinuxサーバーでWebサーバーのアクセスログを確認すると、ロードバランサーからのアクセスが頻繁に来ていることがわかります。以下は、Apacheのログを確認するコマンドの例です。

tail -f /var/log/apache2/access.log
168.63.129.16 - - [30/Mar/2026:10:00:01 +0900] "GET /health.html HTTP/1.1" 200 10
168.63.129.16 - - [30/Mar/2026:10:00:06 +0900] "GET /health.html HTTP/1.1" 200 10

ここで表示されている「168.63.129.16」というIPアドレスは、Azureの特殊なパブリックIPアドレスで、ロードバランサーなどのプラットフォームサービスが通信を行うために使用されます。このIPからの通信をファイアウォール（NSG）で拒否してしまうと、正常性プローブが失敗して全サーバーがダウン判定されてしまうので注意してください。

7. 複数のルールを設定して柔軟に運用する

7. 複数のルールを設定して柔軟に運用する

Azure Load Balancerでは、一つのロードバランサーに対して複数の正常性プローブを設定できます。例えば、ポート80（HTTP）用とポート443（HTTPS）用で個別のチェックを行うことができます。

また、C#で作成したバッチ処理サーバーなど、Web画面がないプログラムの監視には、TCPプローブを使って「プロセスがポートをリッスンしているか」だけを確認するのが一般的です。以下のコードは、TCPポートを開いて待機するシンプルな例です。

using System.Net;
using System.Net.Sockets;

TcpListener server = new TcpListener(IPAddress.Any, 8080);
server.Start();
Console.WriteLine("正常性プローブの待機を開始しました（ポート: 8080）");

while (true)
{
    // ロードバランサーからの接続を受け入れてすぐに閉じる
    using (TcpClient client = server.AcceptTcpClient())
    {
        // 接続されるだけで「正常」とみなされる
    }
}

8. データベースの状態をプローブの結果に反映させる

8. データベースの状態をプローブの結果に反映させる

より高度な運用を目指すなら、データベースの内容に基づいてプローブの戻り値を変える方法があります。例えば、メンテナンスモードを管理するテーブルを用意し、特定のフラグが立っている間だけ503エラーを返すようにします。これにより、Azureポータルを操作せずに、データベースの値を書き換えるだけで安全にサーバーを切り離す（デプロイ作業など）ことが可能になります。

id | server_name | is_active | maintenance_mode
---+-------------+-----------+-----------------
1  | WebServer01 | 1         | 0
2  | WebServer02 | 1         | 1
3  | WebServer03 | 0         | 0

上記のテーブルがある場合、WebServer02は「maintenance_mode」が1なので、プローブに対してエラーを返し、ロードバランサーからの新規接続を停止させることができます。SQLで状態を更新する例を見てみましょう。

UPDATE server_status
SET maintenance_mode = 1
WHERE server_name = 'WebServer01';

id | server_name | is_active | maintenance_mode
---+-------------+-----------+-----------------
1  | WebServer01 | 1         | 1
2  | WebServer02 | 1         | 1
3  | WebServer03 | 0         | 0

このように、正常性プローブは単なる故障検知だけでなく、計画的なメンテナンスにも活用できる非常に強力なツールなのです。

9. トラブルシューティングのポイント

9. トラブルシューティングのポイント

「設定は正しいはずなのに、なぜか異常（Unhealthy）と判定される！」というときは、以下のチェックリストを確認してください。

特にクラウド初心者がハマりやすいのが「NSG」の設定です。デフォルトでは許可されていますが、セキュリティを厳しくしすぎると、守り神であるロードバランサーのチェックまで弾いてしまうので注意しましょう。

まとめ

まとめ

Azure Load Balancerの運用において、システムの高可用性を支える心臓部とも言えるのが正常性プローブ（Health Probe）の設計です。単にサーバーが起動しているかどうかを確認するだけでなく、アプリケーションの内部状態やデータベースとの接続性まで考慮した設計を行うことで、ユーザーにエラーを返さない堅牢なシステムを構築できます。特に、TCPプローブとHTTP/HTTPSプローブの使い分けは重要で、プロトコルの特性を理解した上で、適切な監視パスを設定することが求められます。

また、監視の「間隔」や「異常しきい値」の設定は、障害検知のスピードとシステム負荷のトレードオフの関係にあります。最短で障害を検知したいからといって極端に短い間隔を設定すると、監視通信そのものがサーバーのリソースを圧迫し、パフォーマンス低下を招く恐れがあります。標準的な5秒から15秒程度の間隔をベースに、システムの要件に合わせて微調整を行うのがベストプラクティスです。さらに、Azure特有の共有IPアドレス（168.63.129.16）からの通信許可をネットワークセキュリティグループ（NSG）で正しく設定することも、構築時の必須項目として覚えておきましょう。

実践的な正常性プローブの活用例

開発現場では、単純な静的ファイルの配置だけでなく、C#（ASP.NET Core）などを利用して、より詳細なヘルスチェックロジックを実装することが推奨されます。例えば、外部APIの応答速度やディスク空き容量、メモリ使用率などをチェックし、閾値を超えた場合に一時的に「異常」を返すことで、致命的なクラッシュが発生する前にトラフィックを他の健全なサーバーへ逃がすといった高度な制御が可能です。

以下に、C#でより詳細なチェックを行うためのサンプルコードを示します。このコードでは、内部のサービス状態を多角的に評価し、適切なステータスコードを返却しています。

using Microsoft.AspNetCore.Mvc;
using System.Threading.Tasks;

[ApiController]
[Route("api/[controller]")]
public class AdvancedHealthController : ControllerBase
{
    // 複雑なシステムチェックをシミュレーションするメソッド
    [HttpGet("detailed")]
    public async Task<IActionResult> CheckFullSystem()
    {
        // 1. データベース接続の確認
        bool isDbOk = await Task.Run(() => CheckDatabaseConnectivity());
        
        // 2. 外部ストレージの確認
        bool isStorageOk = await Task.Run(() => CheckStorageAccess());

        // 全てのチェックがパスした場合のみ200 OKを返す
        if (isDbOk && isStorageOk)
        {
            return Ok(new { status = "Success", message = "All systems operational" });
        }
        else
        {
            // 異常時は503 Service Unavailableを返し、ロードバランサーに切り離しを促す
            return StatusCode(503, new { status = "Error", message = "System degradation detected" });
        }
    }

    private bool CheckDatabaseConnectivity() => true; // 実際はDB接続確認を記述
    private bool CheckStorageAccess() => true;    // 実際はストレージ確認を記述
}

このように、APIベースの正常性プローブを設計することで、インフラ層だけでなくアプリケーション層の障害も確実に捉えることができます。また、運用フェーズにおいては、SQLデータベースを用いてサーバーの稼働状態を動的に制御する手法も非常に有効です。メンテナンス時に特定のサーバーをロードバランサーから安全に切り離す「ドレイニング（Draining）」のような操作も、正常性プローブの戻り値を操作することでプログラムから制御可能になります。

最新のクラウドネイティブな環境では、インフラのコード化（IaC）と共に、こうした観測可能性（Observability）を高める設計が不可欠です。Azure Load Balancerの正常性プローブをマスターすることは、信頼性の高いクラウドエンジニアへの第一歩と言えるでしょう。

server_id | hostname    | current_load | is_maintenance
----------+-------------+--------------+---------------
101       | WebApp-VM01 | 45%          | 0
102       | WebApp-VM02 | 12%          | 1
103       | WebApp-VM03 | 0%           | 1

-- WebApp-VM02のメンテナンスモードを解除して復帰させる
UPDATE server_inventory
SET is_maintenance = 0
WHERE hostname = 'WebApp-VM02';

server_id | hostname    | current_load | is_maintenance
----------+-------------+--------------+---------------
101       | WebApp-VM01 | 48%          | 0
102       | WebApp-VM02 | 5%           | 0
103       | WebApp-VM03 | 0%           | 1