Azure Load Balancerの完全ガイド：負荷分散でアプリケーションのパフォーマンスを向上させる

Webサイトやアプリケーションの利用者が増加すると、単一のサーバーでは処理しきれなくなることがあります。そんな時に活躍するのがロードバランサーです。

Azure Load Balancerは、Microsoftが提供するクラウドベースの負荷分散サービスで、複数のサーバーにトラフィックを効率的に分散し、システムの可用性とパフォーマンスを向上させます。

本記事では、Azure Load Balancerの基本概念から実際の作成方法まで、初心者の方でも理解できるよう丁寧に解説します。負荷分散の仕組み、SKUの選び方、料金体系、そして実践的な作成手順まで、Azure Load Balancerを導入する際に必要な知識を網羅的にカバーしています。

これからAzureを学び始める方や、システムの高可用性を実現したい方にもわかりやすいように解説します。

Azure Load Balancerとは？
Azure Load Balancerが対応可能な負荷分散方法
Azure Load Balancerの種類
Azure Load Balancerの構成要素
Azure Load Balancerの料金
Azure Load Balancerの作成方法
まとめ

Azure Load Balancerとは？

ロードバランサーは、複数のサーバーに対してトラフィック（通信）を効率的に分散させる仕組みです。まるで交通整理をする警察官のように、たくさんのリクエストが来た時に、どのサーバーに処理をお願いするかを決めてくれます。

例えば、あなたがWebサイトを運営していて、1台のサーバーだけで運用していたとします。突然アクセスが急増した場合、そのサーバーは処理しきれずにダウンしてしまう可能性があります。しかし、3台のサーバーを用意してロードバランサーを設置すれば、アクセスを3台に分散できるため、安定したサービス提供が可能になります。

負荷分散とは？

負荷分散とは、システムにかかる処理の負荷を複数のリソースに分散させることです。これにより以下のメリットが得られます：

可用性の向上: 1台のサーバーが故障しても、他のサーバーが処理を継続できます
パフォーマンスの向上: 複数のサーバーで処理を分担することで、レスポンス時間が改善されます
拡張性の確保: トラフィックの増加に応じて、サーバーを追加することで対応できます

Azure Load Balancerは、Microsoftが提供するクラウドベースのロードバランシングサービスで、これらの機能をAzure環境で簡単に実現できます。

Azure Load Balancerが対応可能な負荷分散方法

Azure Load Balancerは、シンプルで高性能なレイヤー4負荷分散に特化しており、以下の分散方法をサポートしています。

ラウンドロビン（均等負荷分散）

Azure Load Balancerのデフォルトの負荷分散方法です。一般的なラウンドロビンとは少し異なり、ハッシュベースの分散を行います。

分散の仕組み:

各リクエストについて、5つの情報（送信元IP、送信元ポート、宛先IP、宛先ポート、プロトコル）を組み合わせてハッシュ値を計算
そのハッシュ値に基づいて、利用可能なバックエンドサーバーの中から送信先を決定
同じ5つの情報を持つリクエストは、常に同じサーバーに送信される

5タプルハッシュ: 送信元IP、送信元ポート、宛先IP、宛先ポート、プロトコルの組み合わせによるハッシュ値を計算して分散先を決定します。

セッション持続性（Session Affinity）

同じクライアントからのリクエストを同じサーバーに送信する機能です。ユーザーがログインした後に別のサーバーに転送されてログイン情報が失われることを防ぎます。

分散の仕組み:

クライアントからの最初のリクエストで、2つまたは3つの情報からハッシュ値を計算
そのハッシュ値に基づいて、特定のバックエンドサーバーを割り当て
同じクライアントからの後続のリクエストは、常に同じサーバーに送信される

2タプル分散: 送信元IPと宛先IPの組み合わせで分散先を決定
3タプル分散: 送信元IP、宛先IP、プロトコルの組み合わせで分散先を決定

ログイン状態の維持やショッピングカートの内容保持など、セッション情報をサーバー側で管理している場合に有効です。ただし、特定のサーバーに負荷が偏る可能性があるため、使用時は注意が必要です。

対応していない負荷分散方法

Azure Load Balancerは以下の負荷分散方法には対応していません：

重みづけラウンドロビン: サーバーごとに重み付けを設定する機能
最小接続数: 現在の接続数に基づく分散
最速応答時間: レスポンス時間を考慮した分散
動的比率: サーバーの性能に応じた動的な負荷分散

これらの機能が必要な場合は、Azure Application GatewayやAzure Front Doorなどの他のサービスを検討してください。

Azure Load Balancerの種類

