この記事の要点

クラウドロードバランサは、複数のサーバへ通信を振り分けて負荷分散・高可用性を実現するマネージドサービス。 ALB は L7(アプリケーション層)で動き、HTTP のパスやホスト名を見てルーティングできる。 NLB は L4(トランスポート層)で動き、TCP/UDP を超高速・低遅延でさばく。固定 IP を持てる。 CLB は旧世代の汎用ロードバランサで、新規は用途に応じて ALB か NLB を選ぶのが基本。 振り分け先のサーバ群は「ターゲットグループ」としてまとめ、ヘルスチェックで正常なサーバにだけ流す。 オートスケールと連携してサーバの増減に自動追従し、SSL/TLS の終端(復号)もロードバランサで担える。

概要

クラウドロードバランサ(Load Balancer、負荷分散装置)とは、クライアントからの通信を背後にある複数のサーバへ振り分けることで、負荷の分散と高可用性を実現するマネージドサービスです。1 台のサーバに通信が集中して処理しきれなくなることを防ぎ、また一部のサーバが故障しても残りのサーバで処理を継続できるようにします。

クラウドのロードバランサは、自分でハードウェアを用意したりソフトウェアを構築したりする必要がなく、クラウド事業者が冗長化・スケーリングまで含めて運用してくれます。代表的な AWS では、用途に応じて ALB(L7)・NLB(L4)・CLB(旧世代)の種類があり、扱う通信の層(レイヤ)や機能が異なります。どれを選ぶかが、性能とルーティングの柔軟性を左右します。

仕組み

ロードバランサは、振り分け先のサーバ群をターゲットグループ(対象グループ)としてまとめて管理します。そして各ターゲットに対してヘルスチェックを定期的に行い、正常応答するサーバにだけ通信を流します。異常になったサーバは振り分け対象から自動的に外され、復旧すると再び戻されます。

          [クライアント]
                │
        ┌───────▼────────┐
        │ ロードバランサ   │  ← ヘルスチェックで生死判定
        └──┬─────┬─────┬──┘
           │     │     │
        ┌──▼─┐ ┌─▼──┐ ┌─▼──┐
        │ EC2 │ │EC2 │ │EC2 │  ← ターゲットグループ
        │ OK  │ │OK  │ │NG ✗│     NG は振り分け対象外
        └─────┘ └────┘ └────┘

ALB(Application Load Balancer)は OSI 参照モデルのL7(アプリケーション層)で動作します。HTTP/HTTPS の中身を解釈できるため、URL のパス(/api/* はサーバ群 A、/img/* はサーバ群 B)やホスト名に応じた高度なルーティングが可能です。

NLB(Network Load Balancer)はL4(トランスポート層)で動作し、TCP/UDP のパケットを中身を見ずに超高速・低遅延でさばきます。秒間数百万接続規模に耐え、固定 IP アドレスを持てるのも特徴です。HTTP に依存しないプロトコルや、極端な性能要件で選ばれます。

さらにロードバランサはSSL/TLS 終端を担えます。クライアントとの間の暗号化(HTTPS)をロードバランサで復号し、背後のサーバへは平文(または内部用の暗号)で渡すことで、各サーバの証明書管理や暗号処理の負荷を肩代わりします。

構成・実用例

ALB でパスベースルーティングと SSL 終端を行い、オートスケールと連携する構成例です。

[ユーザー] ── HTTPS(443) ──▶ ALB (SSL 終端 / 証明書管理)
                                │
                ┌──────────────┴──────────────┐
        path /api/*                     path /*
                │                             │
        ┌───────▼────────┐            ┌──────▼─────────┐
        │ API ターゲット   │            │ Web ターゲット   │
        │ グループ        │            │ グループ        │
        │ (Auto Scaling)  │            │ (Auto Scaling)  │
        └─────────────────┘            └────────────────┘
        負荷増 → インスタンス自動追加、ALB が自動で振り分け対象に登録

AWS CLI でターゲットグループを作り、ヘルスチェックパスを設定する例です。

# ターゲットグループ作成(ヘルスチェックは /health)
aws elbv2 create-target-group --name web-tg \
    --protocol HTTP --port 80 --vpc-id vpc-xxxx \
    --health-check-path /health

オートスケールと組み合わせると、アクセス急増時にサーバが自動で増え、ロードバランサがそれを即座に振り分け先へ加えます。深夜などアクセスが減ればサーバを減らし、コストも最適化されます。

主な用途

• Web アプリの負荷分散と冗長化 — 複数の Web/AP サーバへ振り分け、単一障害点をなくします。
• SSL/TLS の集約管理 — 証明書をロードバランサに集約し、サーバ側の暗号処理負荷を下げます。
• パス/ホストベースのルーティング(ALB) — 1 つの入口から複数サービスへマイクロサービス的に振り分けます。
• 超高スループットな TCP/UDP 処理(NLB) — ゲーム・IoT・金融など低遅延・大量接続の用途に使います。

関連技術との比較

項目	ALB(L7)	NLB(L4)	CLB(旧世代)
動作レイヤ	L7(アプリ層 / HTTP)	L4(TCP/UDP)	L4/L7 簡易
ルーティング	パス/ホスト/ヘッダ単位	ポート単位	限定的
性能・遅延	高機能・やや高遅延	超高速・超低遅延	中程度
固定 IP	不可(DNS 名)	可能	不可
SSL 終端	得意	可能	可能
推奨	HTTP アプリ全般	低遅延/非 HTTP	非推奨(新規は ALB/NLB)

注意点・落とし穴

• ヘルスチェックの設定ミス — チェック先パスが認証必須だったり 200 を返さないと、正常なサーバまで「異常」と判定され全滅します。専用の /health を用意します。
• 用途に合わないタイプ選択 — HTTP のパスルーティングが要るのに NLB を選ぶと実現できません。L7 が必要なら ALB です。
• ALB は固定 IP を持てない — IP ホワイトリスト連携が必要な相手には DNS 名ではなく固定 IP を持つ NLB を検討します。
• セキュリティグループとの整合 — ロードバランサからバックエンドへの通信が、ターゲット側のセキュリティグループで許可されていないと振り分けに失敗します。
• SSL 終端後の内部通信 — ロードバランサで復号した後の内部経路が平文だと盗聴リスクが残ります。要件に応じて内部も暗号化します。

関連リンク

• クラウドネットワーク
• VPC
• サブネット(クラウド)
• セキュリティグループ
• VPNゲートウェイ・専用線接続
• クラウド・インフラ
• アドレッシング・識別子
• プライベートIPアドレス