ロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説【2026年版】

ロードバランサー（負荷分散装置）は、複数のサーバーへリクエストを振り分け、1台に負荷が偏るのを防ぐ仕組みです。この記事では、ロードバランサーがどうやって振り分け先を決め、故障したサーバーをどう切り離すのか、L4とL7の実装差、ラウンドロビンなどの振り分け方式、ヘルスチェックとセッション維持、そしてAWS ELBやKubernetesでの構成まで、システム設計の判断材料として実装目線で整理します。「どのタイプを選べばよいか」「自社の規模で本当に必要か」に、条件付きで答えます。

まとめ｜ロードバランサーの役割と導入判断で外さない基準

ロードバランサーは、受け取ったリクエストを複数のサーバーへ分配し、処理を1台に集中させないための装置です。狙いは2つあります。台数を増やして処理能力を水平に伸ばすスケールアウトと、1台が落ちても残りで受け続ける可用性の確保です。この2つを同時に満たすのが、単純なサーバー増設との違いになります。

タイプ選びは「性能の数字」ではなく、何を見て振り分けたいかで決めます。IPとポートだけで高速にさばくならL4、URLやCookieを見た経路制御が要るならL7が出発点です。自前運用ならNginxやHAProxy、クラウド上ならAWSのALB／NLBが現実的な選択肢になります。小規模で常時稼働の要件が薄いなら、DNSラウンドロビンや単一サーバーで足りることもあります。迷ったら「止まると何円失うか」を先に見積もり、その額が構築・運用コストを上回るときに導入する——これが本記事の結論です。

ロードバランサーとは｜複数サーバーへ負荷分散する仕組みと役割

Webサービスへのアクセスが増えると、1台のサーバーでは処理が詰まり、応答が遅れたり停止したりします。サーバーを複数並べても、アクセスを均等に配る仕組みがなければ意味がありません。その配分役がロードバランサーです。クライアントから見える受付窓口を1つに保ちながら、裏側の複数サーバーへ処理を割り振ります。

リクエストを複数サーバーへ振り分けるロードバランサーの基本動作

ロードバランサーは、公開用のIPアドレス（仮想IP、VIP）を1つ持ち、利用者からのアクセスをすべてここで受けます。受けたリクエストは、背後に登録した複数のサーバー群（サーバープール、ターゲットグループ）のどれか1台へ転送されます。利用者はサーバーが何台あるかを意識せず、常に同じ窓口へアクセスするだけです。裏側では、サーバーを追加・撤去してもプールへの登録を変えるだけで済み、公開用の窓口は変わりません。この「窓口の一本化」と「背後の可変性」の分離が、台数を柔軟に増減できる土台になります。

単一障害点を避け可用性を高める冗長化とロードバランサーの関係

サーバーを1台構成にすると、その1台が落ちた瞬間にサービス全体が止まります。この「そこが壊れると全体が停止する箇所」を単一障害点（SPOF）と呼びます。ロードバランサーは複数サーバーへ分散することで、1台の故障は残りの台数で吸収し、単一障害点を減らせる構図です。ここが冗長化という考え方の実装面での中心です。ただしロードバランサー自身を1台で組むと、今度はそこが新たな単一障害点になります。実運用ではロードバランサーも2台以上で組み、Active-Standbyや Active-Activeで冗長化するのが前提です。VRRPやkeepalivedで仮想IPを引き継ぎ、片方が落ちてももう片方が窓口を継続します。

ロードバランサーの種類｜L4とL7・アプライアンスとソフトの違い

ロードバランサーは2つの軸で分類できます。1つはOSIのどの層で振り分けるか（L4かL7か）、もう1つはどの形態で動かすか（専用機かソフトウェアかクラウドか）です。この2軸で自社の要件に合う組み合わせを絞り込みます。

トランスポート層L4とアプリケーション層L7の振り分けの違い