Azure Load Balancerは、SKUと対象範囲の2つの軸で分類されます。適切な種類を選択することで、コストとパフォーマンスのバランスを最適化できます。

SKU

SKU（Stock Keeping Unit）は、Azure Load Balancerの機能と性能レベルを決定する重要な選択肢です。現在利用可能なSKUは以下の通りです。

Basic SKU（廃止予定）

2025年9月30日に廃止予定のため、新規作成は推奨されません。既存のBasic SKUをお使いの場合は、Standard SKUへの移行を検討してください。

Standard SKU（推奨）

Standard SKUは現在推奨されているSKUで、本格的な本番環境での使用に適しています。このSKUの最大の特徴は高可用性とゾーン冗長性です。

可用性ゾーン（Availability Zone）をサポートしており、データセンター全体の障害が発生した場合でも、他のゾーンでサービスを継続できます。ゾーン冗長構成により、単一障害点を排除し、サービスの継続性を大幅に向上させることが可能です。

高可用性: 可用性ゾーンをサポートし、データセンター全体の障害にも対応
セキュリティ: デフォルトでセキュアな設定、Network Security Group（NSG）による制御が必要
診断機能: Azure Monitorとの統合により、詳細なメトリクスとログが利用可能
スケーラビリティ: より多くのバックエンドインスタンスをサポート
SLA保証: 99.99%の可用性が保証

Gateway SKU

Gateway SKUは、サードパーティのネットワーク仮想アプライアンス（NVA）と統合するための特別なSKUです。このSKUは、高度なセキュリティ要件がある企業環境で利用されています。

透過的な挿入: トラフィックを自動的にNVAにルーティング
チェーン機能: 複数のNVAを連鎖させることが可能
高可用性: NVAの冗長性を提供

内部向けか、パブリック対応か

Azure Load Balancerは、トラフィックの送信元によって内部向けとパブリック対応の2つのタイプに分類されます。システムのセキュリティ要件とアクセス範囲によって使い分けましょう。

内部ロードバランサー（Internal Load Balancer）

内部ロードバランサーは、Azure仮想ネットワーク内でのみ動作するプライベートなロードバランサーです。

同じ仮想ネットワーク内のリソースからのみアクセス可能で、プライベートIPアドレス（例：10.0.1.4）を使用します。

インターネットから直接アクセスできないため、非常に高いセキュリティレベルを実現できます。

用途: データベースサーバー、アプリケーションサーバーなど、内部トラフィックの負荷分散
アクセス: 同じ仮想ネットワーク内のリソースからのみアクセス可能
IPアドレス: プライベートIPアドレスを使用
セキュリティ: インターネットから直接アクセスできないため、セキュリティレベルが高い
料金: 基本的に無料（データ処理料金のみ）

パブリックロードバランサー（Public Load Balancer）

パブリックロードバランサーは、インターネットからのトラフィックを受け付ける外部向けのロードバランサーです。

インターネット全体から直接アクセス可能で、パブリックIPアドレス（例：203.0.113.5）を使用し、世界中のユーザーからアクセスできるグローバル展開が可能です。

オンラインゲームの接続処理とマッチメイキングシステムや、大量のIoTデバイスからのデータ収集システムなど、大規模なトラフィック処理が必要なシステムでも威力を発揮します。

用途: Webサーバー、APIサーバーなど、インターネット向けサービスの負荷分散
アクセス: インターネットから直接アクセス可能
IPアドレス: パブリックIPアドレスを使用
スケーラビリティ: 大量のインターネットトラフィックに対応
料金: 使用量に応じた課金

Azure Load Balancerの構成要素

Azure Load Balancerは、以下の構成要素が連携することで負荷分散を実現しています。

フロントエンドIP
バックエンドプール
インバウンド規則
アウトバウンド規則

フロントエンドIP

フロントエンドIPは、クライアントがアクセスする際の窓口となるIPアドレスです。外部からの全てのリクエストを最初に受け取る重要な役割を担います。

パブリックロードバランサーの場合は、パブリックIPアドレスリソースを関連付けます。この設定により、インターネット上の任意のクライアントからアクセスできるようになります。

一方、内部ロードバランサーでは、仮想ネットワーク内のプライベートIPアドレスを使用し、同じネットワーク内のリソースからのみアクセス可能になります。

1つのロードバランサーに複数のフロントエンドIPを設定することも可能で、異なるサービスやアプリケーションに対して別々のIPアドレスを割り当てられます。また、IPv4とIPv6の両方をサポートしているため、将来的なネットワーク環境の変化にも対応できます。

