負荷分散の基礎と実践：可用性・スケーラビリティを両立する総合ガイド
エバープレイ編集部負荷分散とは — 基本定義と目的
負荷分散（ロードバランシング、load balancing）とは、複数のサーバやサービス間で要求（トラフィック、接続、処理）を適切に振り分けることで、単一ノードへの過負荷を防ぎ、可用性・スループット・応答性を向上させる技術とその仕組みの総称です。Webサービス、API、データベース読み取りレプリカ、メール配信など、スケールや信頼性が求められる領域で広く使われます。
なぜ負荷分散が必要か
- 可用性の確保：バックエンドの一部が障害を起こしても、他の健全なノードへトラフィックを迂回させることでサービス継続を実現します。
- スケーラビリティ：トラフィック増加時に処理を複数ノードへ分散してスループットを向上させられます。水平スケール（ノード追加）との親和性が高いです。
- パフォーマンス最適化：負荷を均等化することで応答時間のばらつきを軽減し、ユーザー体験を改善します。
- 保守性：ノードの入れ替えやソフトウェア更新を行う際に、トラフィックを避けることでゼロダウンタイム運用が可能になります。
負荷分散の基本的なタイプ
負荷分散は実装レイヤや運用形態によって分類できます。代表的なものを挙げます。
- DNSラウンドロビン（名前解決ベース）：DNS応答を変更して複数IPを返す簡易的な分散。シンプルだがキャッシュやDNS TTLに依存し、細かいヘルスチェックや重み付け制御が難しい。
- レイヤ4（L4）ロードバランサ：TCP/UDPレベルで接続を振り分ける。パケット／接続単位で処理するため高速で低レイテンシ。例：AWS NLB、IPVS、ハードウェアロードバランサ。
- レイヤ7（L7）ロードバランサ：HTTP/HTTPSなどアプリケーション層の内容（パス、ヘッダ、Cookie）に基づいてルーティング可。リクエスト単位での高度な制御やリライト、TLS終端が可能。例：NGINX、Envoy、AWS ALB。
- ハードウェア vs ソフトウェア：従来は専用機（F5、Citrix等）で実装されてきましたが、現在はソフトウェア型（HAProxy、NGINX、Envoy）やクラウドマネージド（AWS ELB、GCP Load Balancing等）が主流です。
- クラウドマネージド vs 自前運用：クラウドプロバイダのLBは管理が容易でスケーリング自動化が強み。自前運用はコストやカスタマイズ性、オンプレ要件で選ばれます。
振り分けアルゴリズム（代表例）
どのノードに振り分けるかを決めるルールは重要です。主なアルゴリズム：
- ラウンドロビン：順番に振り分ける最も単純な方式。状態を持たないがノード性能差があると不均等になる。
- 重み付きラウンドロビン：ノード毎に重みをつけ、性能差を考慮して振り分ける。
- 最小コネクション（Least Connections）：現在の接続数が少ないノードへ振る。長時間接続（WebSocket等）に有効。
- 最小レスポンスタイム：応答が速いノードを優先。ヘルスチェックと組み合わせて動的に評価する。
- ソースIPハッシュ／コンシステントハッシュ：クライアントIPやセッションIDに基づいたハッシュでノードを決定。再配置やキャッシュの有効利用に便利。
セッション永続化（スティッキーセッション）とその問題点
一部アプリケーションはセッション情報をサーバローカル（メモリ）で管理しており、同一クライアントの要求を常に同じバックエンドに送る必要があります。これをスティッキーセッション（セッション永続化）と言います。実装方法はCookie方式、IPハッシュ方式などがあります。
ただしスティッキーを多用すると負荷分散の効果が減り、特定ノードへ負荷集中・スケーリングの柔軟性低下を招きます。推奨はセッションを外部ストア（Redisやデータベース）に移すなどしてステートレス化することです。
ヘルスチェックとフェイルオーバー
信頼性を保つために、ロードバランサはバックエンドの健全性を監視します。代表的なチェック：
- TCPポート接続確認（L4）
- HTTPステータス確認（L7）— ステータスコードとレスポンスボディの検査
- カスタムヘルスエンドポイント（/health, /ready）
ヘルスチェックの閾値（連続失敗回数、成功回数のしきい値）、間隔、タイムアウト設定は重要です。短くしすぎると誤検知が増え、長すぎると切り替えが遅れて障害影響が拡大します。
TLS（SSL）終端と再暗号化
ロードバランサでTLS終端（SSLオフロード）を行うと、バックエンドは平文HTTPで通信でき、CPU負荷を軽減できます。代わりにロードバランサ側で証明書管理が必要です。一方、セキュリティ方針でバックエンドまでTLSを維持したい場合は、TLSを終端せずにTLSパススルー（NLBのようなL4方式）を使うか、ロードバランサで復号後に再暗号化してバックエンドに送る（SSL re-encryption）構成が取られます。
アーキテクチャ上のモード（NAT、プロキシ、DSRなど）
- NATモード／プロキシモード：ロードバランサが宛先を書き換えたり、バックエンドへの接続をプロキシしたりする。クライアントの送信元IPアドレスがバックエンドから見えない場合があり、X-Forwarded-For等のヘッダで実装する。
- DSR（Direct Server Return）：ロードバランサは受信したパケットの振り分けのみ行い、応答はバックエンドが直接クライアントへ返す方式。負荷分散装置の負荷が下がるがネットワーク設定が複雑。
- プロキシ（フルプロキシ）方式：クライアントとバックエンド間で独立した接続を確立。セキュリティや制御（WAF、レート制限）が行いやすい。
クラウドネイティブ環境とサービスメッシュの関係
コンテナ／Kubernetesの世界では、負荷分散は複数レイヤにまたがっています。KubernetesのServiceはクラスタ内部での通信を抽象化し、IngressやService type=LoadBalancerで外部トラフィックを受けます。kube-proxyはiptablesやIPVS方式でPodへトラフィックを振り分けます。
サービスメッシュ（例：Istio、Linkerd）はサイドカープロキシ（Envoyなど）を用いてマイクロサービス間のL7トラフィック制御、トラフィックシフト、リトライ、回路遮断（circuit breaker）などを提供し、従来のロードバランサの機能を補完・拡張します。
観測・監視・テスト
運用で重要な指標：
- リクエストレート（RPS/秒）
- アクティブ接続数
- レスポンスレイテンシ分布（p50, p95, p99）
- バックエンドのヘルスステータス、エラー率（5xx）
- スループット（Mbps）とCPU/メモリ使用率
Prometheus + Grafana、ELK/EFK、Datadogなどを使って可視化します。負荷テストツール（wrk、k6、JMeter、ab）で代表的なワークロードを模してスルーリング、レイテンシ、エラーレートのボトルネックを発見します。
セキュリティ面の取り組み
- TLSの強制・最新プロトコルと強力な暗号スイートの利用
- WAF（Web Application Firewall）でのシグネチャ検査やルール適用
- レート制限でブルートフォースやスクレイピングを抑制
- DDoS対策：クラウドプロバイダの保護（AWS Shield、Cloudflare等）やWAFと組み合わせる
- ログと監査の整備：不審トラフィックの検出とフォレンジック対応
パフォーマンス最適化のポイント
- キープアライブ（HTTP keep-alive）やコネクションプールでオーバーヘッドを低減
- TLSセッション再利用・セッションチケットでTLSハンドシェイクコストを抑える
- HTTP/2やgRPCなどの多重化プロトコルを活用して同接続内で複数リクエストを捌く
- ロードバランサ自体のスケーリング（水平スケール、冗長構成）を設計
- キャッシュ（CDNやアプリケーションキャッシュ）と組み合わせて負荷を低減
選定時の考慮事項（事例的ガイドライン）
- トラフィック特性：短いHTTPリクエスト多数か、長時間接続が多いか（WebSocket等）
- 必要なレイヤ：L4で十分か、L7で詳細制御が必要か
- 運用体制：証明書管理・TLS更新、ルール更新の運用負荷
- 可用性要件：マルチAZ/リージョンでの冗長化、フェイルオーバー時間
- コスト：マネージドサービスのランニングコストと自前運用の人件費との比較
- セキュリティ要件：WAFやDDoS保護、監査ログの保持
よくある落とし穴・運用上の注意点
- ヘルスチェックの閾値設定ミスで不必要な切替や無駄な検出遅延を招く
- スティッキーセッション過多で負荷分散効果が薄れる
- TLS証明書の期限切れによる障害（自動更新の仕組みが必須）
- バックエンドのリソース（ファイルディスクリプタ、接続上限）を見落とすとボトルネックになる
- DNSベースの分散はキャッシュ／TTLによる切替遅延が発生する点を理解する
まとめ（実践的なベストプラクティス）
- 設計はステートレス化を第一に：セッションを外部化するとスケーリングが楽になる
- ヘルスチェックとメトリクスを丁寧に設計し、可観測性を確保する
- L4とL7の利点を目的に応じて使い分ける（性能重視ならL4、ルーティング制御やWAFならL7）
- クラウドを使う場合はマネージドLBの特性（ALB/NLB/GLB等）を理解して選定する
- セキュリティはロードバランサの責務でもある：TLS管理、WAF、DDoS対策を組み込む
- 定期的な負荷試験と障害注入（chaos engineering）で実運用時の振る舞いを検証する
参考文献
- 負荷分散 - Wikipedia（日本語）
- NGINX - HTTP Load Balancing（公式ドキュメント、英語）
- HAProxy Documentation - Load Balancing（公式ドキュメント、英語）
- AWS Elastic Load Balancing（公式ドキュメント、英語）
- Google Cloud Load Balancing（公式ドキュメント、英語）
- Kubernetes — Service（公式ドキュメント、日本語）
- Envoy Proxy — What is Envoy?（公式ドキュメント、英語）
- OWASP（セキュリティ全般とベストプラクティス、英語）
投稿者プロフィール
