ロードバランシングの概念を理解したら、次に気になるのは「実際どう設定するのか」という点でしょう。
ハードウェア型・ソフトウェア型・クラウド型とそれぞれに設定方法が異なり、冗長化・フェイルオーバー・クラスタリングといった高可用性のための構成も合わせて理解することが重要です。
本記事では、ロードバランシングの設定方法を代表的なソフトウェアロードバランサー（NGINX・HAProxy）を中心に解説し、冗長化構成・可用性向上のポイント・フェイルオーバーの仕組みについても詳しく説明します。
実際のシステム構築に役立てていただければ幸いです。
ロードバランシングの設定は目的別に構成を選ぶことが重要（結論）
それではまず、ロードバランシングの設定において最初に考えるべき構成選択について解説していきます。
ロードバランシングの設定を始める前に、まず「どのような目的でロードバランシングが必要か」を明確にすることが重要です。
| 目的 | 推奨する構成 | 代表的な製品・サービス |
|---|---|---|
| シンプルな負荷分散 | ソフトウェアL7（単台） | NGINX・HAProxy |
| 高可用性が必要 | ソフトウェアL7（冗長化） | NGINX+Keepalived |
| クラウド環境 | マネージドサービス | AWS ALB・GCP LB |
| 大規模・高トラフィック | ハードウェア型またはクラウド型 | F5・AWS NLB |
| マイクロサービス | サービスメッシュ・サイドカープロキシ | Envoy・Istio |
中小規模のWebサービスではNGINXまたはHAProxyによるソフトウェアロードバランサーが最もコストパフォーマンスに優れた選択肢です。クラウド環境ではAWSのELB（Elastic Load Balancing）などのマネージドサービスを使うことで、運用負担を大幅に削減できます。
NGINXによるL7ロードバランシングの設定
NGINXは世界で最も広く使われているソフトウェアロードバランサーの一つです。
基本的なHTTP負荷分散の設定を示します。
# /etc/nginx/nginx.conf
http {
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
→ デフォルトはラウンドロビンで3台に均等分散
このシンプルな設定だけでL7ロードバランシングが動作します。
NGINXの各アルゴリズム設定
NGINXでアルゴリズムを変更するには、upstreamブロック内に指定します。
# 最少接続数
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
# 重み付きラウンドロビン
upstream backend {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
}
# IPハッシュ
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
HAProxyの設定方法
続いては、HAProxyを使ったロードバランシングの設定方法を確認していきます。
HAProxyはL4・L7両方に対応した高性能なオープンソースのロードバランサーです。
HAProxyの基本設定
# /etc/haproxy/haproxy.cfg
global
log /dev/log local0
maxconn 4096
defaults
mode http
timeout connect 5s
timeout client 30s
timeout server 30s
frontend web_frontend
bind *:80
default_backend web_servers
backend web_servers
balance roundrobin
option httpchk GET /health
server web1 192.168.1.10:8080 check
server web2 192.168.1.11:8080 check
server web3 192.168.1.12:8080 check
option httpchk GET /healthでHTTPヘルスチェックを設定し、serverの末尾のcheckで各サーバーへのヘルスチェックを有効化しています。
HAProxyは統計情報の表示・詳細なログ・多様なアルゴリズムサポートなど、運用に役立つ機能が充実しています。
HAProxyのアルゴリズム設定
HAProxyはbalanceディレクティブでアルゴリズムを指定します。
balance roundrobin # ラウンドロビン
balance leastconn # 最少接続数
balance source # 送信元IPハッシュ
balance uri # URIハッシュ
balance random # ランダム
HAProxyのスティッキーセッション設定
HAProxyではCookieベースのスティッキーセッションを簡単に設定できます。
backend web_servers
balance roundrobin
cookie SERVERID insert indirect nocache
server web1 192.168.1.10:8080 check cookie web1
server web2 192.168.1.11:8080 check cookie web2
→ クライアントのCookieにサーバーIDを保存して同一サーバーへ誘導
冗長化・クラスタリング・フェイルオーバーの設定
続いては、ロードバランサー自体の冗長化とフェイルオーバーの設定方法について確認していきます。
ロードバランサーが単一障害点にならないよう、ロードバランサー自体を冗長化することが重要です。
KeepalivedによるVRRP冗長化
LinuxではKeepalivedというソフトウェアを使ってVRRP（Virtual Router Redundancy Protocol）による冗長化が実現できます。
2台のロードバランサーにKeepalivedを設定し、仮想IPアドレス（VIP）を共有します。
メインのロードバランサーが停止するとVIPがバックアップに自動的に移動し、クライアントは停止を意識せずに接続を続けられます。
# keepalived.conf（マスター側）
vrrp_instance LB_HA {
state MASTER
interface eth0
virtual_router_id 51
priority 100
virtual_ipaddress {
192.168.1.100 # 仮想IPアドレス（VIP）
}
}
# keepalived.conf（バックアップ側）
vrrp_instance LB_HA {
state BACKUP
interface eth0
virtual_router_id 51
priority 90 # マスターより低い優先度
virtual_ipaddress {
192.168.1.100
}
}
マスターの優先度がバックアップより高く設定されており、マスターが復旧するとVIPが自動的に戻ります（プリエンプション）。
フェイルオーバーの仕組み
フェイルオーバーとは、現在稼働中のシステムが障害を起こしたとき、自動的にバックアップシステムへ切り替わる仕組みです。
ロードバランサーのフェイルオーバーには2つのレベルがあります。
まず「ロードバランサー自身のフェイルオーバー」で、VRRPによるActive-Standby切り替えがこれにあたります。
次に「バックエンドサーバーのフェイルオーバー」で、ヘルスチェックで障害を検知したサーバーを振り分け対象から外す処理です。
フェイルオーバーの切り替え時間（RTO：Recovery Time Objective）を最小化するために、ヘルスチェック間隔と判定しきい値の適切な設定が重要です。
クラスタリング構成の考え方
クラスタリングとは複数のサーバーを論理的に1つのシステムとして扱う技術です。
ロードバランシングと組み合わせることで、高可用性クラスタ（HA Cluster）を構築できます。
アプリケーションサーバー層・データベース層それぞれにクラスタリングを適用し、システム全体のSPOFをなくすことが目標です。
クラウド環境でのロードバランシング設定
続いては、クラウド環境（主にAWS）でのロードバランシング設定の概要を確認していきます。
AWS ALBの設定手順
AWS ALB（Application Load Balancer）の基本的な設定手順は以下のとおりです。
① ターゲットグループの作成
・振り分け先のEC2インスタンスをグループ化
・ヘルスチェックパスを設定（例：/health）
② ALBの作成
・リスナー（80番または443番ポート）を設定
・サブネット（マルチAZ）を選択
③ リスナールールの設定
・URLパスごとの振り分けルールを設定
・ターゲットグループとの紐付け
④ SSL証明書の設定（HTTPS使用時）
・AWS Certificate Manager（ACM）と統合
AWSのマネージドサービスを使うことで、冗長化・自動スケーリング・ヘルスチェックが自動的に管理されます。
Auto Scalingとの組み合わせ
ALBとAuto Scalingグループを組み合わせることで、トラフィックの増減に応じてバックエンドサーバーの台数を自動調整できます。
トラフィック増加時にはEC2インスタンスが自動的に追加されてALBのターゲットグループに登録され、減少時には自動的に削除されます。
これによりコストを最適化しながら高パフォーマンスを維持するスケーラブルなシステムが実現できます。
設定時の注意点とベストプラクティス
ロードバランシングの設定における重要な注意点をまとめます。
まず、ヘルスチェックエンドポイントは軽量な処理に留めることです。
DBアクセスなど重い処理を含めると、ヘルスチェック自体がサーバーに負荷をかけます。
次に、ドレイン（Graceful Shutdown）の設定です。
サーバーを停止する際に既存の接続を維持したまま新規接続だけを止める「コネクションドレイン」を設定することで、処理中のリクエストが中断されません。
また、アクセスログの収集も重要です。
ロードバランサーのアクセスログを収集・分析することで、トラフィックパターンや障害の原因分析が容易になります。
まとめ
ロードバランシングの設定は目的・規模・環境に応じて適切な構成と製品を選ぶことが重要です。
NGINX・HAProxyはオープンソースで高機能なソフトウェアロードバランサーとして中小規模のシステムに最適です。
KeepalivedによるVRRP冗長化でロードバランサー自身のSPOFを解消し、フェイルオーバーの自動化が実現できます。
クラウド環境ではAWS ALBなどのマネージドサービスがAuto Scalingと組み合わさることで、運用コストを最小化しながら高可用性を実現できます。
ヘルスチェック・ドレイン・ログ収集などの細部にも気を配り、信頼性の高いロードバランシング構成を実現してみてください。