バックエンドプール

バックエンドプールは、実際にトラフィックを処理するサーバー群を管理する構成要素です。

バックエンドプールには、仮想マシン、仮想マシンスケールセット、可用性セットのインスタンスを含めることができます。

システムの拡張性を確保するため、インスタンスの追加や削除を動的に行うことができます。例えば、トラフィックが増加した際には新しいサーバーをプールに追加し、負荷が軽減された時には不要なサーバーを削除できます。

バックエンドプールの重要な機能として、ヘルスチェックによる正常性監視があります。正常に動作しているインスタンスのみにトラフィックが送信され、障害が発生したサーバーは自動的に分散対象から除外されます。また、異なる可用性ゾーンのインスタンスを同じプールに含めることで、地理的な冗長性も確保できます。

インバウンド規則（負荷分散規則）

インバウンド規則は、フロントエンドに到着したトラフィックをバックエンドプールにどのように分散するかを定義する重要な構成要素です。この規則により、ロードバランサーの動作が決定されます。

プロトコル: TCP、UDPを指定できます
ポート: フロントエンドポートとバックエンドポートを設定します
分散方法: 5タプルハッシュ分散がデフォルト
セッション持続性: 同じクライアントからのリクエストを同じサーバーに送信する設定も可能
フローティングIP: Direct Server Return（DSR）の有効/無効を設定

アウトバウンド規則

アウトバウンド規則は、バックエンドプールからインターネットへの送信トラフィックを制御する構成要素です。この機能により、内部サーバーからの外部通信を適切に管理できます。

SNAT: 送信元ネットワークアドレス変換を行います
ポート割り当て: 各インスタンスに割り当てるSNATポート数を制御できます
アイドルタイムアウト: 接続のタイムアウト時間を設定できます
パブリックIPの指定: 送信時に使用するパブリックIPアドレスを指定できます

Azure Load Balancerの料金

Azure Load Balancerの料金体系は、種類とSKUによって異なります。

内部ロードバランサーは基本無料

Azure Load Balancerの料金体系は、内部ロードバランサーとパブリックロードバランサーで大きく異なります。この違いを理解することで、コスト効率の良いシステム設計が可能になります。

内部ロードバランサーは基本無料

内部ロードバランサーは、Microsoftが推進するAzure内部でのトラフィック最適化政策により、基本的に無料で利用できます。内部ロードバランサー自体の維持費用は一切発生せず、処理されるデータ量に対してのみ課金される仕組みになっています。

パブリックロードバランサーの料金について

Standard Load Balancer	リージョンレベルの価格	グローバルレベルの価格
はじめの 5 ルール	¥3.611/時間	¥3.611/時間
追加ルール	¥1.445/ルール/時間	¥1.445/ルール/時間
インバウンド NAT 規則	Free	Free
データ処理量	¥0.723/GB	追加料金なし

ゲートウェイロードバランサー	料金
ゲートウェイ時間	¥1.806/時間
チェーン時間	¥1.445/時間
データ処理量	¥0.578/GB

パブリックロードバランサーは、複数の要素によって料金が構成される従量課金制です。

tandard Load Balancerの場合、基本となるのは最初の5つのルールに対する基本料金で、1時間あたり3.611円が発生します。この料金は、ロードバランサーが存在する限り、トラフィックの有無に関わらず継続的に発生するため、月額では約2,600円程度になります。

追加のルールが必要な場合は、6つ目以降のルールについて1ルールあたり1時間につき1.445円の追加料金が発生します。複雑な負荷分散設定や複数のサービスを同一のロードバランサーで処理する場合は、この追加コストを考慮した設計が重要です。

実際の料金は、利用地域や為替レートによって変動するため、正確な金額はAzureの料金計算ツールで確認することを推奨します。

Azure Load Balancerの作成方法

Azure Load Balancerは、複数の方法で作成できます。それぞれの方法について詳しく説明します。

Azureポータルでの作成方法

GUIベースで直感的に作成できる方法です：

手順1: Azure ポータルにアクセス

Azure ポータルにサインイン
「Load Balancer」を検索

手順2: 基本設定

サブスクリプション: 使用するサブスクリプションを選択
リソースグループ: 新規作成または既存のものを選択
名前: ロードバランサーの名前を入力
地域: デプロイする地域を選択
種類: パブリックまたは内部を選択
SKU: Standard（推奨）を選択

手順3: フロントエンドIP設定

パブリックの場合: パブリックIPアドレスを新規作成または既存のものを選択
内部の場合: 仮想ネットワークとサブネットを選択

手順4: バックエンドプール設定

