ロードバランサの選定 — L4とL7、どこで負荷分散を切るか

ロードバランサをどこに置き、何レイヤーで動かすかという判断は、セッション設計・TLS終端・ヘルスチェックの粒度・冗長化方式と不可分に絡み合う。「後から足せばいい」という発想で構築を進めると、10台以上のサーバーに展開した後でアプリ・ネットワーク・セキュリティポリシーの三方向に変更が波及し、手戻り工数が初期設計の数倍に膨らむ。本記事では、L4とL7の役割の違いを設計視点で整理したうえで、ハードウェアLB・ソフトウェアLB・クラウドLBのトレードオフ、ヘルスチェックとセッション維持の設計、そして「分散しすぎ・集約しすぎ」の境界線を判断するためのフレームを示す。

負荷分散を後から挟むと構成が破綻する構造

後付けLBが生む依存関係の連鎖

アプリケーションが単一サーバーを前提に設計された状態でロードバランサを後付けすると、セッション管理・IPアドレス参照・TLS証明書の配置といった複数の前提条件が同時に崩れる。接続元IPをアプリ内で直接参照している設計では、LBを前段に置いた途端にすべてのリクエストがLBのIPから来ているように見え、アクセス制御ロジックが機能しなくなる。この修正を10台以上のサーバーに展開した後で行おうとすると、アプリ側・ネットワーク側・セキュリティポリシー側の三方向で変更作業が発生し、工数は初期設計時に組み込んだ場合の3倍以上になることが多い。LBは「追加する機器」ではなく「構成の前提条件」として最初から設計に織り込む必要がある。

セッション設計との不可分な関係

ロードバランサの設置場所と方式は、セッションの持ち方に直結する。ステートフルなセッションをアプリサーバーのメモリに保持している構成では、LBがリクエストを別のサーバーに振り分けた瞬間にセッションが失われる。後から外部セッションストア（RedisやMemcachedなど）を追加するためには、アプリコードの修正・デプロイ・データ移行が必要になり、それ自体がリリースリスクとなる。セッション設計はLBの選定と同時に決定しなければ、後の工程で必ず行き詰まる。逆に言えば、セッション方式が先に決まれば、LBに求める機能要件も自ずと絞り込める。

TLS終端の場所が決まっていない構成の危うさ

TLSをどこで終端するかはLB選定の前提条件であり、後から変更すると影響範囲が広い。クライアント〜LB間でTLSを終端する場合、バックエンドはHTTPで受け取れるが、証明書の管理はLBに集中する。エンドツーエンドで暗号化したい場合はTLSパススルーになるが、この場合はL7での振り分けができない。TLS終端の設計を後回しにした構成では、証明書の更新手順・バックエンドのポート設定・ファイアウォールルールを後から再整理する事態になり、変更のたびに影響範囲の確認コストがかかり続ける。

L4分散とL7分散の役割の違いを設計視点で

L4分散の強みと適切な用途

L4ロードバランサはTCP/UDPレイヤーで動作し、パケットの中身を参照せずに送信先を決定する。処理オーバーヘッドが小さく、毎秒数十万〜数百万コネクションを扱う高スループット環境でも安定して動作する。データベースへのTCP接続をバランシングする用途や、HTTPSをパススルーでバックエンドに渡す構成では、L4が適切な選択になる。ただし、URLパスやHTTPヘッダによる振り分けはできないため、マイクロサービスのように「サービスごとに異なるバックエンドへルーティング」という要件には応えられない。シンプルさゆえの速さと引き換えに、アプリケーション層の制御は捨てることになる。

L7分散が必要になる設計パターン

L7ロードバランサはHTTP/HTTPSの中身を解析し、URLパス・ホストヘッダ・Cookieの値・HTTPメソッドなどを条件にルーティングを制御できる。マイクロサービス環境では /api/orders を注文サービスへ、/api/inventory を在庫サービスへとパスベースで分散できる。WebSocketやHTTP/2のサポート、gzip圧縮、レートリミットなどの機能もL7で実現できる。一方で、TLSパースとHTTPデコードの処理が加わるため、L4と比較してレイテンシが数ミリ秒増加することがある。高頻度の短命なリクエストが大量に来る環境では、このオーバーヘッドの積み重なりを事前に測定しておくべきだ。

