Azure Load Balancer規則の設定方法を徹底解説！フロントエンドIPとバックエンドプールを紐付けるコツ

Azure Load Balancer規則の作成｜フロントエンドIPとバックエンドプールの紐付け

先生と生徒の会話形式で理解しよう

生徒

「Azure（アジュール）でWebサーバーを複数台動かしているのですが、ユーザーからのアクセスをうまく振り分けるにはどうすればいいですか？」

先生

「それならAzure Load Balancer（アジュールロードバランサー）の出番ですね。特に負荷分散規則の設定が重要になります。」

生徒

「負荷分散規則...。具体的にフロントエンドIPとバックエンドプールをどうやって紐付ける（ひもづける）のでしょうか？」

先生

「初心者の方でも迷わないように、ポータルでの設定手順や仕組みを丁寧に解説していきますね！」

1. Azure Load Balancerの基本構造を知ろう

Azure Load Balancer（負荷分散装置）は、外部からの通信を複数の仮想マシン（カソウマシン）に効率よく割り振るためのサービスです。クラウド環境でシステムを安定稼働させるためには欠かせない要素です。この仕組みを理解するために、まずは主要な3つのコンポーネントを覚えましょう。

一つ目はフロントエンドIP構成です。これは、インターネット側からアクセスしてくるユーザーが最初に見つける「窓口」となるIPアドレスのことです。二つ目はバックエンドプールです。これは、実際に処理を行うサーバー（仮想マシン）のグループを指します。そして三つ目が、今回メインで解説する負荷分散規則（フカブンサンキソク）です。これは、「どの窓口（フロントエンド）に来た通信を、どのサーバーグループ（バックエンド）に流すか」を決めるルールのことです。

歴史的には、ハードウェアのロードバランサーが物理的なデータセンターで使われてきましたが、現在はAzureのようなクラウド上でソフトウェアとして提供されるのが一般的になりました。これにより、急なトラフィックの増加にも柔軟に対応できる「スケーラビリティ」が確保されています。

2. フロントエンドIPとバックエンドプールの関係性

フロントエンドIPとバックエンドプールを紐付ける作業は、いわば「交通整理」のようなものです。例えば、あなたがショッピングサイトを運営しているとします。ユーザーがURLを叩いてアクセスするのはフロントエンドIPです。しかし、一つのサーバーだけではアクセスが集中したときにパンクしてしまいます。そこで、バックエンドプールに複数のサーバーを用意しておき、規則（ルール）を作って順番に通信を流すのです。

この紐付けが行われていないと、Azure Load Balancerはどこにパケットを運べばよいか分からず、ユーザーにはエラーが表示されてしまいます。設定の際は、プロトコル（TCPやUDP）やポート番号を正確に指定する必要があります。

3. 負荷分散規則の作成手順

それでは、Azureポータルでの具体的な設定手順を見ていきましょう。まず、作成済みのLoad Balancerのリソースを開きます。左側のメニューから「負荷分散規則」を選択し、「追加」ボタンをクリックします。ここで設定する主な項目は以下の通りです。

名前： 規則を識別するための任意の名前（例：web-rule-80）
フロントエンドIPアドレス： 事前に作成したパブリックIPまたは内部IPを選択
バックエンドプール： 通信を飛ばしたいサーバーグループを選択
プロトコル： 通常のWebサイトならTCPを選択
ポート： 80（HTTP）や443（HTTPS）など
バックエンドポート： サーバー側で待ち受けているポート番号

これらの項目を正しく紐付けることで、初めて通信が流れるようになります。初心者の方がよくつまずくポイントは、バックエンドポートの指定ミスです。フロントエンドが80番でも、サーバー内のアプリが8080番で動いているなら、バックエンドポートには8080を指定しなければなりません。

4. 正常性プローブの役割と紐付け

規則を作成する際、必ずセットで設定するのが「正常性プローブ（セイジョウセープローブ）」です。これは、バックエンドプール内のサーバーが元気に動いているかどうかを定期的にチェックする仕組みです。もし、あるサーバーが故障して応答しなくなった場合、負荷分散規則はこの正常性プローブの結果を見て、故障したサーバーへの通信を自動的にストップします。

この自己修復のような仕組みがあるおかげで、ユーザーはサーバーの故障に気づくことなくサイトを利用し続けることができます。規則の設定画面で、どの正常性プローブを使用するかを選択する箇所があるため、必ず適切なプローブを指定しましょう。

5. セッション永続化の設定

負荷分散規則には「セッション永続化（エイゾクカ）」という高度な設定もあります。通常、ロードバランサーは通信をバラバラに振り分けますが、場合によっては「同じユーザーからのアクセスは、ずっと同じサーバーに送ってほしい」という状況があります。例えば、ショッピングカートの情報をサーバー内のメモリに保存している場合などです。