「バックエンドプール」タブで「追加」をクリック
プール名を入力
ターゲットタイプ（仮想マシン、仮想マシンスケールセットなど）を選択
ターゲットインスタンスを追加

手順5: 負荷分散規則設定

プロトコル（TCP/UDP）を選択
フロントエンドポートとバックエンドポートを設定
ヘルスプローブを設定
セッション持続性を設定（必要に応じて）

CLIでの作成方法

コマンドラインで効率的に作成する方法です。各手順を順番に実行してください。

手順1: リソースグループの作成

まず、ロードバランサーを配置するリソースグループを作成します。

az group create --name myResourceGroup --location eastus

手順2: パブリックIPの作成（パブリックロードバランサーの場合）

パブリックロードバランサーを作成する場合は、フロントエンド用のパブリックIPアドレスを作成します。

az network public-ip create \
  --resource-group myResourceGroup \
  --name myPublicIP \
  --sku Standard

内部ロードバランサーを作成する場合は、この手順をスキップしてください。

手順3: ロードバランサーの作成

ロードバランサー本体を作成し、フロントエンドIPとバックエンドプールを同時に設定します

az network lb create \
  --resource-group myResourceGroup \
  --name myLoadBalancer \
  --sku Standard \
  --public-ip-address myPublicIP \
  --frontend-ip-name myFrontEnd \
  --backend-pool-name myBackEndPool

内部ロードバランサーの場合は以下のコマンドを使用

az network lb create \
  --resource-group myResourceGroup \
  --name myInternalLoadBalancer \
  --sku Standard \
  --subnet mySubnet \
  --vnet-name myVNet \
  --frontend-ip-name myFrontEnd \
  --backend-pool-name myBackEndPool

手順4: ヘルスプローブの作成

バックエンドインスタンスの健全性を監視するヘルスプローブを作成します

az network lb probe create \
  --resource-group myResourceGroup \
  --lb-name myLoadBalancer \
  --name myHealthProbe \
  --protocol tcp \
  --port 80

HTTPによるヘルスチェックを行う場合は以下のコマンドを使用

az network lb probe create \
  --resource-group myResourceGroup \
  --lb-name myLoadBalancer \
  --name myHttpHealthProbe \
  --protocol http \
  --port 80 \
  --path "/"

手順5: 負荷分散規則の作成

az network lb rule create \
  --resource-group myResourceGroup \
  --lb-name myLoadBalancer \
  --name myHTTPRule \
  --protocol tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name myFrontEnd \
  --backend-pool-name myBackEndPool \
  --probe-name myHealthProbe

手順6: バックエンドプールにVMを追加（オプション）

既存の仮想マシンをバックエンドプールに追加する場合

az network nic ip-config address-pool add \
  --address-pool myBackEndPool \
  --ip-config-name ipconfigmyVM \
  --nic-name myVMNic \
  --resource-group myResourceGroup \
  --lb-name myLoadBalancer

作成確認

az network lb show \
  --resource-group myResourceGroup \
  --name myLoadBalancer

Terraformでの作成方法

Infrastructure as Code（IaC）として管理する方法です：

# プロバイダーの設定
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~>3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

# リソースグループ
resource "azurerm_resource_group" "main" {
  name     = "ait0303-rg"
  location = "East US"
}

# パブリックIP
resource "azurerm_public_ip" "main" {
  name                = "pip-loadbalancer"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  allocation_method   = "Static"
  sku                = "Standard"
}

# ロードバランサー
resource "azurerm_lb" "main" {
  name                = "lb-example"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  sku                = "Standard"

  frontend_ip_configuration {
    name                 = "internal"
    public_ip_address_id = azurerm_public_ip.main.id
  }
}

# バックエンドプール
resource "azurerm_lb_backend_address_pool" "main" {
  loadbalancer_id = azurerm_lb.main.id
  name            = "BackEndAddressPool"
}

# ヘルスプローブ
resource "azurerm_lb_probe" "main" {
  loadbalancer_id = azurerm_lb.main.id
  name            = "http-probe"
  port            = 80
  protocol        = "Http"
  request_path    = "/"
}

# 負荷分散規則
resource "azurerm_lb_rule" "main" {
  loadbalancer_id                = azurerm_lb.main.id
  name                           = "LBRule"
  protocol                       = "Tcp"
  frontend_port                  = 80
  backend_port                   = 80
  frontend_ip_configuration_name = "internal"
  backend_address_pool_ids       = [azurerm_lb_backend_address_pool.main.id]
  probe_id                       = azurerm_lb_probe.main.id
}