両方を組み合わせる2段構成の判断軸

外部トラフィックをL4で受け、後段にL7を配置する2段構成は、DDoS対策と細かいルーティング制御を両立したい場合の選択肢になる。前段のL4がIPフィルタリング・SYNフラッド対策・TCPコネクション管理を担い、後段のL7がアプリケーション層のルーティングを担う設計は、大規模な公開サービスで採用されることがある。ただし、2段構成はIPのリライトやL2ループなど構成が複雑になり、デバッグに習熟した担当者が必要になる。単純な構成を保てるなら1段で完結させる判断の方が、長期的な運用コストを抑えられる場合も多い。

比較表: ハードLB／ソフトLB／クラウドLBのトレードオフ

区分	スループット上限の目安	設定変更の柔軟性	初期コスト感	運用属人化リスク
ハードウェアLB	数百万セッション/秒（ASIC依存）	低（ベンダーノウハウ必要）	高（数百万円〜）	高
ソフトウェアLB（HAProxy/NGINX）	数万〜数十万セッション/秒（NIC依存）	高（テキスト設定・GitOps対応）	低〜中（サーバー代のみ）	中
クラウドマネージドLB	自動スケール（制限値あり）	中（UI/API操作・制限あり）	低（従量課金）	低

ハードウェアLBが有利な場面

専用ハードウェア（F5 BIG-IPやA10 Networksなど）は、ASICによるハードウェアオフロードで毎秒数百万セッションを処理できる。金融系や通信系の本番環境での採用実績が多く、SLAや保守契約が明確という点も選定理由になることがある。反面、設定変更にベンダー固有のノウハウを要するため、担当者が変わったときに属人化が発生しやすい。ハードウェアLBが本当に必要かどうかは、スループット要件を具体的な数値で測定した上で判断すべきであり、「実績があるから」という理由だけで選定するのは避けた方がよい。

ソフトウェアLBの設計上の扱い

HAProxyやNGINXをソフトウェアLBとして運用するアプローチは、設定のコード管理（GitOps）が容易で変更履歴を追いやすいという利点がある。ただし、カーネルへの依存やNICの性能上限があり、単一ノードで捌けるスループットの天井はハードウェアLBより低い。Keepalivedとの組み合わせでVIPをフェイルオーバーさせる構成が定番だが、フェイルオーバーの切り替え時間（通常1〜3秒）とアプリ側の再試行設計を合わせて検討しなければ、短時間の接続断をサービス断として扱ってしまう設計になる。

クラウドLBで意識すべき設計の差異

AWSのALB/NLB、GCPのCloud Load Balancing、AzureのApplication Gatewayはマネージドサービスとして運用コストを抑えられる。一方で、ターゲットグループの登録件数上限・リクエストの最大バイト数・WebSocketの接続維持時間などに制限があり、設計段階で制限値を把握せずに構築を進めると、本番直前で設計変更を迫られる事例が現場ではよく見られる。クラウドLBの制限はドキュメントを確認するだけでなく、想定トラフィックのシミュレーションテストで実際に検証することが、設計の精度を高めるうえで重要になる。

ヘルスチェックとセッション維持をどう設計するか

ヘルスチェックの粒度が運用品質を左右する

ヘルスチェックをTCPのポート死活だけに留めると、アプリケーションプロセスは起動しているがリクエストを正常に処理できない「半壊状態」を検出できない。HTTPの200応答を確認する程度では、依存するデータベースやキャッシュサーバーが停止している状況を見抜けないことがある。理想的なヘルスチェックエンドポイントは、DB接続・外部API疎通・ストレージioを軽量に確認して結果を返す設計にすべきだが、これをアプリ側に実装せずにLBのチェック設定だけを変えても意味はない。ヘルスチェックはLBとアプリの共同設計で成立するものだという認識が出発点になる。

