ロードバランサーの設定完全ガイド【2026年版】

Webサイトやアプリケーションのパフォーマンスを最適化し、安定したサービス提供を実現するには、ロードバランサーの適切な設定が不可欠です。2026年現在、クラウドサービスの普及により、オンプレミスからクラウドまで幅広い環境でロードバランサーが活用されています。本ガイドでは、ロードバランサーの基本原理から具体的な設定手順、最新のテクノロジー動向までを網羅的に解説します。この記事を最後まで読み進めれば、自分の環境に最適なロードバランサーを選択し、効率的な設定ができるようになるでしょう。
—
目次
– ロードバランサーとは
– ロードバランサーの種類と特徴
– ロードバランサーの選び方
– ロードバランサーの設定手順
– AWS ELB/ALBの設定
– Azure Load Balancerの設定
– Google Cloud Load Balancingの設定
– オンプレミス環境の設定
– 高度な設定テクニック
– ヘルスチェックの最適化
– SSL/TLS終端の設定
– セッション永続化の実装
– 監視とログ管理
– トラブルシューティング
– 2026年のロードバランサー動向
– まとめ
– よくある質問
—
ロードバランサーとは
ロードバランサーは、複数のサーバーやサービスに対して、クライアントからのリクエストを適切に分配するネットワーク機器またはソフトウェアです。その主な目的は以下の通りです。
- 負荷分散:複数のサーバーに処理を分散させ、システム全体のパフォーマンスを向上させます。
- 可用性向上:1台のサーバーに障害が発生しても、他のサーバーが処理を引き継ぐことでサービスを継続します。
- スケーラビリティ:トラフィックの増加に応じて、簡単にサーバーを追加できます。
- セキュリティ向上:DDoS攻撃の緩和や、内部サーバーのIPアドレスを隠蔽することでセキュリティを強化します。
具体例として、ECサイトのようなトラフィックが急増するシステムでは、ロードバランサーを導入することで、ユーザー体験を損なうことなく多くのリクエストを処理できます。例えば、Amazonのような大規模ECサイトでは、年間数十億件のリクエストを処理するために、高度なロードバランサーシステムが活用されています。
(出典: AWS Elastic Load Balancing)
—
ロードバランサーの種類と特徴
ロードバランサーは、その機能やレイヤーによって複数の種類に分類されます。以下に主要な種類とその特徴をまとめます。
| 種類 | レイヤー | 主な機能 | メリット | デメリット | 代表的な製品 |
|---|---|---|---|---|---|
| L2ロードバランサー | データリンク層(OSIモデル第2層) | MACアドレスに基づくトラフィック分配 | 低レイテンシ、シンプルな設定 | 柔軟性に欠ける、高度な機能が少ない | Cisco ACE、F5 BIG-IP LTM |
| L3ロードバランサー | ネットワーク層(OSIモデル第3層) | IPアドレスに基づくトラフィック分配 | ルーティング機能との連携が可能 | アプリケーションレイヤーの機能が限定的 | Cisco CSR 1000v、Juniper MX Series |
| L4ロードバランサー | トランスポート層(OSIモデル第4層) | TCP/UDPポートに基づくトラフィック分配 | 高速処理、シンプルな負荷分散 | アプリケーションレイヤーの処理ができない | AWS Network Load Balancer、HAProxy |
| L7ロードバランサー | アプリケーション層(OSIモデル第7層) | HTTP/HTTPSリクエストの内容に基づく分配 | 柔軟なルーティング、高度な機能 | レイテンシが高くなる可能性あり | AWS Application Load Balancer、Nginx、Apache Traffic Server |
| グローバルロードバランサー | 複数のレイヤーを組み合わせ | 地理的なトラフィック分配、DNSベースの負荷分散 | 世界規模での可用性向上 | 設定が複雑、コストが高い | AWS Global Accelerator、Cloudflare Load Balancer |
例えば、Webアプリケーションの場合、通常はL7ロードバランサーが使用されます。これは、HTTPリクエストのURLパスやヘッダー情報に基づいて、異なるバックエンドサーバーにリクエストを振り分けることができるためです。一方、単純なTCP/UDPベースのサービスでは、L4ロードバランサーが適しています。
(出典: F5 Networks – Load Balancer Glossary)
—
ロードバランサーの選び方
ロードバランサーを選択する際には、以下の要素を総合的に考慮する必要があります。
1. 使用環境
- クラウド環境:AWS、Azure、Google Cloudなどのクラウドサービスでは、それぞれ専用のロードバランサーが提供されています。例えば、AWSの場合はELB(Elastic Load Balancer)ファミリーが利用できます。
- オンプレミス環境:自社でサーバーを管理する場合は、ハードウェアロードバランサーやソフトウェアロードバランサー(例:HAProxy、Nginx)を選択します。
- ハイブリッド環境:クラウドとオンプレミスの両方を活用する場合は、ハイブリッドロードバランサーを検討します。
2. トラフィックの種類と量
- HTTP/HTTPSトラフィック:Webアプリケーションの場合は、L7ロードバランサーが適しています。URLパスやドメイン名に基づいてリクエストを振り分けることができます。
- TCP/UDPトラフィック:データベース接続やゲームサーバーなど、プロトコルレベルで負荷分散が必要な場合は、L4ロードバランサーを選択します。
- 大量のトラフィック:年間数十億件のリクエストを処理する場合は、高性能なロードバランサー(例:F5 BIG-IP、Citrix ADC)が必要です。
3. 機能要件
ロードバランサーに求められる機能を明確にします。
| 機能 | 説明 | 対応ロードバランサー例 |
|---|---|---|
| SSL/TLS終端 | 暗号化されたトラフィックを復号化し、バックエンドサーバーに平文で転送する機能 | AWS ALB、Nginx、HAProxy |
| ヘルスチェック | バックエンドサーバーの健康状態を監視し、障害が発生したサーバーへのトラフィックを停止する機能 | 全ての主要ロードバランサー |
| セッション永続化 | 同じクライアントからのリクエストを常に同じバックエンドサーバーに振り分ける機能 | AWS ALB、Nginx、HAProxy |
| コンテンツルーティング | リクエストの内容(URLパス、ヘッダー、クエリパラメータなど)に基づいて振り分け先を決定する機能 | AWS ALB、Nginx、Apache Traffic Server |
| WAF統合 | Web Application Firewallと連携し、悪意のあるトラフィックをブロックする機能 | AWS ALB + AWS WAF、F5 BIG-IP ASM |
| グローバル負荷分散 | 地理的に分散したデータセンター間でトラフィックを振り分ける機能 | AWS Global Accelerator、Cloudflare Load Balancer |
4. コスト
ロードバランサーのコストは、以下の要素によって大きく異なります。
- 初期費用:ハードウェアロードバランサーの場合は、機器の購入費用がかかります。ソフトウェアロードバランサーの場合は、ライセンス費用がかかることがあります。
- 運用費用:クラウドサービスのロードバランサーの場合は、使用した分だけ料金が発生します。例えば、AWS ELBの場合は、1時間あたりの料金とデータ処理量に応じた料金が発生します。
- 保守費用:ハードウェアロードバランサーの場合は、保守契約が必要なことがあります。ソフトウェアロードバランサーの場合は、アップデートやサポートにかかる費用を考慮します。
2026年現在、クラウドサービスの普及により、初期費用を抑えて柔軟にスケールできるロードバランサーが主流となっています。例えば、AWS ALBの場合、1時間あたり$0.0225(2026年時点の価格)から利用できます。
(出典: AWS ELB Pricing)
—
ロードバランサーの設定手順
ロードバランサーの設定手順は、使用する環境や製品によって異なります。以下に、主要なクラウドサービスとオンプレミス環境における設定手順を解説します。
AWS ELB/ALBの設定
AWS Elastic Load Balancer(ELB)は、AWSが提供するマネージド型のロードバランサーです。2026年現在、以下の3種類のロードバランサーが提供されています。
- Application Load Balancer(ALB):L7ロードバランサーで、HTTP/HTTPSトラフィックに最適です。
- Network Load Balancer(NLB):L4ロードバランサーで、TCP/UDPトラフィックに最適です。
- Gateway Load Balancer(GWLB):L3ロードバランサーで、ネットワークトラフィックの検査と負荷分散に使用されます。
AWS ALBの設定手順
- ロードバランサーの作成
- AWS Management Consoleにログインし、EC2ダッシュボードに移動します。
- 左側のメニューから「ロードバランサー」を選択し、「ロードバランサーの作成」をクリックします。
- ロードバランサーの種類として「Application Load Balancer」を選択します。
- 基本設定で、ロードバランサー名、スキーム(インターネット向けまたは内部向け)、IPアドレスタイプ(IPv4またはデュアルスタック)を指定します。
- リスナーの設定で、プロトコル(HTTP/HTTPS)とポート(80/443)を指定します。HTTPSを使用する場合は、SSL証明書をアップロードまたはAWS Certificate Manager(ACM)から選択します。
- ターゲットグループの作成
- 「ターゲットグループ」を選択し、「ターゲットグループの作成」をクリックします。
- ターゲットグループ名、プロトコル(HTTP/HTTPS)、ポート(80/443)、ターゲットタイプ(インスタンス、IP、Lambdaなど)を指定します。
- ヘルスチェックの設定で、ヘルスチェックパス(例:/health)、ヘルスチェック間隔(秒)、ヘルスチェックタイムアウト(秒)、健康なしきい値、 unhealthyしきい値を指定します。
- リスナーとルールの設定
- ロードバランサーの「リスナー」タブで、既存のリスナーを編集または新しいリスナーを追加します。
- ルールを設定し、リクエストを振り分ける条件(例:ホストヘッダー、パスパターン)とターゲットグループを指定します。
- ターゲットの登録
- ターゲットグループにEC2インスタンスを登録します。EC2ダッシュボードからインスタンスを選択し、「アクション」→「ターゲットグループに登録」をクリックします。
- 登録したターゲットがヘルスチェックに合格するまで待ちます。
- ロードバランサーのテスト
- ロードバランサーのDNS名(例:my-alb-123456789.ap-northeast-1.elb.amazonaws.com)に対して、curlやブラウザでアクセスします。
- 複数のリクエストを送信し、リクエストが異なるターゲットに振り分けられることを確認します。
(出典: AWS ALB公式チュートリアル)
Azure Load Balancerの設定
Azure Load Balancerは、Azureが提供するマネージド型のロードバランサーです。2026年現在、以下の2種類のロードバランサーが提供されています。
- 基本ロードバランサー:L4ロードバランサーで、TCP/UDPトラフィックに最適です。
- 標準ロードバランサー:L4ロードバランサーで、高可用性とスケーラビリティを提供します。
Azure Load Balancerの作成手順とテスト
- ロードバランサーの作成
- Azure Portalにログインし、左側のメニューから「ロードバランサー」を選択します。
- 「追加」をクリックし、ロードバランサーの基本情報(サブスクリプション、リソースグループ、リージョン、名前、SKU、タイプ)を入力します。
- 「フロントエンドIP構成」で、パブリックIPアドレスまたは内部IPアドレスを割り当てます。
- 「バックエンドプール」で、ロードバランサーに接続する仮想マシン(VM)を追加します。
- 「ヘルスプローブ」で、ヘルスチェックの設定(プロトコル、ポート、間隔、しきい値)を行います。
- 「負荷分散規則」で、トラフィックを振り分けるルール(プロトコル、ポート、バックエンドプール、ヘルスプローブ)を設定します。
- ロードバランサーのテスト
- ロードバランサーのパブリックIPアドレスに対して、curlやブラウザでアクセスします。
- 複数のリクエストを送信し、リクエストが異なるVMに振り分けられることを確認します。
(出典: Azure Load Balancer公式ドキュメント)
Google Cloud Load Balancingの設定
Google Cloud Load Balancingは、Google Cloudが提供するマネージド型のロードバランサーです。2026年現在、以下の種類のロードバランサーが提供されています。
- HTTP(S)ロードバランサー:L7ロードバランサーで、HTTP/HTTPSトラフィックに最適です。
- TCPロードバランサー:L4ロードバランサーで、TCPトラフィックに最適です。
- UDPロードバランサー:L4ロードバランサーで、UDPトラフィックに最適です。
- 内部ロードバランサー:内部ネットワーク内で使用されるロードバランサーです。
Google Cloud Load Balancingの構成手順
- バックエンドサービスの作成
- Google Cloud Consoleにログインし、左側のメニューから「ネットワーキング」→「負荷分散」を選択します。
- 「ロードバランサーの作成」をクリックし、ロードバランサーの種類として「HTTP(S)ロードバランサー」を選択します。
- バックエンド構成で、バックエンドサービスを作成します。バックエンドタイプ(インスタンスグループ、NEG(ネットワークエンドポイントグループ)、ゾーン間負荷分散)を選択します。
- ヘルスチェックを設定し、ヘルスチェック名、プロトコル、ポート、間隔、しきい値を指定します。
- フロントエンドの設定
- フロントエンド構成で、IPアドレス(新規作成または既存の静的IPアドレス)、ポート(80/443)、プロトコル(HTTP/HTTPS)を指定します。
- HTTPSを使用する場合は、SSL証明書をアップロードまたはGoogle CloudのSSL証明書マネージャーから選択します。
- ルールの設定
- ホストとパスのルールを設定します。例えば、特定のホスト名やURLパスに基づいて、異なるバックエンドサービスに振り分けることができます。
- ロードバランサーのテスト
- ロードバランサーのIPアドレスに対して、curlやブラウザでアクセスします。
- 複数のリクエストを送信し、リクエストが異なるバックエンドに振り分けられることを確認します。
(出典: Google Cloud HTTP(S)ロードバランサー公式ドキュメント)
オンプレミス環境の設定
オンプレミス環境でロードバランサーを設定する場合、ハードウェアロードバランサーまたはソフトウェアロードバランサーを使用します。代表的なソフトウェアロードバランサーには、Nginx、HAProxy、Apache Traffic Serverがあります。
Nginxを使用したロードバランサーの構築手順
Nginxは、高性能なWebサーバーであり、ロードバランサーとしても広く使用されています。以下に、Nginxを使用したロードバランサーの設定手順を解説します。
- Nginxのインストール
- LinuxサーバーにSSHで接続します。
- 以下のコマンドを実行して、Nginxをインストールします。
bash
Ubuntu/Debian
sudo apt update
sudo apt install nginx
CentOS/RHEL
sudo yum install epel-release
sudo yum install nginx
- Nginxの設定ファイルの編集
- /etc/nginx/nginx.confファイルを編集します。
- 以下の設定を追加します。
nginx
http {
upstream backend {
server 192.168.1.10:80;
server 192.168.1.11:80;
server 192.168.1.12:80;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /health {
return 200 ‘OK’;
add_header Content-Type text/plain;
}
}
}
- ヘルスチェックの設定
- /healthエンドポイントを使用して、バックエンドサーバーの健康状態を監視します。
- Nginxの設定ファイルにヘルスチェック用のlocationブロックを追加します。
- Nginxの再起動
- 設定ファイルを保存し、Nginxを再起動します。
bash
sudo systemctl restart nginx
- ロードバランサーのテスト
- ロードバランサーのIPアドレスまたはドメイン名に対して、curlやブラウザでアクセスします。
- 複数のリクエストを送信し、リクエストが異なるバックエンドサーバーに振り分けられることを確認します。
(出典: Nginx公式ドキュメント)
—
高度な設定テクニック
基本的なロードバランサーの設定が完了したら、次は高度な設定テクニックを活用して、パフォーマンスやセキュリティを向上させましょう。
ヘルスチェックの最適化
ヘルスチェックは、ロードバランサーがバックエンドサーバーの健康状態を監視するための重要な機能です。適切なヘルスチェックを設定することで、障害が発生したサーバーへのトラフィックを自動的に停止し、システム全体の可用性を向上させることができます。
ヘルスチェックの種類
| 種類 | 説明 | メリット | デメリット |
|---|---|---|---|
| TCPヘルスチェック | 指定したポートにTCP接続を試み、接続が成功すれば正常と判断します。 | シンプルで高速、ネットワーク層で動作 | アプリケーション層の障害を検出できない |
| HTTPヘルスチェック | 指定したURLにHTTPリクエストを送信し、HTTPステータスコードを確認します。 | アプリケーション層の障害を検出可能 | HTTPサーバーが動作していてもアプリケーションが動作していない場合に検出できない |
| HTTPSヘルスチェック | HTTPSリクエストを送信し、SSL/TLSの正常性も確認します。 | セキュリティの正常性も確認可能 | 設定が複雑、レイテンシが高くなる |
| カスタムヘルスチェック | スクリプトやAPIを使用して、アプリケーション固有のヘルスチェックを行います。 |
本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら




