この記事の要点
• ロードバランシングは複数サーバーにトラフィックを分散し可用性を向上させる技術
• L4（トランスポート層）とL7（アプリケーション層）の2種類がある
• ヘルスチェックと高可用性構成でサービスの安定運用を実現する
ロードバランシングとは
ロードバランシング（負荷分散）は、複数のサーバーにトラフィックを分散させ、システム全体の可用性とパフォーマンスを向上させる技術です。
なぜ必要か: 1台のサーバーでは処理できない大量のリクエストに対応し、サーバー障害時もサービスを継続するために不可欠です。
ロードバランサーの基本構成
flowchart TB
LB["ロードバランサー"]
LB --> S1["Server 1"]
LB --> S2["Server 2"]
LB --> S3["Server 3"]
クライアントはロードバランサーのIPアドレスにアクセスし、ロードバランサーが適切なサーバーにリクエストを振り分けます。
L4とL7ロードバランシング
L4（トランスポート層）ロードバランシング
TCP/UDPレベルで負荷分散を行います。
- 動作: IPアドレスとポート番号で振り分け
- メリット: 高速、低オーバーヘッド
- デメリット: HTTPコンテンツを見られない
L7（アプリケーション層）ロードバランシング
HTTPレベルで負荷分散を行います。
- 動作: URL、ヘッダー、Cookieなどで振り分け
- メリット: 柔軟なルーティング
- デメリット: 処理負荷が高い
L7ロードバランシングの例:
/api/*→ APIサーバー群/static/*→ 静的ファイルサーバー/admin/*→ 管理画面サーバー
主要な負荷分散アルゴリズム
ラウンドロビン（Round Robin）
順番に各サーバーへリクエストを振り分けます。
- リクエスト1 → Server A
- リクエスト2 → Server B
- リクエスト3 → Server C
- リクエスト4 → Server A（繰り返し）
適している場合: サーバー性能が均一な場合
重み付きラウンドロビン（Weighted Round Robin）
サーバーの性能に応じて振り分け比率を調整します。
- Server A (weight: 3) → 3リクエスト
- Server B (weight: 2) → 2リクエスト
- Server C (weight: 1) → 1リクエスト
最小接続数（Least Connections）
現在の接続数が最も少ないサーバーに振り分けます。
- Server A: 10接続中
- Server B: 5接続中 ← 次のリクエストはここへ
- Server C: 8接続中
適している場合: 処理時間にばらつきがある場合
IPハッシュ（IP Hash）
クライアントIPアドレスのハッシュ値でサーバーを決定します。
hash(192.168.1.100) % 3 = 1→ Server Bhash(192.168.1.101) % 3 = 0→ Server A
適している場合: セッションの維持が必要な場合
ヘルスチェック
ロードバランサーは定期的にサーバーの状態を確認し、障害サーバーを自動的に除外します。
アクティブヘルスチェック
ロードバランサー → GET /health → 各サーバー。200 OK → 正常（振り分け対象）、5xx/タイムアウト → 異常（除外）
パッシブヘルスチェック
実際のリクエストの成功/失敗を監視します。
- 連続5回失敗 → サーバーを除外
- 30秒後 → 再度振り分け試行
セッション維持（スティッキーセッション）
同じユーザーのリクエストを同じサーバーに送り続ける仕組みです。
実現方法
| 方式 | 説明 |
|---|---|
| Cookie | サーバーIDをCookieに保存 |
| IPアドレス | クライアントIPで固定 |
| URLパラメータ | セッションIDをURLに含める |
注意点
スティッキーセッションは負荷の偏りを生む可能性があります。可能であれば、セッション情報を外部ストア（Redis等）で管理し、ステートレスな設計を目指しましょう。
注意: スティッキーセッションに依存すると、サーバーダウン時にセッションが失われます。外部セッションストアの導入を強く推奨します。
代表的なロードバランサー
ソフトウェア
| 名前 | 特徴 |
|---|---|
| Nginx | 高性能、リバースプロキシ機能 |
| HAProxy | 高可用性、豊富な機能 |
| Envoy | クラウドネイティブ、サービスメッシュ対応 |
クラウドサービス
| サービス | プロバイダー |
|---|---|
| ALB/NLB | AWS |
| Cloud Load Balancing | Google Cloud |
| Azure Load Balancer | Microsoft Azure |
高可用性構成
ロードバランサー自体の冗長化も重要です。
flowchart TB
VIP["仮想IP<br/>(VIP/Floating IP)"]
VIP --> Active["LB (Active)"]
Standby["LB (Standby)"] -->|監視| Active
Active --> Servers["サーバー群"]
Active-Standby構成で、アクティブなロードバランサーに障害が発生すると、スタンバイが自動的に引き継ぎます。
ポイント: クラウド環境ではマネージドロードバランサー（AWS ALB/NLB、GCP Cloud Load Balancing等）を利用することで、冗長化の管理負荷を大幅に軽減できます。
まとめ
ロードバランシングは、現代のWebサービスにおいて不可欠な技術です。適切なアルゴリズムの選択、ヘルスチェックの設定、高可用性構成により、安定したサービス運用を実現できます。
実践メモ: まずはラウンドロビンから始めて、パフォーマンスの問題が見えてきたら最小接続数など他のアルゴリズムへ切り替えましょう。
参考リソース
- NGINX - HTTP Load Balancing
- HAProxy Documentation
- AWS - Elastic Load Balancing
- Google SRE Book - Load Balancing at the Frontend
- Cloudflare Learning - What is load balancing?