セッション維持（スティッキーセッション）の設計リスク

特定クライアントを常に同じバックエンドに固定するスティッキーセッション（ソースIPハッシュやCookieベースのアフィニティ）は、ステートフルなアプリを改修せずにLBを挟む場合の逃げ道として使われることがある。しかし、特定バックエンドに負荷が集中するホットスポット問題や、バックエンドの1台が落ちたときにそのユーザーのセッションが失われるという問題が残る。スティッキーセッションを採用する場合は、それがアーキテクチャ的な妥協であると明示した上で、外部セッションストア化のロードマップを同時に持っておくことが設計上の判断として求められる。

ドレイニングとゼロダウンタイムデプロイの設計

バックエンドをローリングアップデートする際、コネクションドレイン（AWSではDeregistration Delay、HAProxyではgrace period）を適切に設定しないと、処理中のリクエストが強制切断される。ドレイン時間はアプリ側のリクエスト最大処理時間より長く確保することが基本になる。実際の構築現場では、ドレイン時間をデフォルト値（例: 300秒）のまま放置して不必要に長い切り替え時間を生んでいる事例や、逆に短すぎてリクエスト断が発生している事例が見受けられる。数値の根拠を持って設定するかどうかが、デプロイ品質を分ける境界になる。

冗長化とスケールを見越したLB配置の判断

SPOF（単一障害点）としてのLBを排除する

ロードバランサ自体がSPOFになることは、冗長化の目的と矛盾する。ソフトウェアLBをActive-Standby構成で冗長化する場合、VIPのフェイルオーバー遅延・ハートビート検出間隔・DNSキャッシュのTTLの3つを組み合わせて設計しないと、実効的な切り替え時間が想定より長くなる。クラウド環境ではマネージドLBが内部的に冗長化されているが、リージョン障害時の挙動は事前に確認しておく必要がある。50台規模の本番環境で「LBが1台でも問題ない」と判断していた現場が、LB再起動1回で15分のサービス断を経験したという話は珍しくない。

水平スケールとLBの性能限界の見極め

バックエンドサーバーをスケールアウトしても、LBがボトルネックになると性能が頭打ちになる。ソフトウェアLBをシングルノードで運用している場合、NICのスループット上限（10Gbps程度）やカーネルのコネクション処理能力がボトルネックになりやすい。DNSラウンドロビンでLBを複数配置するアプローチは単純だが、DNSキャッシュのためにトラフィックの偏りが発生する。ECMP（等コストマルチパス）を活用してL3レベルで複数LBへ均等に振り分ける構成は、高トラフィック環境での水平スケールに有効だが、設計難度は上がるため、必要性の見極めが先になる。

マルチAZ・マルチリージョン構成でのLB設計

クラウド環境でマルチAZ構成を取る場合、LBのAZ間トラフィックコストとレイテンシも設計変数になる。クロスゾーン負荷分散を有効にすると各バックエンドへ均等に振り分けられるが、AZ跨ぎのトラフィックが発生する。無効にするとAZ内で閉じるがバックエンド台数の偏りが生じやすい。マルチリージョン構成の場合はGTM（グローバルトラフィックマネージャー）やGeolocation DNSとLBを組み合わせる判断が必要になるが、障害時のフェイルオーバー設計が複雑になるため、本当にマルチリージョンが必要な要件かどうかを先に確定させることが優先される。

分散しすぎ・単一LBに寄せすぎの境界

過剰なLBレイヤーが生む運用コスト

マイクロサービス化の流れの中で、サービスごとにLBを立てる設計が増えることがある。しかしLBの台数が増えると、証明書の更新・ヘルスチェックの設定・ルーティングルールの管理が乗算的に増え、構成管理の負荷が上がる。5サービスにそれぞれL7 LBを立てた環境では、証明書の更新だけで月に1〜2回の定期作業が発生し、設定ドリフトのリスクも上がる。KubernetesのIngressコントローラが集約点になる場合も、その冗長化と性能設計を別途考慮しなければ、集約したことが新たなSPOFを生む結果になる。

