ロードバランサ完全ガイド：種類・アルゴリズム・TLS終端・セッション管理まで徹底解説
エバープレイ編集部ロードバランサとは — 概要
ロードバランサ（ロードバランサー、ロードバランシング装置）は、クライアントからのリクエスト（接続）を複数のバックエンド（サーバ群、サービスインスタンス）に振り分けるためのネットワークコンポーネントです。主な目的は可用性の向上、スループットの最大化、レスポンス遅延の低減、そして単一障害点（SPOF: Single Point Of Failure）の排除です。ロードバランサは物理的ハードウェア、仮想アプライアンス、ソフトウェア（プロキシ系）やクラウドサービスとして提供されます。
ロードバランサの主な種類
- DNSベースのロードバランシング：DNS応答で複数のIPを返すことで分散する（ラウンドロビンDNS等）。簡易だが細かいヘルスチェックやセッション制御はできない。
- レイヤ4（L4）ロードバランス：TCP/UDPレベルで接続を振り分ける。低遅延で高スループット、TLSパススルーにも対応可能。例：NLB（AWS）、ハードウェアLB。
- レイヤ7（L7）ロードバランス：HTTP/HTTPS等、アプリケーションプロトコルの内容（URL、ヘッダ、Cookie）に基づいてルーティングできる。例：ALB（AWS）、NGINX、Envoy。
- リバースプロキシ型：実装上はL7プロキシが多く、リクエストを受けて代行してバックエンドに送る。TLS終端やキャッシュ、WAF機能を統合できる。
基本的な動作原理
ロードバランサへ到達したリクエストは、内蔵のアルゴリズム（ルール）とバックエンドの状態情報に基づき配送先が決定されます。多くのロードバランサは定期的にバックエンドをヘルスチェック（HTTPステータス、TCPハンドシェイク、独自API）し、異常なサーバを自動的に除外して健全なインスタンスのみへ振り分けます。
代表的な振り分けアルゴリズム
- ラウンドロビン：順番に振り分ける。シンプルだがサーバ能力を考慮しない。
- 重み付きラウンドロビン：サーバごとに重みを付け、より強力なサーバに多く振る。
- 最小コネクション（Least Connections）：現在の接続数が最少のサーバへ振る。長時間接続がある場合に有効。
- IPハッシュ／クライアントハッシュ：クライアントIPやヘッダ等のハッシュにより同じクライアントを同じサーバへ誘導（セッション性を保つ際に使う）。
- 一貫性のあるハッシュ（Consistent Hashing）：キャッシュや分散セッションでノード追加/削除時の再配置を最小化する。
セッション管理とステート（Sticky Session）
ステートフルなアプリケーションでは、同一利用者のリクエストを同じサーバに送る必要がある場合があります。これを「セッションアフィニティ（Sticky Session）」と呼び、実装方法は主に以下：
- ロードバランサによるIPアフィニティ
- Cookieベースのアフィニティ（LBが特定のCookieをセット）
- アプリケーション側でセッション共有（Redis等の外部セッションストア）にしてステートレス化するのが一般に推奨される
TLS/SSLの終端とパススルー
ロードバランサはTLS終端（オフロード）を行い、暗号化処理を解除して以降は平文でバックエンドへ転送することができます。これによりバックエンドの負荷が下がり、L7処理（パスやヘッダに基づくルーティング）が可能になります。一方、TLSパススルーは暗号化を維持したまま接続をバックエンドに中継し、エンドツーエンド暗号化が保たれます。SNI（Server Name Indication）を用いた複数ドメインの処理や、証明書管理の考慮が必要です。
ヘルスチェックとグレースフルシャットダウン
ヘルスチェックは単に「応答があるか」を見るだけでなく、アプリケーションレベルの状態（503を返す、特定のAPI応答）まで確認可能です。サーバのメンテナンス時は接続ドレイン（connection draining）を行い、新規接続を止め既存接続を完了させることで切断やデータ破損を防ぎます。
高可用性とスケーリング戦略
ロードバランサ自体も可用化が必要です。一般的な構成はアクティブ-アクティブ（複数LBによる分散）やアクティブ-スタンバイ（フェイルオーバー）で、クラスタリングや共有設定・状態同期を行います。クラウドではマネージドLB（ALB/NLB/GCP/Azure）を使うことで運用負荷を削減できます。スケールは水平スケーリング（インスタンス追加）が基本で、オートスケーリングと連携して需要に追随します。
セキュリティ機能との連携
ロードバランサはWAF（Web Application Firewall）、レート制限、IP制限、DDoS防御の前段として機能することが多いです。L7のプロキシでは不正なヘッダやリクエストボディの検査、ボット対策なども実装できます。
代表的なソフトウェアとクラウドサービス
- オープンソース / ソフトウェア：HAProxy、NGINX（Open Source / NGINX Plus）、Envoy、Traefik
- 商用 / ハードウェア：F5 BIG-IP、Citrix ADC（旧NetScaler）等
- クラウド提供：AWS（ALB、NLB、Classic LB）、Google Cloud Load Balancing、Azure Load Balancer / Application Gateway、Cloudflare等のエッジサービス
- サービスメッシュ（Envoyベース等）：Istio、Linkerd等。マイクロサービス内部の東西トラフィック制御に使われる
運用で重要なポイントと監視指標
- 監視：リクエストレート（RPS）、エラー率、平均/95/99パーセンタイル応答時間、アクティブ接続数、バックエンドのヘルス状態
- ログ：アクセスログ、エラーログ、ヘルスチェックログを保存して障害解析に活用
- テスト：障害注入（Chaos）、リージョン障害想定のフェイルオーバーテスト
- 構成管理：証明書更新、自動化（IaC）、ロールアウト時の段階的適用
よくある課題と対策
- Sticky Sessionに頼りすぎるとスケール性が悪化する → セッション共有でステートレス化を検討
- ヘルスチェックが甘いとトラフィックが不健康なインスタンスへ流れる → アプリケーションレベルの深いチェックを導入
- TLSオフロードでセキュリティポリシーが分断される → 内部ネットワークでも暗号化したい場合はTLSパススルーや内向きTLSを利用
- 過負荷時の不均衡 → 適切なアルゴリズム選定と自動スケールの設定
まとめ
ロードバランサは現代の分散システムやクラウドアーキテクチャにおいて不可欠なコンポーネントです。適切なレイヤ（L4/L7）、振り分けアルゴリズム、ヘルスチェック、セキュリティ連携を選ぶことがシステムの可用性・性能・運用性を左右します。ステート管理やTLSの扱いなど設計上のトレードオフを理解し、監視と自動化を組み合わせて運用することが重要です。
参考文献
- HAProxy 公式サイト
- NGINX：Load balancing — NGINX documentation
- Envoy Proxy Documentation
- AWS Elastic Load Balancing の概要（Amazon）
- Google Cloud Load Balancing ドキュメント
- Azure Load Balancer ドキュメント
- Load balancing (computing) — Wikipedia
投稿者プロフィール
