TL
ホーム/ネットワーク/機器/ ロードバランサ(負荷分散装置)

L4 / L7・負荷分散・可用性確保

ロードバランサ(負荷分散装置)

複数のサーバへリクエストを振り分け、負荷を分散して可用性とスケールを確保する装置・機能ヘルスチェックで障害サーバを外し、L7 では URL ベースの振り分けや SSL 終端も行う

TL;DR要点だけ先に
  • 1.複数サーバへ振り分けて負荷を分散する装置。
  • 2.ヘルスチェックで落ちたサーバを自動的に外す。
  • 3.可用性とスケールが欲しいなら前段に LB を。

Core Facts

基本情報

Introducing

ロードバランサ(負荷分散装置)複数のサーバへリクエストを振り分け、負荷を分散して可用性とスケールを確保する装置・機能。ヘルスチェックで障害サーバを外し、L7 では URL ベースの振り分けや SSL 終端も行う。
OSI 層
L4トランスポート)/ L7アプリ)
主な機能
振り分け / ヘルスチェック / SSL 終端
方式
ラウンドロビン / 最小接続 / 重み付け
配置
サーバ群の前段
選ばれる理由
負荷分散で可用性とスケールを確保ヘルスチェックで障害ノードを自動排除
主な利用シーン
Web/API サーバの負荷分散無停止メンテ・ローリング更新 / SSL 終端・リバースプロキシ

Decision Guide

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

Why It Fits

選ぶ理由

  1. 負荷分散で可用性とスケールを確保
  2. ヘルスチェックで障害ノードを自動排除
  3. L7 で URL/ホスト別の振り分け・SSL 終端

Trade-offs

考慮すべき点

  1. それ自体が単一障害点→冗長化が必須
  2. L7 処理は CPU 負荷が高い
  3. セッション維持(スティッキー)の設計が要る

Deep Dive

もっと詳しく

どんな機器か

ロードバランサ(負荷分散装置)は、複数のサーバへリクエストを振り分ける 機器・機能です。クライアントからはひとつの窓口(仮想 IP)に見えますが、背後では複数のサーバが処理を分担します。これにより、可用性(1 台落ちても止まらない)とスケール(台数を増やせば処理能力が伸びる) を確保します。

動作する層によって L4 型L7 型 に分かれます。

どう動くのか

クライアントの接続を受け、設定したアルゴリズム(ラウンドロビン、最小接続数など)に従って各サーバへ割り振ります。重要なのが次の 2 つです。

  • ヘルスチェック:各サーバが正常に応答するか定期的に確認し、異常なノードは振り分け先から自動的に外す。復旧すれば戻す。
  • SSL 終端:クライアントとの TLS をロードバランサ側で終端し、背後のサーバ群の暗号処理負荷を減らす。証明書管理も一元化できる。

似た機器との違い

L4 と L7 で振り分けの粒度が違います。

  • L4(トランスポート層):IP とポート単位で振り分ける。中身を見ないぶん 高速 で、汎用的なTCP/UDP通信に向く。
  • L7(アプリケーション層):HTTP の URL やホスト名、ヘッダ を見て振り分けられる。/api はこのサーバ群、/img は別の群、といった柔軟な制御ができる。

リバースプロキシと機能が重なる部分が多く、製品によっては一体で提供されます。

設計・運用のポイント

  • スティッキーセッション:同一クライアントを毎回同じサーバへ固定する仕組み。サーバ側にセッションを保持する構成で必要になるが、固定しすぎると負荷が偏る。可能ならセッションを外部(共有ストア)に持たせ、固定への依存を減らすのが望ましい。
  • 自身が単一障害点:ロードバランサが落ちると全体が止まるため、冗長化が必須。2 台構成でフェイルオーバーする。

製品を選ぶときの観点

  • L4 か L7 か:URL ベースの振り分けや HTTP ヘッダ操作が要るなら L7。
  • SSL 終端の性能:TLS 処理を捌けるスループットか。
  • ヘルスチェックの柔軟性:アプリ層まで踏み込んだ死活監視ができるか。
  • 冗長構成と自動化:フェイルオーバー、設定の API 連携に対応するか。

Decision Context

ロードバランサ(負荷分散装置)を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

Web/API サーバの負荷分散

比較で見る軸

OSI 層: L4(トランスポート)/ L7(アプリ) / 主な機能: 振り分け / ヘルスチェック / SSL 終端 / 方式: ラウンドロビン / 最小接続 / 重み付け

導入後に効く点

ヘルスチェックで障害ノードを自動排除

先に潰すリスク

それ自体が単一障害点→冗長化が必須

数字・仕様の読み方
OSI 層
L4(トランスポート)/ L7(アプリ)
主な機能
振り分け / ヘルスチェック / SSL 終端
方式
ラウンドロビン / 最小接続 / 重み付け
配置
サーバ群の前段

判断チェックリスト

  • 自社の用途が「Web/API サーバの負荷分散 / 無停止メンテ・ローリング更新」に近いか確認する。
  • 強みである「負荷分散で可用性とスケールを確保」が本当に評価軸になるか確認する。
  • 注意点の「それ自体が単一障害点→冗長化が必須」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

Web/API サーバの負荷分散無停止メンテ・ローリング更新SSL 終端・リバースプロキシF5 BIG-IPCitrix ADC(NetScaler)A10 ThunderHAProxy / Nginx各クラウドの ELB / Azure LB / Cloud Load Balancing

Landscape

代表的な製品・サービス

F5 BIG-IP

商用 ADC の定番

Citrix ADC(NetScaler)
A10 Thunder
HAProxy / Nginx

OSS ソフトウェア LB

各クラウドの ELB / Azure LB / Cloud Load Balancing

Use Cases

こんな場面で使う

Web/API サーバの負荷分散無停止メンテ・ローリング更新SSL 終端・リバースプロキシ
参考リンク