L4ロードバランサーは、トランスポート層（TCP／UDP）のIPアドレスとポート番号だけを見て転送します。中身のHTTPを解釈しないため高速で、秒間の処理量（スループット）を稼ぎやすいのが持ち味です。対してL7ロードバランサーは、アプリケーション層のHTTP／HTTPSを解釈し、URLのパスやホスト名、Cookie、HTTPヘッダーを見て振り分け先を変えられます。たとえば「画像は画像用サーバー、APIはAPI用サーバー」といった経路制御や、HTTPSの復号（SSLターミネーション）はL7の領分です。判断軸はシンプルで、中身を見た振り分けが要るならL7、要らず速度優先ならL4を選びます。

両者は排他ではありません。外側でNLB（L4）が大量の接続を受け、内側でALB（L7）が経路制御する二段構成も定番です。まず「中身で振り分ける必要があるか」を決めるのが、層を選ぶ最初の分岐になります。

アプライアンス・ソフトウェア・クラウドLBを選ぶときの判断軸

形態は3つに分かれます。専用ハードウェア（アプライアンス）は、F5のBIG-IPやCitrix ADC、A10などが代表で、高いスループットと手厚いサポートが強みで、機器費と保守費がかかる形です。ソフトウェアLBは、Nginx（1.27系）やHAProxy（3系）、Envoyを汎用サーバー上で動かす方式で、費用を抑えつつ構成を柔軟に組めます。これらのソフトウェアLBが動く土台となるOSは、Linuxとは何かとサーバー用途の解説で整理しています。クラウドLBは、AWSのELB（ALB／NLB）やAzure Load Balancer、Google Cloud Load Balancingなど、マネージドサービスとして従量課金で使えます。オンプレの基幹で高い性能が要るならアプライアンス、コストと自由度を取るならソフトウェア、運用の手離れを優先しクラウド上で組むならクラウドLB、が実務での切り分けです。マイクロサービスのように内部通信の経路制御が主題になる構成では、L7の振り分けが設計の中心になります。サービス分割の考え方はモノリスとマイクロサービスの違いとモジュラモノリスの整理で先に押さえると、どこにロードバランサーを置くかが見えてきます。

リバースプロキシとロードバランサーの違いと重複する領域の整理

「リバースプロキシとロードバランサーは何が違うのか」は、実装でよく混乱する点です。リバースプロキシは、クライアントとサーバーの間に立つ代理サーバーで、キャッシュ、SSL復号、アクセス制御などを担い、背後が1台でも成立します。ロードバランサーは複数サーバーへの分散が主目的です。両者が重なるのは、NginxやEnvoyのようなL7ソフトウェアが、リバースプロキシとして動きながら同時に複数サーバーへ負荷分散するケースです。つまりL7ロードバランサーの多くは、リバースプロキシの機能の上に負荷分散を載せた形で実装されます。区別のコツは「代理が主目的ならリバースプロキシ、分散が主目的ならロードバランサー」と役割で見ることです。

Kubernetesのロードバランサーとクラスタ内の負荷分散

コンテナ環境では、ロードバランサーの位置づけが少し変わります。Kubernetesでは、Serviceという抽象がクラスタ内のPod群へトラフィックを分散し、その実体はノード上のkube-proxy（iptablesまたはIPVS）です。外部からの入口には、Service（type LoadBalancer）でクラウドのL4 LBを割り当てるか、Ingressコントローラー（Nginx IngressやEnvoyベース）でL7の経路制御を行います。コンテナの増減に追従して振り分け先が自動で入れ替わる点が、従来の固定サーバー構成との違いです。Kubernetes自体の仕組みはKubernetesの読み方・K8sの意味から仕組みまでの解説にまとめており、本記事はその中の負荷分散部分を実装目線で補完します。

負荷分散アルゴリズムとヘルスチェック｜振り分けと監視の仕組み

ロードバランサーの中身は、大きく「どう配るか（振り分け方式）」と「どこへ配ってよいか（ヘルスチェック）」の2つで動きます。ここを理解すると、応答の偏りや障害時の挙動を設計で制御できるようになります。

ラウンドロビン・最小コネクション・重み付けの振り分け方式の違い

