この記事の要点

ロードバランサ (負荷分散装置) は、複数のサーバへ要求を振り分けて 1 台あたりの負荷を下げ、可用性とスケーラビリティを高める仕組み トランスポート層で振り分ける L4 ロードバランサ (NLB) と、HTTP の内容まで見て振り分ける L7 ロードバランサ (ALB) がある 分散アルゴリズムにはラウンドロビン・最小接続 (least connections)・IP ハッシュ・重み付けなどがある ヘルスチェックで各サーバの生死を監視し、ダウンしたサーバへは要求を送らないことで可用性を担保する 同一ユーザを同じサーバへ固定するセッション維持 (スティッキーセッション) が必要な場合もある

概要

ロードバランサ (load balancer / 負荷分散装置) とは、クライアントからの要求を複数のサーバへ振り分ける装置・ソフトウェアです。1 台のサーバに処理が集中するのを防ぎ、全体の処理能力 (スケーラビリティ) と、一部が壊れても止まらない可用性 (アベイラビリティ) を高めます。Web サイトへのアクセスが増えても、後ろにサーバを追加していくだけで捌けるようにする「スケールアウト」の要となる仕組みです。親項目の 負荷分散・プロキシ・CDN を参照してください。

実体は リバースプロキシ と重なる部分が多く、nginx や HAProxy はリバースプロキシでありロードバランサでもあります。クラウドでは NLB (Network Load Balancer) や ALB (Application Load Balancer) としてマネージドサービスが提供されています。

仕組み

ロードバランサは、どの層 (レイヤ) の情報を見て振り分けるかで大きく 2 種類に分かれます。OSI 参照モデルの第 4 層か第 7 層かが分類の軸です。

• L4 ロードバランサ (NLB): トランスポート層 (TCP/UDP) の情報、すなわち IP アドレスとポート番号だけを見て振り分ける。中身を解釈しないため非常に高速で、HTTP 以外のプロトコルも扱える。
• L7 ロードバランサ (ALB): アプリケーション層まで見て、HTTP のパス・ホスト名・Cookie・ヘッダの内容に応じて振り分ける。/api はアプリ群、/img は静的配信群、といった賢いルーティングができる。SSL 終端もここで行うことが多い。

振り分け方 (分散アルゴリズム) には次のようなものがあります。

• ラウンドロビン: サーバを順番に 1 台ずつ均等に回す。最も基本的でシンプル。
• 最小接続 (least connections): その時点で接続数が最も少ないサーバへ送る。処理時間にばらつきがある場合に有効。
• IP ハッシュ: クライアント IP のハッシュ値で送り先を決める。同じ IP は常に同じサーバへ行くため、簡易的なセッション固定になる。
• 重み付け (weighted): 性能の高いサーバに多めの重みを与え、能力に応じて配分する。

さらに、各サーバが正常かを定期的に確認するヘルスチェックと、同じ利用者を同じサーバへ固定するセッション維持 (スティッキーセッション) が重要な要素です。

設定・実用例

nginx の upstream を使った L7 ロードバランサの例です。3 台のバックエンドへ最小接続方式で分散し、重み付けとヘルスチェック (失敗回数) を指定しています。

upstream app_backend {
    least_conn;                              # 最小接続方式

    server 10.0.0.11:3000 weight=3;          # 高性能機に多めの重み
    server 10.0.0.12:3000 weight=1;
    server 10.0.0.13:3000 weight=1 max_fails=3 fail_timeout=30s;

    # IP ハッシュで固定したい場合は least_conn の代わりに:
    # ip_hash;
}

server {
    listen 80;
    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

各サーバの生死は、外形監視として定期的に確認できます。

# 各バックエンドのヘルスチェック用エンドポイントを叩く例
curl -s -o /dev/null -w "%{http_code}\n" http://10.0.0.11:3000/healthz
curl -s -o /dev/null -w "%{http_code}\n" http://10.0.0.12:3000/healthz

主な用途

• スケールアウト: アクセス増に対しサーバを横に並べ、ロードバランサで分散して処理能力を上げる。
• 高可用性: 1 台が故障しても残りで処理を継続し、サービス停止を防ぐ。
• 無停止メンテナンス: 対象サーバをヘルスチェックから外して切り離し、更新後に戻す (ローリングアップデート)。
• SSL 終端: L7 LB で HTTPS を一括復号し、バックエンドを単純化する。
• 地理/用途別振り分け: パスやホスト名でマイクロサービス群へ振り分ける。

L4 と L7 の比較

観点	L4 ロードバランサ (NLB)	L7 ロードバランサ (ALB)
見る情報	IP アドレス + ポート	HTTP パス・ヘッダ・Cookie
速度	非常に高速	解析する分やや重い
対応プロトコル	TCP/UDP 全般	主に HTTP/HTTPS
賢いルーティング	不可 (中身を見ない)	可 (パス/ホスト別)
SSL 終端	基本しない (素通し)	得意

注意点

• ロードバランサ自体の冗長化: LB が単一障害点になると本末転倒。LB 自体も冗長構成 (アクティブ/スタンバイ等) にする。
• セッション維持の落とし穴: スティッキーセッションで特定サーバに固定すると、そのサーバ停止時にセッションが失われる。セッションを外部 (Redis 等) に持たせる設計が望ましい。
• ヘルスチェックの設計: チェックが甘いと故障機に送り続け、厳しすぎると正常機を切り離す。エンドポイントと閾値を適切に決める。
• 偏り: ラウンドロビンでも処理時間がばらつくと負荷が偏る。最小接続や重み付けを検討する。
• クライアント IP の保持: L7 LB ではバックエンドから見た送信元が LB の IP になるため、X-Forwarded-For で元 IP を引き継ぐ。

関連リンク

• 負荷分散・プロキシ・CDN
• リバースプロキシ
• HAProxy
• nginxリバースプロキシ設定
• HTTP