Webサービスの利用者が増えると、1台のサーバーでは処理しきれなくなる場面が出てきます。
そのような問題を解決するのがロードバランシング（負荷分散）という技術です。
ロードバランシングは複数のサーバーにリクエストを振り分けることで、特定のサーバーへの負荷集中を防ぎ、システム全体のパフォーマンスと可用性を高めます。
本記事では、ロードバランシングの仕組みと負荷分散の方法をわかりやすく解説するとともに、ラウンドロビン・重み付けなどの主要アルゴリズム、ネットワーク構成の基礎についても詳しく説明します。
インフラ設計やシステム開発に関わる方はぜひ参考にしてみてください。
ロードバランシングとはリクエストを複数サーバーに分散する技術（結論）
それではまず、ロードバランシングの基本的な意味と仕組みについて解説していきます。
ロードバランシング（Load Balancing）とは、クライアントからのリクエストを複数のサーバー（バックエンドサーバー）に均等またはルールに従って分散する技術のことです。
この分散処理を行う機器・ソフトウェアをロードバランサー（Load Balancer）と呼びます。
ロードバランシングの主な目的は3つです。①パフォーマンス向上（1台に負荷が集中することを防ぎ、レスポンスを高速化）、②可用性の向上（1台が障害を起こしても他のサーバーで処理を継続）、③スケーラビリティ（サーバーを追加するだけで処理能力を増強できる）です。
ロードバランサーはクライアントとサーバーの間に位置し、クライアントはロードバランサーのIPアドレスに対してリクエストを送ります。
ロードバランサーが適切なサーバーを選択してリクエストを転送し、レスポンスをクライアントに返します。
ロードバランシングが必要な理由
現代のWebサービスでロードバランシングが必要な理由は非常に明確です。
まず、アクセスの集中への対応です。
人気サービスや特定のイベント時にはアクセスが急増し、1台のサーバーでは処理が追いつかなくなります。
次に、単一障害点（SPOF）の排除です。
1台のサーバーだけでサービスを提供していると、そのサーバーが停止すればサービス全体が止まります。
複数のサーバーに分散することで、1台が停止しても他のサーバーがカバーできます。
またメンテナンスの容易化もあります。
サーバーを1台ずつ順番にメンテナンスしても、サービスを止めずに対応できます。
ロードバランサーの基本的な構成
典型的なロードバランサーを使ったシステム構成を見てみましょう。
クライアント（ブラウザ・アプリ）
↓ リクエスト
ロードバランサー（振り分けを担当）
↙ ↓ ↘
Webサーバー1 Webサーバー2 Webサーバー3
↓ データアクセス
データベースサーバー
クライアントはロードバランサーの仮想IPアドレス（VIP）に接続し、実際のサーバーの存在を意識する必要がありません。
ヘルスチェックの重要性
ロードバランサーは定期的に各バックエンドサーバーへヘルスチェック（死活監視）を行います。
応答がないサーバーや異常なサーバーは自動的に振り分け対象から除外されるため、障害サーバーへリクエストが転送されることを防げます。
ヘルスチェックはHTTP GETリクエストへの応答・TCPポートへの接続確認・カスタムヘルスチェックエンドポイントへのアクセスなどで行われます。
ロードバランシングの主要アルゴリズム
続いては、ロードバランシングで使われる主要なアルゴリズムについて確認していきます。
どのサーバーにリクエストを振り分けるかを決める「分散アルゴリズム」は、ロードバランシングの中核となる部分です。
ラウンドロビン（Round Robin）
ラウンドロビンは最もシンプルな分散アルゴリズムです。
リクエストを順番にサーバーへ均等に振り分けます。
サーバーA・B・Cの3台がある場合
1番目のリクエスト → サーバーA
2番目のリクエスト → サーバーB
3番目のリクエスト → サーバーC
4番目のリクエスト → サーバーA（繰り返し）
シンプルで実装が容易ですが、各リクエストの処理負荷が同じであることが前提です。
処理の重いリクエストと軽いリクエストが混在する場合、特定のサーバーに負荷が偏ることがあります。
重み付きラウンドロビン（Weighted Round Robin）
重み付きラウンドロビンは、サーバーのスペックや処理能力に応じて振り分け比率（重み）を設定するアルゴリズムです。
サーバーA（重み3）・B（重み2）・C（重み1）の場合
6リクエストの振り分け：A・A・A・B・B・C
→ スペックの高いサーバーにより多くリクエストが届く
スペックが異なる複数のサーバーが混在する環境に特に有効なアルゴリズムです。
最少接続数（Least Connections）
最少接続数アルゴリズムは、現在の接続数が最も少ないサーバーにリクエストを転送します。
各サーバーの実際の負荷をリアルタイムに考慮するため、処理時間が異なるリクエストが混在する環境で特に有効です。
セッションの持続時間が長いサービス（例：ファイルダウンロード・動画ストリーミング）に適したアルゴリズムです。
IPハッシュ（IP Hash）
IPハッシュはクライアントのIPアドレスをハッシュ化して、常に同じサーバーに振り分けるアルゴリズムです。
同じクライアントが常に同じサーバーに接続されるため、セッション情報をサーバー側で持つ場合（ステートフルなアプリケーション）に有用です。
ただし、NATやプロキシ経由のクライアントは同一IPになりやすく、偏りが生じる可能性があります。
| アルゴリズム | 特徴 | 適した用途 |
|---|---|---|
| ラウンドロビン | 均等分散・シンプル | 均質なサーバー・均一な負荷 |
| 重み付きラウンドロビン | スペック差を考慮 | 異なるスペックのサーバーが混在 |
| 最少接続数 | 実負荷を考慮 | 処理時間が不均一なリクエスト |
| IPハッシュ | 同一クライアントを同一サーバーへ | ステートフルなアプリケーション |
ロードバランシングのネットワーク構成と種類
続いては、ロードバランシングのネットワーク構成の種類と、それぞれの特徴について確認していきます。
L4ロードバランシングとL7ロードバランシング
ロードバランシングはOSI参照モデルのどのレイヤで動作するかによって、L4（トランスポート層）とL7（アプリケーション層）に分類されます。
L4ロードバランシングはIPアドレスとポート番号の情報だけを使って振り分けます。
パケットの内容を見ないため処理が高速で、TCPやUDPレベルで動作します。
L7ロードバランシングはHTTPのURL・ヘッダー・クッキーなどのアプリケーション層の情報を使って振り分けます。
より細かい制御が可能で、URLパスによるサービス振り分け・HTTPSの終端処理・クッキーベースのセッション維持などが実現できます。
L7ロードバランシングの振り分け例
/api/* → APIサーバーへ
/static/* → 静的コンテンツサーバーへ
/admin/* → 管理サーバーへ
（URLパスに基づいて異なるサーバー群に振り分け）
ハードウェアとソフトウェアのロードバランサー
ロードバランサーにはハードウェア製品とソフトウェア製品があります。
ハードウェアロードバランサーは専用のアプライアンス機器で、F5 BIG-IPやCitrix ADCが代表例です。
高性能で信頼性が高い反面、コストが高く設定変更に専門知識が必要です。
ソフトウェアロードバランサーは汎用サーバー上で動作するソフトウェアで、NGINX・HAProxy・AWS ELB・GCP Cloud Load Balancingなどが代表例です。
クラウド環境ではソフトウェアロードバランサーが主流であり、コスト効率・柔軟性・スケーラビリティに優れています。
クラウド環境でのロードバランシング
AWSではApplication Load Balancer（ALB、L7）・Network Load Balancer（NLB、L4）・Classic Load Balancerなどが提供されています。
Google CloudではCloud Load Balancingが、AzureではAzure Load Balancerが同様のサービスを提供しています。
これらのマネージドサービスを使うことで、インフラ管理の手間を大幅に削減しながら高可用性な負荷分散構成を実現できます。
ロードバランシングの高可用性設計とセッション管理
続いては、ロードバランシングを使った高可用性設計とセッション管理のベストプラクティスについて確認していきます。
ロードバランサー自身の冗長化
ロードバランサーは高可用性の要ですが、ロードバランサー自身が単一障害点になってしまうと本末転倒です。
そのため、ロードバランサー自体も冗長化（Active-Standby構成またはActive-Active構成）することが一般的です。
Active-Standby構成では、アクティブなロードバランサーが停止するとスタンバイが自動的に引き継ぎます（フェイルオーバー）。
Active-Active構成では、2台のロードバランサーが同時に稼働し、負荷を分散します。
スティッキーセッション（セッション維持）
ステートフルなアプリケーションでは、同一クライアントのリクエストを常に同じサーバーに転送する「スティッキーセッション（Sticky Session）」が必要な場合があります。
実現方法としては、CookieベースのセッションアフィニティやIPハッシュが使われます。
ただし、スティッキーセッションを使うと特定のサーバーに負荷が偏る可能性があります。
可能であればセッション情報をRedisなどの共有キャッシュに保存し、ステートレスな設計にすることが理想的です。
グローバルロードバランシング（DNS負荷分散）
地理的に分散した複数のデータセンターにリクエストを振り分けるのが「グローバルロードバランシング（GSLB）」です。
DNS負荷分散はDNSのTTLを短く設定し、クライアントのリクエストを地理的に近いサーバーや負荷の低いデータセンターに誘導します。
Akamai・Cloudflare・AWS Route 53などのサービスがグローバルロードバランシングを提供しており、レイテンシの削減とDR（災害復旧）対策に有効です。
まとめ
ロードバランシングとは複数のサーバーにリクエストを分散することでパフォーマンス・可用性・スケーラビリティを高める技術です。
主なアルゴリズムにはラウンドロビン・重み付きラウンドロビン・最少接続数・IPハッシュがあり、用途に応じて使い分けます。
L4とL7の2種類があり、L7はURLやヘッダーによる細かい振り分けが可能です。
クラウド環境ではAWS ELB・GCP Cloud Load Balancingなどのマネージドサービスが広く使われており、インフラ設計の必須知識となっています。
ロードバランシングの仕組みを正しく理解し、システムの要件に合わせた適切な設計を心がけてみてください。