振り分け方式にはいくつかの型があります。実務でまず押さえるのはラウンドロビンと最小コネクション数の2つです。ラウンドロビンは登録サーバーへ順番に均等配分する方式で、各サーバーの性能が揃っている構成に向きます。最小コネクション数は、そのときつながっている接続が最も少ないサーバーへ回す方式です。処理時間にばらつきがある構成で偏りを抑えられます。サーバー性能に差があるなら、配分量を性能比に応じて変える重み付けラウンドロビンが有効です。送信元IPから固定的に振り分け先を決めるIPハッシュ方式は、後述のセッション維持と関わります。均等配分を既定にし、接続やサーバー性能に偏りが出るなら最小コネクションや重み付けへ切り替える、という順で選ぶと外しません。

ヘルスチェックで障害サーバーを自動的に切り離す監視設定の要点

振り分け先の中に故障したサーバーが混じっていると、そこへ回されたリクエストがエラーになります。これを防ぐのがヘルスチェックです。ロードバランサーは各サーバーへ定期的に生存確認を送り、応答が返らないサーバーをプールから自動的に外します。確認方法には層があり、L4ではTCP接続が張れるかを見て、L7ではHTTPで特定パスへアクセスし応答コード（200番台か）まで確認する二段構えです。設定では、何秒間隔で確認し、何回連続で失敗したら切り離すか（しきい値）を決めます。間隔を短くすれば障害検知は速くなりますが、確認通信そのものがサーバーへ負荷をかけるため、検知速度と負荷のバランスで値を決めるのが実務の勘所です。復旧を検知したサーバーは自動でプールへ戻します。

セッション維持（スティッキーセッション）の必要性と設計上の対策

同じ利用者のリクエストを毎回同じサーバーへ送りたい場面があります。ログイン状態やカート情報をサーバーのメモリに持つ設計だと、別サーバーへ回された瞬間に情報が失われるためです。これを解決するのがセッション維持（スティッキーセッション、セッションアフィニティ）で、Cookieや送信元IPをもとに同一サーバーへ固定します。ただし副作用も見逃せません。特定サーバーへ利用者が張り付くため負荷が偏りやすく、そのサーバーが落ちるとセッションごと失われます。台数を増やしても均等に分散しにくくなる弱点もあります。設計の本筋は、セッション情報をサーバーの外（RedisなどのセッションストアやDB）に出し、どのサーバーでも処理できるステートレス構成にすることです。スティッキーセッションは、既存アプリを短期で載せ替える際の妥協策として使い、恒久策はステートレス化に置くのが堅実です。

企業がロードバランサーを導入すべき条件と過剰投資を避ける判断

ここは他社の解説が踏み込まない、採否を言い切る章です。原則は「可用性かスケールアウトのどちらかが業務要件になったときに入れる」で、検索ボリュームや流行で判断しません。要件が薄いまま冗長構成を組むと、機器費と運用の複雑さだけが増えます。

トラフィック量と可用性要件からロードバランサー導入を検討する条件

次のいずれかに当てはまるなら、ロードバランサーの導入を具体的に検討する段階です。1台のサーバーで処理しきれないトラフィックが常態化している、計画停止や1台の障害でもサービスを止められない（可用性が売上や信用に直結する）、キャンペーンなどで負荷が数倍に跳ねる時間帯がある。とくにECや予約、業務基幹のように停止コストが高いシステムでは、複数台構成とロードバランサーはほぼ前提になります。判断の軸は台数ではなく「止まったときの損失額」で、それが構築・運用コストを上回るなら投資の合理性があります。

小規模で導入を見送る場面とDNSラウンドロビンで足りるケース

一方、見送ってよい場面もはっきりしています。アクセスが少なく1台で余裕があり、短時間の停止が業務上許容できる社内ツールや情報サイトでは、ロードバランサーは過剰です。数台へ大まかに分散したいだけなら、DNSに複数のAレコードを登録するDNSラウンドロビンで代替できます。ただしDNSラウンドロビンにはヘルスチェックがなく、故障サーバーにも振り続け、クライアント側のDNSキャッシュで偏るのが弱点です。あくまで簡易策で、障害時の自動切り離しが要るならロードバランサーへ移行します。「速そうだから」「冗長化が流行だから」で無条件に導入するのは、見送るべき場面の典型です。要件が可用性かスケールアウトのどちらにも当てはまらないなら、1台構成のまま監視とバックアップを固めるほうが費用対効果は高くなります。

