ロードバランサーの仕組み — お店の受付が担当へ振り分けるように

ひよこ

同じお店なのに、担当が何人もいるの？

ペンギン先生

Webサイトも複数のサーバーが同じ仕事を担当することがあるよ。入口のロードバランサーが、届いた要求を設定したルールで担当へ振り分けるんだ。

ひよこ

順番に送るのが基本？

ペンギン先生

ラウンドロビンならA、B、A、Bという具合だよ。重みや利用できる担当の状態も影響する。本文では二人の担当に順番に割り当てる小さなモデルを試せるよ。

ひよこ

暇な担当を選ぶ方法もある？

ペンギン先生

接続数が少ない担当を選ぶleast connectionsなどがあるよ。ただし接続数が少ないこととCPUが暇なことは同じではない。用途に合う判断方法を選ぶんだ。

ひよこ

故障した担当へは送らない？

ペンギン先生

ヘルスチェック等で異常を検知してから対象から外す設計があるよ。検知までの失敗はありうるし、全担当が異常な場合も製品ごとに違う。AWS ALBには全台異常でも送るfail openという挙動があるんだ。

ひよこ

L4とL7って何？

ペンギン先生

L4は主に接続のIPやポートなど、L7はHTTPのホストやパスなどに基づく振り分けだよ。L7なら商品ページとAPIを別の担当へ送るようなルールを作れるんだ。

ひよこ

担当が変わったらカートが消えない？

ペンギン先生

カートを一台のメモリだけに置くと困る場合があるよ。外部の共有ストアを使う方法や、同じ担当に送るセッション維持がある。ただし担当の障害や期限切れで維持できないことも考えるんだ。

ひよこ

振り分けるだけでサーバーも増える？

ペンギン先生

追加するのはオートスケーリングなど別の仕組みだよ。増えたサーバーの登録と準備完了を連携させる。ロードバランサー自体や共通DBがボトルネックにならないかも見よう。

ひよこ

最初に何を確認するといい？

ペンギン先生

誰へ送るか、異常をどう判定するか、状態をどこに保存するかの三つだよ。図では受付と担当を分けて見よう。CDNのキャッシュやDNSの名前解決とは役割が違うんだ。

まず、AとBへ順番に仕事を配る

Python 3で次を round-robin-demo.py に保存し、python round-robin-demo.py を実行します。

from itertools import cycle

targets = cycle(["サーバーA", "サーバーB"])
for request in range(1, 5):
    print(f"要求{request} → {next(targets)}")

A、B、A、Bの順で表示されます。これは割り当てのルールだけの練習で、実際のネットワーク通信やヘルスチェックは行いません。

一つの入口と、複数の担当

受付役は、自分が要求を処理するのではなく、利用できる担当を選びます。ラウンドロビン、重み付き、接続数、ハッシュなど選び方があります。一台へ長い処理が集中する場合、要求数が同じでも負荷が均等とは限りません。

NGINXの基本設定では upstream に複数の担当を登録し、proxy_pass で渡します。導入手順はNGINX入門へ。使用する製品が能動的なチェックを行うか、通常の通信の失敗を使うかも確認してください。

ヘルスチェックで、何を確かめるか

「HTTP応答が返る」だけでは、DBへ保存できることまで分からない場合があります。チェックするパス、応答コード、タイムアウト、連続失敗・成功の条件を決めます。故障の検知と復旧の復帰には時間がかかりえます。

AWS ALBでは、登録先がすべてunhealthyの場合にそれらへ送るfail openが文書化されています。「チェックがあるから故障先への通信が必ずゼロ」とは考えないようにしましょう。

もう少し詳しく：状態と入口の冗長化

セッション維持は同じ担当へ送る仕組みで、状態の複製ではありません。カートやログイン情報を引き継ぐには、共有ストアや保存方法も設計します。

担当を増やしても、入口や共通DBが一つの故障点なら全体は止まります。入口の冗長性、接続の排出、ログや失敗率を確認しましょう。オートスケーリングの仕組みは担当の増減、CDNの仕組みは配信とキャッシュの話です。

ペンギン先生のまとめ

「ロードバランサー」って出てきたら「届いた仕事を、複数の担当へ振り分ける受付」と思えばだいたいOK！ 担当の状態と、カートなどの保存先もセットで考えよう。

参考資料

• NGINX：HTTP load balancing — 振り分け方法・受動的チェック
• AWS：ALB health checks — 異常判定とfail open
• AWS：Target group attributes — セッション維持と登録解除