ロードバランサーの設定徹底解説【2026年最新】
ロードバランサーの設定徹底解説【2026年最新】
ロードバランサーを正しく設定すれば、Webサイトの可用性を99.99%まで引き上げ、応答速度を30%向上させることが可能です。本記事では、AWS ALB、Nginx、HAProxyの3大ロードバランサーの具体的な設定手順と最適化テクニックを、実務で即活用できる形で解説します。初心者から上級者まで、目的に応じた最適な設定方法を網羅的に学べます。
目次
- ロードバランサーとは？基本原理と種類
- AWS ALBの設定手順と最適化
- Nginxを使ったロードバランサー設定
- HAProxyの設定と運用
- ロードバランサーのパフォーマンス最適化
- ロードバランサーのセキュリティ設定
- ロードバランサーのトラブルシューティング
- よくある質問と回答
- まとめと次に学ぶべきこと
ロードバランサーとは？基本原理と種類
ロードバランサーは、複数のサーバーに対してクライアントからのリクエストを自動的に分散させるネットワーク機器またはソフトウェアです。その主な目的は、システムの可用性向上、パフォーマンス最適化、および障害耐性の強化にあります。
具体的な動作原理としては、以下の3つの主要な機能を提供します：
| 機能 | 説明 | 具体例 |
|---|---|---|
| ヘルスチェック | バックエンドサーバーの稼働状態を定期的に確認 | HTTP 200 OKを返さないサーバーを自動除外 |
| 負荷分散アルゴリズム | リクエストをバックエンドサーバーに振り分ける方法 | ラウンドロビン、最小接続数、IPハッシュなど |
| SSL/TLS終端 | 暗号化通信をロードバランサーで処理し、バックエンドに平文で転送 | HTTPSリクエストを受け取り、HTTPで内部サーバーに転送 |
ロードバランサーには主に以下の4種類があり、用途に応じて使い分ける必要があります：
| 種類 | 特徴 | 主な用途 | 代表的な製品 |
|---|---|---|---|
| アプリケーション層(L7) | HTTP/HTTPSリクエストの内容に基づいてルーティング可能 | Webアプリケーション、APIサービス | AWS ALB、Nginx、HAProxy |
| トランスポート層(L4) | TCP/UDPレベルで負荷分散、高速処理が可能 | データベース接続、ゲームサーバー | AWS NLB、HAProxy、F5 BIG-IP |
| ネットワーク層(L3) | IPアドレスに基づいてルーティング、最も高速 | 大規模なデータセンター間負荷分散 | Cisco ACE、Juniper MX |
| グローバルサーバーロードバランシング | 地理的に分散したデータセンター間で負荷分散 | マルチリージョン展開、災害復旧 | AWS Global Accelerator、Cloudflare Load Balancer |
2026年現在、クラウドネイティブな環境ではAWS ALB（Application Load Balancer）が最も広く採用されています。一方で、オンプレミス環境や特殊な要件がある場合は、NginxやHAProxyといったオープンソースソリューションが選択されます。
ロードバランサーを選定する際の重要な判断基準は以下の通りです：
- パフォーマンス要件：1秒あたりのリクエスト処理数（RPS）とレイテンシの目標値
- 機能要件：SSL終端、WAF統合、ブルーグリーンデプロイメントなど
- コスト：初期費用、運用コスト、拡張コスト
- 運用性：監視機能、ログ出力、設定変更の容易さ
- セキュリティ要件：DDoS保護、TLSバージョン、暗号化要件
例えば、ECサイトのような高トラフィックなWebアプリケーションでは、AWS ALB + Auto Scaling + CloudFrontの組み合わせが一般的です。一方、金融システムのように厳格なセキュリティ要件がある場合は、HAProxy + Keepalivedによるオンプレミス構成が選ばれることが多いです。
AWS ALBの設定手順と最適化
AWS ALB（Application Load Balancer）は、AWSが提供するマネージド型のL7ロードバランサーです。2026年現在、AWS ALBは以下の主要な機能を提供しています：
- HTTP/HTTPSリクエストのルーティング
- Web Application Firewall（WAF）との統合
- Auto Scalingとのシームレスな連携
- AWS Certificate Manager（ACM）によるSSL/TLS証明書管理
- CloudWatchとの統合による詳細なモニタリング
AWS ALBを効果的に活用するためには、基本的な設定から始めて、段階的に高度な機能を導入していくことが重要です。
基本的なALB設定
AWS ALBの基本的な設定手順は以下の通りです。まずは最もシンプルな構成から始め、徐々に機能を追加していきましょう。
1. ALBの作成
- AWS Management Consoleにログインし、EC2ダッシュボードに移動します。
- 「ロードバランサー」→「ロードバランサーの作成」をクリックします。
- ロードバランサーの種類を選択：Application Load Balancerを選択します。
- 基本的な設定：
- 名前：例「my-web-alb」
- スキーム：インターネット向け
- IPアドレスタイプ：IPv4
- リスナーの設定：
- プロトコル：HTTP
- ポート：80
- デフォルトアクション：ターゲットグループに転送
- VPCとサブネットの選択：少なくとも2つの異なるAZ（アベイラビリティゾーン）にサブネットを選択します。
- セキュリティグループの設定：
- HTTP（ポート80）を許可
- HTTPS（ポート443）を許可（後で追加）
- ターゲットグループの作成：
- ターゲットグループ名：例「my-web-tg」
- ターゲットタイプ：インスタンス
- プロトコル：HTTP
- ポート：80
- ヘルスチェックパス：/health
- ヘルスチェック間隔：30秒
- ターゲットの登録：EC2インスタンスをターゲットグループに登録します。
- レビューと作成：設定内容を確認し、ロードバランサーを作成します。
2. ターゲットグループの詳細設定
ターゲットグループには、ロードバランサーがリクエストを振り分けるバックエンドサーバーの集合を定義します。以下のパラメータを適切に設定することで、パフォーマンスと可用性を最適化できます。
| パラメータ | 推奨値 | 説明 |
|---|---|---|
| ヘルスチェックパス | /health | アプリケーション固有のヘルスチェックエンドポイント |
| ヘルスチェック間隔 | 30秒 | サーバーの健康状態を確認する頻度 |
| ヘルスチェックタイムアウト | 5秒 | ヘルスチェックがタイムアウトするまでの時間 |
| 正常閾値 | 2回 | 連続して正常と判断される回数 |
| 異常閾値 | 2回 | 連続して異常と判断される回数 |
| 登録解除遅延 | 300秒 | ターゲットを登録解除するまでの猶予時間 |
ヘルスチェックの設定は非常に重要です。例えば、ECサイトの場合、/healthエンドポイントはデータベース接続やキャッシュサーバーの状態も確認するように設計する必要があります。ヘルスチェックが不適切な場合、正常なサーバーが除外されたり、逆に異常なサーバーが登録されたままになる可能性があります。
3. リスナーとルールの設定
ALBのリスナーは、特定のポートとプロトコルで受信したリクエストを処理するルールを定義します。デフォルトでは、HTTP（ポート80）で受信したリクエストをターゲットグループに転送するルールが作成されます。
より高度なルーティングを行う場合は、以下のようなルールを追加します：
- パスベースルーティング：/api/* はAPIサーバーに、/static/* は静的ファイルサーバーに振り分ける
- ホストベースルーティング：api.example.com はAPIサーバーに、www.example.com はWebサーバーに振り分ける
- HTTPヘッダーに基づくルーティング：特定のUser-Agentやリクエストヘッダーに応じて振り分ける
例えば、以下のようなルールを設定することで、異なるサービスにリクエストを振り分けることができます：
<Listener Rule 1>
Conditions:
- Path is /api/*
Actions:
- Forward to API-TargetGroup
</Listener Rule 1>
<Listener Rule 2>
Conditions:
- Host is api.example.com
Actions:
- Forward to API-TargetGroup
</Listener Rule 2>高度なALB設定（WAF・HTTPS強制）
基本的なALB設定が完了したら、次はセキュリティとパフォーマンスを向上させる高度な設定に進みます。2026年現在、Webアプリケーションのセキュリティ要件はますます厳格化しており、ALBを活用したセキュリティ対策が必須となっています。
1. HTTPSの有効化とSSL/TLSの最適化
HTTPからHTTPSへの移行は、Webサイトのセキュリティを向上させるだけでなく、SEO効果やブラウザからの警告回避にもつながります。AWS ALBでは、AWS Certificate Manager（ACM）を使用してSSL/TLS証明書を簡単に管理できます。
HTTPSを有効化する手順は以下の通りです：
- ACMで証明書を発行またはインポート：
- AWS Certificate Managerに移動
- 「証明書のリクエスト」をクリック
- ドメイン名を入力（例：*.example.com）
- DNS検証を選択し、CNAMEレコードをDNSに追加
- 検証が完了するまで待ちます（通常数分〜数時間）
- HTTPSリスナーの作成：
- ロードバランサーのリスナー設定で「リスナーの追加」をクリック
- プロトコル：HTTPS
- ポート：443
- デフォルトアクション：ターゲットグループに転送
- SSL証明書：先ほど発行したACMの証明書を選択
- HTTPからHTTPSへのリダイレクトを設定：
- 新しいリスナー（HTTP:80）を作成
- デフォルトアクションを「リダイレクト」に設定
- リダイレクト先：HTTPS（443）
- ステータスコード：HTTP 301（恒久的リダイレクト）
SSL/TLSの設定を最適化するためには、以下のパラメータを適切に設定する必要があります：
| 設定項目 | 推奨値 | 説明 |
|---|---|---|
| SSLプロトコル | TLS 1.2, TLS 1.3 | 古いSSLv3やTLS 1.0/1.1は無効化 |
| 暗号スイート | ECDHE-ECDSA-AES128-GCM-SHA256 など | 安全性とパフォーマンスのバランスが取れた暗号スイートを選択 |
| 証明書の有効期限 | 90日 | ACMを使用すれば自動更新が可能 |
| OCSP Stapling | 有効 | 証明書の検証を高速化 |
SSL/TLSの設定は、Webサイトのセキュリティだけでなく、パフォーマンスにも大きな影響を与えます。例えば、古い暗号スイートを使用すると、暗号化/復号化の処理負荷が増大し、レスポンス時間が悪化する可能性があります。2026年現在、TLS 1.3が主流となっており、可能な限りTLS 1.3を使用することを推奨します。
2. Web Application Firewall（WAF）の統合
AWS WAFは、SQLインジェクション、クロスサイトスクリプティング（XSS）、DDoS攻撃などの一般的なWebアプリケーション攻撃から保護するファイアウォールサービスです。ALBとWAFを統合することで、リアルタイムでリクエストをフィルタリングし、悪意のあるトラフィックをブロックできます。
WAFをALBに統合する手順は以下の通りです：
- WAF Web ACLの作成：
- AWS WAF & Shieldコンソールに移動
- 「Web ACLを作成」をクリック
- 名前：例「my-web-acl」
- リソースの種類：Application Load Balancer
- リージョン：ALBと同じリージョンを選択
- ルールの追加：
- AWS管理ルールを追加：
- AWSManagedRulesCommonRuleSet（一般的な攻撃から保護）
- AWSManagedRulesSQLiRuleSet（SQLインジェクションから保護）
- AWSManagedRulesKnownBadInputsRuleSet（既知の悪意のある入力から保護）
- カスタムルールを追加：
- IPアドレス制限：特定のIPアドレスからのアクセスのみ許可
- レート制限：1分間に100リクエスト以上の場合はブロック
- リクエストサイズ制限：リクエストボディが1MB以上の場合はブロック
- AWS管理ルールを追加：
- Web ACLをALBに関連付け：
- ALBの詳細ページに移動
- 「WAF」タブをクリック
- 「Web ACLを関連付ける」をクリック
- 作成したWeb ACLを選択
WAFのルール設定は非常に重要です。例えば、ECサイトの場合、以下のようなルールを設定することで、一般的な攻撃から保護できます：
- SQLインジェクション対策：’ OR 1=1 — などの文字列を含むリクエストをブロック
- クロスサイトスクリプティング（XSS）対策：