ロードバランシングアルゴリズム早見表：ラウンドロビン・最小接続・IPハッシュ・加重

概要¶

「スケーリングはサーバーを追加するだけではない。トラフィックをスマートに分散することだ」という視点からのロードバランシング早見表。

詳細¶

アルゴリズム比較¶

アルゴリズム	仕組み	向いているケース
Round Robin	順番に均等に割り振る	サーバースペックが同等・リクエスト処理時間が似ている
Least Connections	現在の接続数が最も少ないサーバーへ	処理時間にばらつきがある（DB クエリ等）
IP Hash	クライアント IP でサーバーを固定	セッションの粘着性が必要な場合
Weighted	サーバーごとに重み付け	スペックが異なるサーバー群

詳細¶

Round Robin¶

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A  ← 最初に戻る

利点: シンプル、実装が容易
欠点: 処理時間の重いリクエストが特定サーバーに偏ると不均等

Least Connections¶

Server A: 10 connections
Server B: 3 connections  ← 次はここへ
Server C: 7 connections

利点: 負荷が実態に即して均等になる
欠点: 接続数の集計コストが発生
用途: API ゲートウェイ、WebSocket サーバー

IP Hash¶

hash(client_ip) % num_servers → 常に同じサーバー

利点: ステートフルなセッションを保持できる
欠点: サーバー追加/削除でルーティングが変わる（Consistent Hashing で解決）
用途: セッションをサーバーメモリに持つレガシーシステム
     （推奨: セッションは Redis 等の外部ストアへ）

Weighted Round Robin¶

Server A (weight=3): 3回に3回
Server B (weight=1): 3回に1回

Request 1 → A
Request 2 → A
Request 3 → A
Request 4 → B  ← 重みに応じた頻度

利点: 高スペックサーバーにより多くのリクエストを割り振れる

ヘルスチェック¶

ロードバランサーは定期的にバックエンドの生死を確認する。

# AWS ALB ヘルスチェック例
healthCheck:
  protocol: HTTP
  path: /health
  interval: 30 seconds
  threshold: 2   # 2回連続失敗でアウト
  timeout: 5 seconds

なぜ重要か / いつ使うか¶

システムデザイン面接で「どうスケールするか」の答えとして
nginx / AWS ALB / HAProxy の設定でアルゴリズムを選ぶとき
スパイクトラフィックへの対策を設計するとき