ロードバランシング

ロードバランシングとは

ロードバランシング (Load Balancing) は、複数のサーバーにトラフィックを分散し、単一サーバーへの過負荷を防ぎ、可用性とスケーラビリティを向上させる仕組みである。

AWS のロードバランサー

AWS のロードバランサーを以下にまとめる。

タイプ	レイヤー	用途
ALB (Application)	L7 (HTTP)	Web API、パスベースルーティング
NLB (Network)	L4 (TCP/UDP)	高スループット、低レイテンシ
GWLB (Gateway)	L3 (IP)	ファイアウォールや侵入検知など検査アプライアンスの挿入
CLB (Classic)	L4/L7	前世代 (現行世代への移行が推奨)

現行世代は ALB / NLB / GWLB の 3 つで、CLB は前世代として位置づけられている (2026 年 8 月時点)。新規構築で CLB を選ぶ理由はない。

分散アルゴリズム

分散アルゴリズムを以下に整理する。

アルゴリズム	説明	ALB
ラウンドロビン	順番に振り分け	デフォルト
最小接続数	接続数が少ないサーバーに振り分け	最小未処理リクエスト方式として選べる
IP ハッシュ	クライアント IP でサーバーを固定	非対応 (下記)
加重	重み付きで振り分け	ターゲットグループ単位の重み、またはターゲット単位の加重ランダム方式

ALB のアルゴリズムはラウンドロビン (既定)・最小未処理リクエスト・加重ランダムの 3 種で、クライアント IP でハッシュを取る方式は持たない。同じクライアントを同じターゲットへ寄せたい場合は、ALB が発行するクッキー (既定は 1 日) かアプリケーション側のクッキーを使うスティッキーセッションで行う。IP アドレスに基づく固定が必要なら、TCP のフロー情報でターゲットを決める NLB を選ぶ。

スティッキーセッションはセッション情報をサーバー側に持つ設計を延命させるだけで、偏りとフェイルオーバー時のセッション喪失は残る。セッションを外部ストアに追い出すのが本筋である。

パスベースルーティング

パスベースルーティングを図で示す。

ALB
  /api/*     → API サーバー (ECS)
  /admin/*   → 管理画面サーバー (EC2)
  /ws/*      → WebSocket サーバー

ヘルスチェックに失敗したターゲットはトラフィックから自動的に除外される。

ALB のターゲットに指定できるのは EC2 インスタンス・IP アドレス・Lambda 関数のいずれかで、S3 バケットを直接ターゲットにはできない。静的ファイルは後述のように CloudFront から S3 を配信し、ALB には動的リクエストだけを通す。

サーバーレスでのロードバランシング

Lambda + API Gateway の場合、ロードバランシングは不要。API Gateway が自動的にリクエストを Lambda に振り分け、Lambda が自動スケールする。

アーキテクチャ	ロードバランサー
ECS / EKS	ALB が必要
Lambda + API Gateway	不要 (自動)
EC2	ALB / NLB が必要

CloudFront との組み合わせ

CloudFront との組み合わせを図で示す。

ユーザー → CloudFront (CDN) → ALB → ECS

CloudFront で静的コンテンツをキャッシュし、動的リクエストのみ ALB に転送する。

さらに掘り下げるなら関連書籍が参考になる。

サイト情報

ロードバランシング