“OSI参照モデル”で見た第4層、第7層の「ロードバランサー」の違いはこれだ：2つのロードバランサーを比較【前編】

「ロードバランシング」（負荷分散）は、いまやWebサービスや業務システムを支える不可欠な仕組みだ。ネットワークとアプリケーション、2つの負荷分散の仕組みを解説する。

≫ 2025年07月10日 07時15分公開

　「ロードバランシング」（負荷分散）は、もはや現代のITサービスに欠かせない仕組みだ。オンラインショッピングやニュースの閲覧、投資情報の確認といった一般的なインターネットサービスはもちろん、大企業のITインフラで運用される業務システムも、ロードバランシングなしでは正常に機能しないと言って過言ではない。

　トラフィック（ネットワークを流れるデータ）を複数のシステムに分散させるのがロードバランシングだ。その仕組みは、地理的に離れたデータセンターや、世界各地に分散する仮想サーバといった広範囲にまたがって構成されていることがある。ロードバランシングがなければ、ニュースサイトの閲覧でもオンラインショッピングでも、全てのユーザーが同じサーバにアクセスすることになり、結果としてサーバが過負荷に陥り、サービスの提供が困難になる恐れがある。これを防ぐために、ロードバランサー（負荷分散装置）はトラフィックを各サーバへ適切に振り分ける。

　とはいえ一口にロードバランシングと言っても、その仕組みは大きく「ネットワークロードバランシング」と「アプリケーションロードバランシング」の2種類に分けることができる。これは、「OSI参照モデル」（OSI：開放型システム間相互接続）の7階層のうち、どの階層で処理をするかによって区別される。ネットワークロードバランシングは第4層（レイヤー4、トランスポート層）で機能し、アプリケーションロードバランシングは第7層（レイヤー7、アプリケーション層）で機能する。以降では、この2つのロードバランシングの処理が、それぞれどのような結果の違いを生むのかを解説する。

ネットワークロードバランシングとは何か

　ネットワークロードバランシングは、ルーターのような機能を持つ専用のシステムや機器として実装されるが、多くの場合はハードウェア面でもソフトウェア面でも負荷分散の目的に応じて設計されている。この負荷分散方式は、OSI参照モデルの第4層、トランスポート層で動作し、主にTCP（Transmission Control Protocol：伝送制御プロトコル）やUDP（User Datagram Protocol：ユーザーデータグラムプロトコル）といったトランスポート層のプロトコルを使用する。TCPは全てのパケットが正しく転送されることを保証するのに対し、UDPは転送の保証がない通信の仕組みだ。

　エンドユーザーがWebサービスにリクエストを送信する際は、一般に既知のドメイン名が使われる。例えば、米ニュースメディア「CNN」のWebサイトを閲覧しようとするリクエストは、そのドメインにひも付けられたIPアドレスを持つロードバランサーに送られる。ロードバランサーは、CNNのコンテンツを提供する複数のバックエンドシステムのIPアドレスをルーティングテーブル（宛先までの経路情報をまとめた表）に登録しており、受信したリクエストを即座に適切なサーバへと振り分ける。

　ネットワークロードバランサーは、リクエストの内容を解析せず、パケット（送受信データを小分けにした単位）のヘッダ情報のみを基に処理を実行する。そのため、リクエスト内容に応じた転送先の選定はしない。ただし、応答しないサーバを自動的に振り分け対象から除外する機能を備えているため、全体としての信頼性は向上する。

アプリケーションロードバランシングとは何か

　アプリケーションロードバランシングは、OSI参照モデルの第7層、アプリケーション層で動作するロードバランシング方式だ。サーバにインストールされたアプリケーションが、HTTPS（Hypertext Transfer Protocol Secure）やSMTP（Simple Mail Transfer Protocol）といったアプリケーション層のプロトコルによる通信内容を解析し、その内容に応じて処理を振り分ける。この方式では、リクエストの内容に沿ってサーバに処理を割り当てることができる。例えばオンラインショッピングでは、ユーザーのリクエスト内容に応じて、該当する商品カテゴリーの在庫情報を管理しているシステムに処理を振り分けるといった制御が可能になる。

　ネットワークロードバランシングがリクエストを単純に転送するのに対し、アプリケーションロードバランシングでは、リクエストのヘッダ情報を解析し、アプリケーション層のプロトコルに含まれるデータ内容を精査する。この解析には時間がかかるものの、その分リクエストの内容に基づいて、最適なサーバへの振り分けを判断できるという利点がある。

併せて読みたいお薦め記事

負荷分散の仕組みをさらに広く

ロードバランシングのアルゴリズム

　ロードバランサーはリクエストを受信すると、さまざまなアルゴリズムを使って転送先の候補を選定する。アルゴリズムには、大まかに2つの種類がある。一つはあらかじめ定義されたルールに従ってリクエストを振り分ける「静的アルゴリズム」。もう一つはサーバのワークロード（システムにかかる処理負荷やその種類）や応答時間などの状況に基づいて転送先を調整する「動的アルゴリズム」だ。以下に、ロードバランシングでよく用いられる主なアルゴリズムの例を挙げる。

ラウンドロビン方式
- 宛先の候補を順番に循環させて振り分ける、シンプルな静的アルゴリズム。
重み付きラウンドロビン方式
- ラウンドロビン方式の一種。ネットワーク管理者が各システムの性能に応じて重みを設定できるため、サーバの処理能力が均一でない場合に適している。
IPハッシュ方式
- クライアントのIPアドレスをハッシュ化（一定のルールに基づいて一意の値を生成する処理）し、同じIPアドレスからのリクエストは常に同じサーバに送信されるようにする静的アルゴリズム。セッション（1つの通信の開始から終わりまで）の維持が必要なステートフルアプリケーションに有効。
最小接続数方式（最小未処理リクエスト方式）
- 動的アルゴリズムの一つで、接続数や待機リクエスト数が最も少ないサーバを選び、最速の応答を得ることを目的とする。効率は高いが、接続の終了や待機リクエストの処理ごとにサーバからロードバランサーへの通知が必要になるため、通信量が増えるという課題もある。
重み付き最小接続数方式
- サーバの処理可能なアクティブ接続数（現在進行中のセッション数）に応じて重みを設定し、接続状況に基づいて動的にサーバを選ぶ。重みの考え方は重み付きラウンドロビン方式と似ているが、判断基準はリアルタイムの接続数となる。
最小応答時間方式（最速応答方式）
- サーバの応答時間を計測し、最も迅速に応答できるサーバを選択する動的アルゴリズム。最小接続数方式に、接続の完了や待機リクエストの処理時間などの平均応答時間を加味することで、より精度の高い振り分けが可能になる。
リソースベース方式
- 各サーバにインストールされたソフトウェアエージェントが、CPUやメモリなどのリソース使用状況を収集し、それに基づいてリクエストを割り振る動的アルゴリズム。リソースの可用性に応じた最適な負荷分散が可能になる。