ロードバランサーとは、利用者から届いたアクセスや通信を、複数のサーバーへ振り分ける仕組みです。
1台のサーバーへ負荷が集中するのを防ぎ、アクセス増加へ対応しやすくしたり、障害が起きたサーバーを避けて正常なサーバーへ通信を送ったりするために使われます。
30秒でわかる結論
- ロードバランサーは、複数サーバーへ通信を振り分ける仕組み
- 目的は主に負荷分散・可用性向上・拡張性の確保
- L4はTCP/UDPなど通信レベル、L7はHTTP/HTTPSの内容を見て振り分けられる
- 代表的な分散方式はラウンドロビン、最小接続数、重み付け、ハッシュなど
- ヘルスチェックで異常なサーバーを配送先から外せる
- ロードバランサーを置くだけで完全な冗長化になるわけではない
- 複数Webサーバーではセッションやアップロードファイルの共有方法も考える
- 小規模WordPressサイトでは通常、自前のロードバランサーは不要
- 高アクセス・EC・Webアプリ・複数台構成で必要性が高くなる
ロードバランサーとは？
ロードバランサー（Load Balancer）は、外部から届いた通信を複数のバックエンドサーバーへ分配する役割を持ちます。
構成イメージ
利用者
↓
ロードバランサー
↓ ↓ ↓
WebサーバーA WebサーバーB WebサーバーC
利用者からは1つのWebサイトへアクセスしているように見えても、裏側では複数サーバーへ処理を振り分けられます。
初心者向けに一言でいうと
ロードバランサーは、「混んでいる窓口へ人を集中させず、複数の受付へ案内する係」です。
ロードバランサーを使う目的
ロードバランサーの主な目的は次の3つです。
| 目的 | 内容 |
|---|---|
| 負荷分散 | アクセスを複数サーバーへ分ける |
| 可用性向上 | 異常なサーバーを避ける |
| 拡張性 | サーバー追加で処理能力を増やしやすくする |
単純に「速度を上げる装置」というより、複数台を効率よく使うための交通整理役と考えると分かりやすいです。
負荷分散の仕組み
ロードバランサーは利用者からの通信を受け取り、あらかじめ登録されたバックエンドサーバーの中から送信先を選びます。
L4ロードバランサーとは？
L4ロードバランサーは、主にTCP・UDPなどのトランスポート層情報を使って通信を振り分けます。
Google Cloudの現行ドキュメントでも、L4ロードバランシングはTCP・UDPなどネットワーク／トランスポートプロトコル情報を基に振り分ける方式として説明されています。
L4で見る情報の例
- 送信元IP
- 宛先IP
- 送信元ポート
- 宛先ポート
- TCP / UDP
HTTPのURLパスやCookieなど、アプリケーション内部の詳細を見ずに高速に振り分けたい場面で使われます。
L7ロードバランサーとは？
L7ロードバランサーは、HTTP・HTTPSなどアプリケーション層の内容を見て振り分ける方式です。
L7で使える条件例
- URLパス
- ホスト名
- HTTPヘッダー
- Cookie
- リクエスト内容
たとえば、/api/はAPIサーバー、/images/は画像配信サーバーへ送る、といったルーティングができます。
| 比較 | L4 | L7 |
|---|---|---|
| 主に見る情報 | TCP/UDP・IP・ポート | HTTP/HTTPS内容 |
| URLによる振り分け | 基本不可 | 可能 |
| 用途 | 汎用通信 | Web・API |
代表的な負荷分散方式
ロードバランサーには複数の振り分け方法があります。
ラウンドロビン
サーバーを順番に選ぶ方式です。
例
1件目 → A
2件目 → B
3件目 → C
4件目 → A
NGINXでは、特別な方式を指定しない場合、HTTP負荷分散でラウンドロビンが基本になります。
最小接続数
現在の接続数が最も少ないサーバーへ新しい通信を送る方式です。
処理時間が長いリクエストと短いリクエストが混在する場合に、単純な順番分配より負荷を均しやすい場合があります。
重み付け
性能の高いサーバーへ多く振り分ける方式です。
例
サーバーA：weight 3
サーバーB：weight 1
→ AへBより多く振り分ける
ハッシュ
送信元IPなど一定の値から振り分け先を決める方式です。
NGINXのip_hashでは、同じ利用者を可能な限り同じサーバーへ送る用途に使えます。
ヘルスチェックとは？
ヘルスチェックは、バックエンドサーバーが正常に応答できるかを確認する仕組みです。
AWSのNetwork Load Balancerでは、登録先へアクティブなヘルスチェックを行い、正常と判断したターゲットへ通信を送る仕組みが案内されています。
ヘルスチェックの例
WebサーバーA：200 OK → 正常
WebサーバーB：タイムアウト → 異常
WebサーバーC：200 OK → 正常
→ Bを一時的に配送先から外す
障害時の切り離しに重要
ロードバランサーがあっても、異常なサーバーへ振り分け続ければ利用者はエラーを受けます。ヘルスチェックは可用性の重要な要素です。
ヘルスチェックは何を確認する？
単にポートが開いているかだけでなく、Webアプリが正常に応答しているかまで確認する方法があります。
確認例
- TCP接続できるか
- HTTP 200を返すか
- 専用の/health URLが正常か
- 一定時間以内に応答するか
ただし、ヘルスチェックが複雑すぎると、一時的なDB遅延などで全サーバーを異常判定することがあります。何をもって「利用可能」とするかを設計します。
ロードバランサーとリバースプロキシの違い
ロードバランサーとリバースプロキシは役割が重なることがあります。
| 項目 | 主な役割 |
|---|---|
| リバースプロキシ | 利用者の代わりにバックエンドへ接続 |
| ロードバランサー | 複数バックエンドへ負荷を分散 |
NGINXのように、1つのソフトウェアがリバースプロキシとロードバランサーの両方を担うこともあります。
違いを一言で
リバースプロキシは「前段で代理応答する仕組み」、ロードバランサーはその中でも複数の送信先へ分ける機能に重点があります。
ロードバランサーとスケールアウトの関係
サーバーを1台から2台、3台へ増やすスケールアウトでは、増やしたサーバーへどう通信を分けるかが必要になります。
スケールアウト ＝ サーバー台数を増やす
ロードバランサー ＝ 増やしたサーバーへ通信を振り分ける
そのため、Webサーバーを複数台構成にするときにロードバランサーがよく使われます。
ロードバランサーと冗長化の関係
複数サーバーとヘルスチェックを組み合わせれば、1台が停止しても別サーバーで処理を継続できる構成を作れます。
冗長化の例
Web A：正常
Web B：障害
→ ロードバランサーがAだけへ送信
ロードバランサー1台だけでは単一障害点になる
自前でロードバランサーを1台だけ置くと、そのロードバランサー自体が停止した場合に全通信が止まります。高可用性を求める場合は、ロードバランサー側の冗長化やマネージドサービスも含めて設計します。
WordPressを複数台にするときの注意点
WordPressを複数のWebサーバーへ分散する場合、ロードバランサーを置くだけでは不十分です。
追加で考えること
- データベースを共有する
- アップロード画像を共有する
- キャッシュの整合性を保つ
- ログインセッションを共有または維持する
- プラグイン・テーマの状態をそろえる
- cronやバッチの二重実行を防ぐ
問題例
画像をWebサーバーAへアップロード
次のアクセスはWebサーバーBへ振り分け
→ Bにその画像がなければ表示できない
共有ストレージ・オブジェクトストレージ・デプロイ自動化などを使って、複数台で同じ状態を保つ設計が必要です。
セッション維持とは？
通常のラウンドロビンでは、同じ利用者でもリクエストごとに別サーバーへ送られることがあります。
サーバー内だけにログイン状態を保存しているアプリでは、別サーバーへ移動するとログイン情報を失う場合があります。
対処方法
- Sticky Sessionを使う
- Redisなど外部ストアへセッションを保存する
- アプリケーションをステートレス化する
長期的には、特定サーバーへ状態を持たせすぎない設計の方がスケールしやすくなります。
Sticky Sessionとは？
Sticky Sessionは、同じ利用者をできるだけ同じバックエンドサーバーへ送り続ける仕組みです。
例
利用者A → Webサーバー1
利用者Aの次回アクセス → Webサーバー1
実装方法はロードバランサーによって異なり、Cookieや送信元IPなどを使う場合があります。
Sticky Sessionへ依存しすぎない
固定先サーバーが故障した場合やサーバー台数を変更した場合、別サーバーへ切り替わることがあります。重要な状態は共有ストレージ等へ持たせる方が安定します。
SSL/TLS終端とは？
L7ロードバランサーでは、HTTPS通信のTLS処理をロードバランサー側で行う構成があります。
これをTLS終端と呼びます。
構成例
利用者 → HTTPS → ロードバランサー → HTTPSまたはHTTP → Webサーバー
証明書管理をロードバランサーへ集約しやすい一方、ロードバランサーからバックエンドまでの通信を暗号化するかどうかも設計します。
ロードバランサーを使うメリット
主なメリット
- 1台へのアクセス集中を減らせる
- サーバー追加で拡張しやすい
- 障害サーバーを切り離せる
- メンテナンス時に一部サーバーを外せる
- L7ならURL単位で送信先を分けられる
- TLS証明書管理を集約できる場合がある
ロードバランサーのデメリット
管理項目は増える
- 構成が複雑になる
- ロードバランサー料金が増える
- ネットワーク設計が必要
- ヘルスチェック設定が必要
- ログ調査箇所が増える
- セッション・ファイル共有を考える必要がある
- ロードバランサー自体の可用性も考える必要がある
「複数台にすれば安心」というより、管理対象が増えることを理解したうえで導入します。
ロードバランサーが必要になるサイト
高アクセスWebサービス
必要度：高い
1台では処理しきれないアクセスを複数台へ分散します。
EC・予約サイト
必要度：高め
停止の影響が大きく、負荷分散・冗長化の価値があります。
独自Webアプリ
必要度：中～高
複数インスタンスやオートスケールと組み合わせます。
小規模WordPress
必要度：低い
まず1台構成や共用サーバーで十分な場合が多いです。
VPS初心者にロードバランサーは必要？
通常は必要ありません。
1台のVPSでWebサイトを運営している段階では、ロードバランサーを追加しても分散先がないため意味がありません。
初心者はまず1台を安定運用
CPU・メモリ・ログ・バックアップ・監視・セキュリティを理解してから、1台では処理能力や可用性が足りないと判断した時点で複数台構成を検討します。
共用レンタルサーバー利用者は意識する必要がある？
一般的な共用レンタルサーバー利用者が、自分でロードバランサーを設定する必要はほぼありません。
サーバー会社側が内部で負荷分散・冗長化を行っている場合がありますが、利用者側はその仕組みを直接設定しません。
WordPress初心者はここまでで十分
ブログや会社サイトを運営するだけなら、「大量アクセス時に複数サーバーへ分ける仕組み」と理解できれば十分です。
NGINXでもロードバランサーを作れる
NGINXはリバースプロキシとしてだけでなく、複数バックエンドへのHTTPロードバランサーとして利用できます。
公式ドキュメントでは、ラウンドロビン、least-connected、ip-hash、重み付けなどの方式が案内されています。
概念例
NGINX → Web1
→ Web2
→ Web3
設定例をコピーするだけでは不十分
本番では、ヘルスチェック、TLS、ログ、タイムアウト、バックエンド障害時の挙動、ロードバランサー自体の冗長化まで考える必要があります。
クラウドのマネージドロードバランサーとは？
AWS・Google Cloudなどでは、ロードバランサー自体をマネージドサービスとして利用できます。
自前のVPSへロードバランサーソフトを入れる方法より、ロードバランサー基盤の可用性や拡張をクラウド側へ任せやすいのが特徴です。
| 方式 | 特徴 |
|---|---|
| 自前NGINX等 | 自由度が高いが運用負担も大きい |
| クラウドのマネージドLB | 基盤管理を任せやすい |
ロードバランサー導入前に確認すること
確認項目
- 本当に1台では処理できないか
- ボトルネックはWebサーバーかDBか
- バックエンドを複数台へ増やせるか
- セッションを共有できるか
- アップロードファイルを共有できるか
- ヘルスチェックURLを用意できるか
- ロードバランサー自体の障害対策はあるか
- 監視・ログ収集をどうするか
よくある勘違い
注意
- ロードバランサーを置けばサーバー1台でも速くなると思う
- 複数台にすればDBも自動で分散されると思う
- ヘルスチェックがあればすべての障害を検出できると思う
- ロードバランサー1台なら完全に冗長化できると思う
- WordPressを複数台にするだけで画像・セッションも自動共有されると思う
- Sticky Sessionだけで状態管理の問題が全部解決すると思う
- 小規模サイトにも最初から必要だと思う
教科書判定
小規模サイトでは不要。複数台へスケールするときに初めて検討する
一般的なブログや会社サイトなら、ロードバランサーを自分で構築する必要はありません。まず1台のサーバーや共用レンタルサーバーを安定して使う方が管理しやすくなります。
高アクセスのWebサービス、EC、予約システムなどで1台では処理能力や可用性が不足する場合に、Webサーバーを複数台へ増やし、ロードバランサーで分散する構成を検討してください。
導入時は負荷分散だけでなく、ヘルスチェック、セッション、ファイル共有、DB、ロードバランサー自体の冗長化まで一緒に設計することが重要です。
FAQ
Q. ロードバランサーを入れるとサイトは速くなりますか？
A. 1台へ負荷が集中している場合は改善につながる可能性があります。ただしDBや外部APIがボトルネックなら、Webサーバーだけ分散しても十分に改善しない場合があります。
Q. ロードバランサーとリバースプロキシは同じですか？
A. 完全に同じではありません。リバースプロキシはバックエンドへ代理接続する仕組みで、ロードバランサーは複数のバックエンドへ振り分ける役割に重点があります。1つのソフトが両方を行うこともあります。
Q. WordPressにロードバランサーは必要ですか？
A. 一般的なブログや会社サイトでは通常不要です。非常に高いアクセスや高可用性が必要で、Webサーバーを複数台へ増やす場合に検討します。
Q. ヘルスチェックがあればサーバー障害でも絶対に止まりませんか？
A. いいえ。DB、ストレージ、DNS、ロードバランサー自体など別の単一障害点が残る場合があります。システム全体で冗長化を考える必要があります。
Q. L4とL7はどちらがよいですか？
A. 用途次第です。TCP/UDPレベルでシンプルに分散したいならL4、URLやHTTPヘッダーなどを見てWeb通信を細かく振り分けたいならL7が向きます。
まとめ
ロードバランサーは複数サーバーを効率よく使う交通整理役
- 複数サーバーへアクセスを分散する
- 目的は負荷分散・可用性・拡張性
- L4はTCP/UDP、L7はHTTP/HTTPS内容を見て振り分ける
- ラウンドロビン・最小接続数・重み付け・ハッシュなどがある
- ヘルスチェックで異常サーバーを外せる
- リバースプロキシと役割が重なることがある
- スケールアウトと組み合わせて使う
- WordPress複数台ではセッション・画像・DB共有も必要
- ロードバランサー自体の冗長化も考える
- 小規模サイトでは通常不要
次に読む
「リバースプロキシとは？仕組みと用途を解説」「冗長化とは？サーバー障害対策の基本」「フェイルオーバーとは？冗長化との違いを解説」「スケールアップとスケールアウトの違い」もあわせて確認してください。