単一LBに集約しすぎたときの硬直化

全トラフィックを1つのLBに集約する設計は管理が楽だが、変更の影響範囲が広い。特定サービスのルーティングルール変更が他サービスの設定に影響するリスク、特定サービスのトラフィック急増が他サービスに波及するリスク、LBのバージョンアップを計画するたびに全サービスが影響を受けるリスクが生じる。この硬直化は規模が小さい段階ではほとんど問題にならないが、サービス数が10を超えたあたりから顕在化することが多いと、構築経験者からは繰り返し聞かれる。

適切な分散単位を見つける設計判断

LBのレイヤー設計における判断軸は、「変更の独立性」と「管理の統一性」のバランスになる。同じリリースサイクル・同じチームが管理するサービス群は1つのLBに集約し、独立したリリースが必要なサービスや異なる可用性要件を持つサービスは別LBに分離するという判断が、現場では機能しやすい。Ingressを利用する場合は、ネームスペース単位の分離かIngressClassによる論理分割かを早期に決め、後から構造を変えることのコストが高いと理解した上で設計する必要がある。

ロードバランサ設計チェックフレーム

選定前に確定すべき要件の洗い出し

ロードバランサを選定する前に、プロトコル要件（HTTP/HTTPS/TCP/UDP）・最大スループット・セッション設計・TLS終端の場所・ヘルスチェックの粒度・冗長化要件の6点を文書化しておく。これらが曖昧なまま機材調達やクラウドリソースのプロビジョニングを先行させると、後から選定をやり直す事態になる。特にスループット要件は、現在の規模ではなく2〜3年後の予測値で設計することが、スケールアップ時の再構成コストを抑えるポイントになる。要件が確定していない状態での選定は、後の設計変更リスクを最小化するという目的に逆行する。

チェックリストを使った設計レビューの進め方

LB設計のレビューは、要件整理・選定・設定・テストの各フェーズでそれぞれ異なる観点が必要になる。以下のチェックフレームを用いて各フェーズの抜け漏れを確認する。設計レビューはLBの設定が完成した後ではなく、選定フェーズの段階で一度実施することで、手戻りリスクを大幅に減らせる。

• 【要件確定】プロトコル要件（HTTP/TCP/UDP）を明文化したか
• 【要件確定】ピーク時のスループット・コネクション数を数値で見積もったか
• 【要件確定】TLS終端の場所（LBか、バックエンドか）を決定したか
• 【選定】L4かL7かの選択理由を設計ドキュメントに記録したか
• 【選定】LB自体の冗長化構成（Active-Standby／Active-Active）を決めたか
• 【選定】クラウドLBの場合、最大ターゲット数・最大リクエストサイズ等の制限値を確認したか
• 【設定】ヘルスチェックがアプリケーション層まで確認できる設計になっているか
• 【設定】セッション維持の方式（スティッキー or ステートレス）を決定したか
• 【設定】コネクションドレイン時間をアプリの最大処理時間をもとに設定したか
• 【テスト】フェイルオーバーの切り替え時間を実測したか
• 【テスト】ピークスループットを想定した負荷試験でLBがボトルネックになっていないか確認したか
• 【テスト】バックエンド1台障害時のリクエスト影響範囲をテストしたか

設計を見直す判断タイミング

ロードバランサの設計は一度決めたら固定ではなく、サービスの成長フェーズや構成変更に合わせて見直す機会を持つことが重要になる。バックエンドサーバー台数が初期設計の倍を超えたとき、新しいプロトコル要件（HTTP/2やgRPC）が追加されたとき、マルチリージョン展開を検討し始めたときは、現行のLB設計が前提条件を満たし続けているかを確認するタイミングになる。変更の判断を先送りにすると、技術的負債として積み重なり、次の大型リリースの直前に設計変更を強いられる状況に陥りやすい。設計の見直しを「問題が起きてから」ではなく「節目ごとに」行う文化が、長期的な構成の健全性を支える。