設定値には「なし（デフォルト）」「クライアントIP」「クライアントIPとプロトコル」があります。これを適切に選ぶことで、アプリケーションの仕様に合わせた紐付けが可能になります。ただし、特定のサーバーに負荷が偏る可能性があるため、利用には注意が必要です。

6. ネットワークセキュリティグループとの連携

規則を作成して紐付けが完了しても、通信が通らないことがあります。その原因の多くは、NSG（ネットワークセキュリティグループ）の設定です。Azure Load Balancerの規則で80番ポートを許可しても、仮想マシンに紐付いているNSGで80番がブロックされていたら元も子もありません。ロードバランサーからの通信を許可する受信規則をNSGにも追加することを忘れないでください。

ここで、Azureの環境をスクリプトで確認したり操作したりする際に役立つコード例を紹介します。まずは、現在のLoad Balancerの規則を一覧表示するAzure CLIのコマンドです。


az network lb rule list --lb-name MyLoadBalancer --resource-group MyResourceGroup
{
  "name": "myFirstRule",
  "frontendPort": 80,
  "backendPort": 80,
  "protocol": "Tcp"
}

次に、PowerShellを使用して特定の規則の詳細を取得する例です。インフラの自動化（オートメーション）には欠かせない知識ですね。


$lb = Get-AzLoadBalancer -Name "MyLoadBalancer" -ResourceGroupName "MyResourceGroup"
$rule = Get-AzLoadBalancerRuleConfig -Name "web-rule" -LoadBalancer $lb
Write-Output $rule.FrontendPort

7. トラブルシューティングと確認方法

紐付けがうまくいかない時の確認手順をまとめます。まず、Azureポータルの「診断と解決」ツールを使ってみましょう。ここでは、フロントエンドからバックエンドまでの疎通確認を自動で行ってくれます。また、バックエンドプールの各仮想マシンの状態が「Running（実行中）」になっているかも基本ですが重要です。

また、簡単なC#プログラムを使って、自身のサーバーがどのIPからリクエストを受けているかを確認するデバッグコードを書いてみましょう。これでロードバランサー経由の通信が正しく届いているかテストできます。


using System;
using System.Net;

class Checker
{
    static void Main()
    {
        string hostName = Dns.GetHostName();
        IPAddress[] adrList = Dns.GetHostAddresses(hostName);
        foreach (IPAddress address in adrList)
        {
            Console.WriteLine("サーバーのIPアドレス: " + address.ToString());
        }
    }
}


サーバーのIPアドレス: 10.0.0.4

8. データベース接続との紐付けを考える

Webサーバーの負荷分散ができたら、次はデータベース（DB）との接続についても考慮する必要があります。負荷分散された複数のサーバーから一つのデータベースへアクセスする際、接続文字列の管理が重要です。以下は、SQL Serverへ接続する際の簡単なコード例です。


-- 現在の接続数を確認するSQL
SELECT 
    des.program_name, 
    des.login_name, 
    count(des.session_id) AS connection_count
FROM sys.dm_exec_sessions AS des
GROUP BY des.program_name, des.login_name;

実行結果のイメージは以下の通りです。複数のサーバー（Web1, Web2など）から均等に接続が来ているかを確認するのに役立ちます。


program_name | login_name | connection_count
-------------+------------+-----------------
Web-Server-1 | admin_user | 15
Web-Server-2 | admin_user | 14
Azure-Portal | dev_user   | 2

このように、Azure Load Balancerの規則設定は、単なるネットワークの設定に留まらず、システム全体のアーキテクチャやデータベース接続の安定性にも直結する非常に重要な作業です。フロントエンドIPとバックエンドプールの紐付けをマスターして、止まらないシステム作りを目指しましょう。

まとめ

Azure Load Balancer（アジュールロードバランサー）を活用したシステム構築において、フロントエンドIPとバックエンドプールを正しく紐付ける「負荷分散規則」の設定は、インフラエンジニアやクラウド開発者にとって避けては通れない最重要項目です。この記事を通じて、単なる画面操作の手順だけでなく、プロトコル（TCP/UDP）の選択や、ポート番号の整合性、そしてシステムの可用性を支える「正常性プローブ」の重要性についても深く理解できたのではないでしょうか。

クラウドネイティブな環境では、サーバーの台数を動的に増減させる「スケーリング」が頻繁に行われます。そのため、手動での設定だけでなく、Azure CLIやPowerShellを用いた自動化の知識も非常に価値が高まっています。特に、バックエンドポートとフロントエンドポートが異なる場合のポートフォワーディング的な考え方や、セッション永続化（スティッキーセッション）が必要なアプリケーション特性の判断は、実務レベルでのトラブルを未然に防ぐ鍵となります。