クラウド移行と合わせて負荷分散・冗長構成を設計する際の相談先

ロードバランサーの導入は、サーバー構成・アプリのステートレス化・監視・オートスケールとセットで初めて効果を発揮します。装置だけ入れても、アプリがセッションをメモリに抱えていれば台数を増やせず、ヘルスチェックの設定を誤れば障害をかえって広げかねません。自社に基盤設計の知見が薄い、あるいは既存システムのクラウド移行に合わせて冗長構成を組みたい場合は、要件定義の段階から設計と実装を一貫して支援できる開発会社に相談すると、構成のやり直しを避けられます。一創では負荷分散・冗長化を含むWebシステム開発として、トラフィック要件に応じた構成設計から運用まで対応しています。

ロードバランサー導入でよくある質問｜違い・選び方・料金の疑問

ロードバランサーをこれから設計する担当者や、構成の選定を控えた技術者から寄せられやすい質問に答えます。

ロードバランサーとリバースプロキシの違いは何ですか？

リバースプロキシはクライアントとサーバーの間に立つ代理で、キャッシュやSSL復号を担い、背後が1台でも成立します。ロードバランサーは複数サーバーへの分散が主目的です。NginxやEnvoyのようなL7製品は、リバースプロキシとして動きながら同時に負荷分散も行うため、機能が重なります。主目的が代理ならリバースプロキシ、分散ならロードバランサーと役割で区別します。

L4とL7のロードバランサーはどう使い分けますか？

IPアドレスとポートだけで高速にさばきたいならL4、URLやCookieなど中身を見て振り分け先を変えたいならL7です。SSLの復号やパスごとの経路制御が要る場合はL7になります。両者は併用でき、外側のL4で大量の接続を受け、内側のL7で経路制御する二段構成も一般的です。速度優先か、中身での制御優先かで選びます。

AWSのロードバランサーにはどんな種類がありますか？

AWSのELBには、L7のALB（Application Load Balancer）、L4のNLB（Network Load Balancer）、透過的にアプライアンスへ流すGWLBがあり、旧世代のCLBも残っています。HTTPの経路制御やパスベースの振り分けはALB、超低遅延や固定IPが要るTCP／UDP通信はNLBが目安です。2026年時点の一般的な選択で、詳細な料金や上限は公式の最新情報を確認してください。

ロードバランサー自体が故障したらどうなりますか？

ロードバランサーを1台で組むと、そこが単一障害点になり、故障時にサービス全体が止まります。実運用では2台以上でActive-StandbyまたはActive-Activeの冗長構成にし、VRRPやkeepalivedで仮想IPを引き継ぐ構成が一般的です。クラウドのマネージドLBは、内部で冗長化された構成が提供されるため、利用者側で個別に組む手間は小さくなります。

ロードバランサーの料金はどのくらいかかりますか？

費用は形態で大きく変わります。専用アプライアンスは機器費と年間保守費がかかり、ソフトウェアLBは稼働させるサーバー費用が中心です。クラウドLBは、稼働時間と処理したデータ量に応じた従量課金が一般的で、小さく始めやすい一方、通信量が増えると費用も伸びます。正確な金額は各サービスの最新の料金表で、想定トラフィックをもとに試算するのが確実です。

関連記事

• Kubernetes（クーベネティス）とは？読み方・K8sの意味から仕組みまで初心者向けに解説：ServiceやIngressによるクラスタ内の負荷分散を扱う、コンテナ環境側の解説です。
• モノリスとは？マイクロサービス・モノリシックとの違いとメリット・デメリット、モジュラモノリスまで整理：L7分散が主題になるマイクロサービス構成の考え方が分かります。