ロードバランサの仕組みを図にした。分散より「落ちた先を外す」ほうが本題

• 複数のサーバーに振り分ける仕組み
• 効き目が大きいのは1台落ちても止まらないこと
• 困るのはどの機械に当たるか分からないこと

「負荷分散」という名前から、速くするための仕組みに見える。実際に効くのは、むしろ止まらないほうだ。

立ち位置はリバースプロキシ

MDNは、負荷の分散をリバースプロキシの主な利用法の1つとして挙げている。複数のウェブサーバーに負荷を分ける役割だ。

つまり利用者から見ると、奥に何台あるかは見えない。窓口は1つに見える。

振り分け方にも種類がある

3番目は、やむを得ず選ぶことが多い。ログイン状態などを1台の中に持っていると、別の台に当たった瞬間に失われるからだ。

本来は持たせないほうがよい

HTTPはもともと前のやり取りを覚えていない。だからサーバー側に状態を持たせなければ、どの台に当たっても同じ結果になる。

状態を外に出す（共有のデータベースや保存領域に置く）と、3番目の方式に縛られずに済む。台数を増やすのも楽になる。

いちばん困るのは「当たったときだけ失敗する」

台が複数あると、こういう形の不具合が出る。

• 一時ファイルを手元に置いた → 書いた台と読む台が違うと見つからない
• 1台にだけ設定を入れた → その台に当たったときだけ挙動が違う
• 1台だけ更新し忘れた → 古い内容がたまに返る
• 画像のアップロード先が各台のディスク → 別の台からは見えない

共通するのは再現しないことだ。何度か試すと直ったり直らなかったりする。

「自分だけ動かない」「たまにおかしい」という症状が出たら、当たっている先が毎回違う可能性を候補に入れる。切り分けの順番は表示が遅い原因を、順番に調べた作業にまとめた。

落ちた先を外すには、生死を見ている必要がある

自動で外せるのは、各台が生きているかを定期的に確認しているからだ。この確認が甘いと、落ちた先に送り続けることになる。

確認の作り方で結果が変わる。

• 接続できるかだけ見る … サーバーは生きているが、中のアプリが壊れている状態を検出できない
• 決まったページを開いて内容まで確認する … アプリが動いているところまで分かる
• データベースまで確認する … 奥まで見られるが、確認そのものが負荷になる

どこまで見るかは、検出したい障害の種類で決める。

増やしても速くならない場合

台数を増やせば速くなる、とは限らない。詰まっている場所が別なら、何台足しても変わらない。

• データベースが1つ — ウェブサーバーを増やしても、奥が同じなら奥で詰まる
• 処理そのものが遅い — 1件に10秒かかるなら、台数を増やしても1件は10秒のまま
• 外部のサービス待ち — 待ち時間は台数で減らない

増やす前にどこで時間を使っているかを測る。台数を増やすのは、同時に捌ける数が足りないと分かってからでよい。

止まる前提で考える

台数を増やしても、全部が同じ原因で落ちることはある。設定の誤りを全台に配った場合などだ。

サービスが止まったときに作業を止めない備えは、使う側でも必要になる。考え方は使っているAIサービスが止まった日に、作業を止めないためにしたことに書いた。

まとめ

• ロードバランサはリバースプロキシの役割の1つ
• 効き目が大きいのは分散より落ちた先を外すほう
• 振り分け方は、順番／接続数／同じ先へ固定
• サーバーに状態を持たせないと、台を自由に増やせる
• 困るのは「当たったときだけ失敗する」再現しない不具合
• 生死の確認は、どこまで見るかで検出できる障害が変わる

出典

• MDN「プロキシーサーバーとトンネリング」（リバースプロキシの利用法としての負荷分散）
• MDN「HTTP の概要」（ステートレス性）

図は本記事のために作成したもの。本記事は2026年10月13日時点の内容に基づく。