また、ネットワークの疎通確認においては、NSG（ネットワークセキュリティグループ）の受信セキュリティ規則との整合性を常に意識してください。ロードバランサー側で許可しても、仮想マシン側のファイアウォールでブロックされていれば通信は成立しません。データベース層との連携も含め、システム全体を俯瞰して「どこで通信が止まっているのか」を切り分ける能力を養っていきましょう。

Azure環境を管理する便利なスクリプト例

運用管理の現場では、設定した負荷分散規則が意図通りに動作しているかをプログラムでチェックすることが多々あります。ここでは、C#を使用して特定のネットワークインターフェース情報を取得し、ロードバランサー配下にあるサーバーの健全性を確認する際の補助コードを紹介します。


using System;
using System.Net.NetworkInformation;

namespace AzureNetworkChecker
{
    class Program
    {
        static void Main(string[] args)
        {
            NetworkInterface[] adapters = NetworkInterface.GetAllNetworkInterfaces();
            foreach (NetworkInterface adapter in adapters)
            {
                if (adapter.OperationalStatus == OperationalStatus.Up)
                {
                    Console.WriteLine("アダプター名: " + adapter.Name);
                    Console.WriteLine("状態: " + adapter.OperationalStatus);
                    Console.WriteLine("説明: " + adapter.Description);
                    Console.WriteLine("----------------------------------");
                }
            }
        }
    }
}


アダプター名: eth0
状態: Up
説明: Microsoft Hyper-V Network Adapter
----------------------------------

データベース接続状態の監視とSQL活用

負荷分散が正常に行われている場合、バックエンドのデータベース（Azure SQL Databaseなど）への接続も分散されるはずです。接続元の情報を確認するためのSQLをさらに深掘りしてみましょう。


id | server_name | client_ip    | status      | last_request_time
---+-------------+--------------+-------------+--------------------
1  | WEB-SERVER-A| 10.0.0.4     | online      | 2026-03-30 10:00:01
2  | WEB-SERVER-B| 10.0.0.5     | online      | 2026-03-30 10:00:05
3  | WEB-SERVER-C| 10.0.0.6     | idle        | 2026-03-30 09:55:20
4  | WEB-SERVER-D| 10.0.0.7     | online      | 2026-03-30 10:00:10

上記のテーブル状態を確認し、以下のSQLを実行することで、特定のIP（バックエンドプールの各サーバー）からのアクティブなセッションを特定できます。


SELECT 
    client_net_address,
    local_net_address,
    connection_id,
    num_reads,
    num_writes
FROM sys.dm_exec_connections
WHERE client_net_address IS NOT NULL
ORDER BY num_reads DESC;


client_net_address | local_net_address | connection_id | num_reads | num_writes
-------------------+-------------------+---------------+-----------+-----------
10.0.0.4           | 10.0.0.10         | UUID-001      | 5420      | 1200
10.0.0.5           | 10.0.0.10         | UUID-002      | 5100      | 1150
10.0.0.7           | 10.0.0.10         | UUID-003      | 4890      | 980

レガシーシステムとの連携（COBOLの例）

基幹システムなどでは、Azure上の仮想マシン内でCOBOLプログラムを動かし、ロードバランサー経由でデータ処理を分散させるケースもあります。その際のログ出力処理のイメージです。


IDENTIFICATION DIVISION.
PROGRAM-ID. LB-LOG-WRITER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-LOG-MSG PIC X(50) VALUE "LOAD BALANCER ACCESS LOGGED".
PROCEDURE DIVISION.
    DISPLAY WS-LOG-MSG.
    STOP RUN.

Linuxサーバーでの疎通確認コマンド

バックエンドの仮想マシンがLinuxの場合、自身のIPアドレスやロードバランサーからの通信を確認するために以下のコマンドが頻用されます。


ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0d:3a:af:75:32 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever

先生と生徒の振り返り会話

生徒

「先生、ありがとうございました！負荷分散規則（ふかぶんさんきそく）の設定が、ただの紐付け以上の意味を持っていることがよく分かりました。特に、バックエンドポートとフロントエンドポートが違っていても通信ができる点は驚きました。」

先生

「そうですね。ポートフォワーディングのような役割も果たせるのがロードバランサーの強みです。設定を間違えると、インターネットから全く繋がらなくなるので、ポート番号の入力には細心の注意を払いましょう。」

生徒

「正常性プローブ（せいじょうせいぷろーぶ）についても、もしこれが設定されていなかったら、壊れたサーバーにずっとアクセスを送り続けてしまうということですよね？」

先生

「その通りです。ユーザーにとっては『たまにエラーが出るサイト』になってしまい、信頼を失います。自動で切り離してくれるこの仕組みこそが、クラウドでの可用性（かようせい）を支える心臓部なんですよ。」

生徒

「あと、NSG（ねっとわーくせきゅりてぃぐるーぷ）の設定を忘れがちだというお話も刺さりました。どれだけロードバランサー側で頑張っても、門番であるNSGが閉まっていたら意味がないですもんね。」

先生