【仕組み解説】ロードバランサーはどうやってアクセスを振り分けているのか — 負荷分散の裏側を図解

簡単に言うと、Webサイトへのアクセスを複数のサーバーに振り分ける「交通整理係」だよ。大きな交差点に警察官が立って、車を右や左に誘導するイメージだね。

1台のサーバーで処理できるリクエスト数には限界があるんだ。たとえばセールの日にECサイトに100万人が一気にアクセスしたら、1台では到底さばけないよね。だから複数台のサーバーを用意して、リクエストを均等に分散させるんだよ。これが「負荷分散」— つまりロードバランシングだね。

いくつかのアルゴリズムがあるよ。一番シンプルなのが「ラウンドロビン」で、順番にA→B→C→A→B→C…と回していく方法。もうひとつは「最小接続数（リーストコネクション）」で、今一番ヒマなサーバーに送る方法。あとは「IPハッシュ」といって、アクセス元のIPアドレスから送り先を決める方法もあるよ。

それを防ぐのが「ヘルスチェック」だよ。ロードバランサーは定期的に各サーバーに「生きてる？」と確認のリクエストを送るんだ。応答がないサーバーは自動的に振り分け対象から外して、残りの正常なサーバーだけにリクエストを送るようにするよ。復旧したらまた自動で戻すこともできるんだ。

OSI参照モデルのどの層で振り分けを判断するかの違いだよ。L4（レイヤー4）はトランスポート層、つまりIPアドレスとポート番号だけを見て振り分ける。高速だけど中身は見ない。L7（レイヤー7）はアプリケーション層、つまりURLのパスやHTTPヘッダーの中身を見て振り分けるんだ。たとえば「/api/は処理用サーバーへ、/images/は画像サーバーへ」みたいなルーティングができるよ。

いいところに気づいたね。それを解決するのが「スティッキーセッション（セッション維持）」だよ。最初に接続したサーバーを覚えておいて、同じユーザーのリクエストは常に同じサーバーに送る仕組みだね。CookieにサーバーIDを埋め込む方法が一般的だよ。ただし、そのサーバーが落ちるとセッションが失われるから、最近はセッション情報をRedisなどの外部ストアに保存するのが主流だね。

そうだね。AWSならALB（Application Load Balancer）がL7、NLB（Network Load Balancer）がL4に対応しているよ。Google CloudにはCloud Load Balancingがあって、グローバルに分散できるのが特徴だね。クラウドのロードバランサーはオートスケーリングと組み合わせて、アクセスが増えたら自動でサーバーを追加して、減ったら縮小する — ということが簡単にできるのが大きなメリットだよ。

いい質問だね。CDNは「コンテンツを地理的に近い場所から配信する」仕組みで、画像やCSS・JSなどの静的ファイルを世界中のエッジサーバーにキャッシュしておくものだよ。一方ロードバランサーは「オリジンサーバーの負荷を分散する」のが目的で、動的なリクエストも含めて処理を振り分けるんだ。実際の大規模サービスでは、CDNで静的ファイルをさばきつつ、動的リクエストはロードバランサー経由でサーバー群に振り分ける — という二段構えになっていることが多いよ。

そうだね。ちなみに現場の豆知識として、ロードバランサー自体が単一障害点にならないよう、ロードバランサーも冗長化するのが基本だよ。アクティブ-スタンバイ構成にしたり、DNSラウンドロビンで複数のロードバランサーに分散させたりするんだ。「負荷分散装置を負荷分散する」って面白い話だけど、可用性を追求するとそういう構成になるんだね。