🧠【初心者向け】負荷分散（Load Balancing）の仕組みをやさしく解説（図解あり）

Webアプリがアクセス集中に耐えられるのは、
裏側で 負荷分散（ロードバランシング） が行われているからです。

しかし初心者がつまずきやすい点として、

ラウンドロビンって何？
スティッキーセッションは何のため？
LBの「ヘルスチェック」ってどこで何を見てるの？
L4/L7 の違いは何？
ALB / NLB / GCLB / Envoy って結局何が違うの？

など仕組みが見えにくく、全体像がつかみにくい領域です。

この記事では
初心者でも“本質がつかめる”視点 → 内部構造の深掘り の順で
負荷分散の核心を丁寧に理解できるように整理します。

✨ 結論
負荷分散とは何か？（初心者向けの本質）
1. 🔹 図解（短線版）
なぜ負荷分散が必要なのか？
負荷分散の方式（ロードバランシングアルゴリズム）
スティッキーセッションとは？
ヘルスチェックとは？
1. 種類
  1. ✔ L4ヘルスチェック
  2. ✔ L7ヘルスチェック
L4 / L7 ロードバランサの違い（超重要）
1. ✔ L4ロードバランサ
2. ✔ L7ロードバランサ
ここまでのまとめ（初心者向け）
内部構造：プロキシ型 / 経路制御型
1. ✔ プロキシ型
2. ✔ 経路制御（Direct Routing）
クラウドLBの役割（ネットワークの“入口”）
負荷分散の落とし穴
Auto Scaling と組み合わせると最強
Deep Friendly Tech の一言（後書き）

✨ 結論

✔ 負荷分散の本質は「複数サーバへ処理を均等に振り分ける」

✔ ラウンドロビン方式が基本形

✔ セッション維持にはスティッキーセッション

✔ 障害を検知してルートを切り替えるのがヘルスチェック

✔ L4/L7ロードバランサで“何を見るか”が変わる

✔ クラウド時代は LB が“アプリの入口そのもの” になった

負荷分散とは何か？（初心者向けの本質）

複数のサーバにリクエストを分散し、
1台への負荷集中（＝遅延・障害）を防ぐ仕組み。

🔹 図解（短線版）

      ┌───────────┐
User →│ LoadBalancer │→ Server1
      │               │→ Server2
      └───────────┘

なぜ負荷分散が必要なのか？

✔ 1台のサーバには限界がある

CPU / メモリ / 同時コネクション数に上限がある。

✔ どこか1台が落ちると全滅する

単一障害点（SPOF）を避ける必要がある。

✔ スケールアウト（横に増やす）ができる

クラウド時代は“台数を増やす”のが基本戦略。

負荷分散の方式（ロードバランシングアルゴリズム）

① ラウンドロビン（最も基本）

1件目 → Server1  
2件目 → Server2  
3件目 → Server1  
4件目 → Server2  
（交互に振り分け）

公平で、LBのデフォルト設定としてよく使われます。

② 加重ラウンドロビン（Weighted）

Server1（性能：高） → 2割  
Server2（性能：高） → 2割  
Server3（性能：低） → 6割

性能差がある時に使う。

③ 最小接続数（Least Connections）

今最も空いているサーバに振り分ける

トラフィックが偏りやすいアプリで有効。

④ IPハッシュ（Hash Based）

「ユーザーの IPアドレス」に基づいて振り分け

→ 特定ユーザーが同じサーバに当たり続ける。

スティッキーセッションとは？

セッションIDを見て、
同じユーザーを同じサーバに固定する仕組み。

🔹 図解

User A → Server1（常にこのサーバへ）
User B → Server2（別サーバへ）

スティッキーが必要な例

セッション情報がサーバローカルにある
ショッピングカート状態をメモリに持つ
ユーザーごとに状態が変わるアプリ

デメリット

負荷が偏る
サーバ障害時にセッションが飛ぶ
近年は「セッションを外部に出す」（Redis 等）方針が主流

ヘルスチェックとは？

死んでいるサーバ・重いサーバへ振り分けないために
自動で状態を監視する仕組み。

種類

✔ L4ヘルスチェック

TCP/UDPレベルで“ポートが生きているか”を見る。

✔ L7ヘルスチェック

HTTP リクエスト（/health など）を送り“アプリが正常か”を見る。

L4 / L7 ロードバランサの違い（超重要）

✔ L4ロードバランサ

TCP/UDP
とにかく高速
内容までは見ない（暗号化されたTLSもOK）

例：AWS NLB、GCP TCP LB

✔ L7ロードバランサ

HTTP/HTTPS
リクエストの内容を見てルーティング可能
スマートな振り分け

例：AWS ALB、GCP HTTP LB、Envoy

ここまでのまとめ（初心者向け）

負荷分散は複数サーバに処理を分ける仕組み
ラウンドロビンが基本
スティッキーセッションは“固定”の仕組み
ヘルスチェックで障害サーバを自動遮断
L4/L7で「どこを見るか」が変わる

▼▼ 深掘り編ここから ▼▼

内部構造：プロキシ型 / 経路制御型

✔ プロキシ型

LBがリクエストを受け付け、
バックエンドへ転送する方式。

例：ALB, GCLB(HTTP)

✔ 経路制御（Direct Routing）

LBを経由せず、サーバ同士が通信する。

例：LVS, 一部のNLB構成

クラウドLBの役割（ネットワークの“入口”）

クラウドでは、LB が “アプリの入口” です。

TLS終端（HTTPSの復号）
HTTP/2・gRPC対応
WAF連携
Auto Scaling と連動
パスベース / ホストベースルーティング
リージョン跨ぎの負荷分散

単なる“分散装置”ではありません。

負荷分散の落とし穴

⚠ ① スティッキーを乱用して偏りが発生

⚠ ② ヘルスチェックの失敗閾値が甘い

⚠ ③ L7でルールを書きすぎて遅くなる

⚠ ④ LBを単一障害点にしてしまう

⚠ ⑤ DBは基本的にスケールしない（誤解）

→ LB でさばけても DB が詰まるケースはよくある

Auto Scaling と組み合わせると最強

LB と Auto Scaling Group（ASG）を組み合わせると、

負荷が増えると自動でサーバ増加
減ったらサーバ削減
コスト最適化
トラフィックに強い

クラウド設計の王道パターン。

Deep Friendly Tech の一言（後書き）

負荷分散は
「Webアプリが当たり前に動く理由」
を支える最重要パーツです。

特にクラウドネイティブでは
LB がネットワークの“入り口”として
機能の集約点になります。

理解を深めることで

高負荷アプリのボトルネック調査
設計レビュー
障害対応
インフラとの連携

など、多くの場面で一段深い議論ができるようになります。