- ロードバランサーとは、複数のサーバーへアクセスを振り分け、負荷を均等にならす負荷分散装置のことだ。
- 1台のサーバーに客が殺到すると処理が詰まって落ちる。そこで入口で交通整理をする係を置き、空いているサーバーへ客を流してやる仕組みだと思えばいい。
- 導入すると、1台が故障しても残りで処理を続けられ、アクセスが増えてもサーバーを足すだけでさばける。落ちないサービスの土台になると覚えておけばいい。
この4コマは、アクセスが集中するWebサービスの現場で実際に起こりうる負荷集中の縮図です。コマ①の店員が1人で列をさばけない状態は、1台のサーバーに全リクエストが集まってCPUやメモリを使い切り、応答が返らなくなる瞬間そのものを表しています。人気が出るほど、皮肉にもサービスが自滅しやすくなるわけです。
コマ②で登場する案内係が、まさにロードバランサーの役割を担います。ここで見落としてはいけないのが、案内係はただ順番に客を割り振るだけではないという点でしょう。応答できない窓口を素早く見つけて列から外すヘルスチェックがあるからこそ、コマ③のように待ち時間ゼロが実現します。1台が落ちても客はそれに気づきません。
ただしコマ④の指摘は経営視点でも重い意味を持ちます。案内係が1人しかいなければ、その案内係が倒れた瞬間に店全体が止まるからです。ロードバランサー自体が単一障害点になりうるため、実務では装置そのものも二重化して備えるのが定石になります。守りの要ほど、二重に守る発想が欠かせません。
なぜロードバランサーがWebサービスに欠かせないのか？
ロードバランサーがない場合、Webサービスへのアクセスは1台のサーバーに集中します。人気が出て同時アクセスが数千件に達すると、そのサーバーは処理を抱えきれずに応答が遅れ、やがて画面が真っ白になります。売上の機会も、積み上げた信頼も、一度のダウンで失われてしまうのです。
ロードバランサーを入口に置くと、この構図が一変します。届いたアクセスは空いているサーバーへ順に流され、負荷が一箇所に偏りません。AWSは負荷分散の導入事例として、Code.orgがApplication Load Balancerを使い、オンラインコーディングイベント中に400%も急増したトラフィックを効率的に処理したと紹介しています。増えた分だけサーバーを足せば対応できる、これがスケールアウトという考え方です。
振り分け方には、IPアドレスとポート番号で機械的に割り振るL4方式と、URLやCookieなど通信内容を読んで振り分けるL7方式があります。L4/L7はネットワークの階層モデルの第4層・第7層に由来する呼び名です。加えて、順番に配るラウンドロビン、接続数が最も少ないサーバーを選ぶ最小接続数など、状況に応じたアルゴリズムを選べる柔軟さも持ち合わせています。
ロードバランサーのよくある誤解
高価な専用機器を買わないと使えない
かつては数百万円する専用アプライアンスが主流でしたが、今は事情が違います。AWSのELBやAzureのロードバランサーといったクラウドのマネージド型なら、使った分だけの従量課金で始められます。ソフトウェア型を無料で構築する選択肢もあり、個人開発でも手が届く技術になりました。
導入すればサービスは絶対に落ちなくなる
負荷分散を入れれば安心、と考えるのは危険です。振り分け役であるロードバランサー自体が1台だけなら、それが壊れた瞬間に全てのアクセスが行き場を失います。この単一障害点を避けるため、実務ではロードバランサー自体も2台以上で冗長化するのが基本になります。守りの要こそ二重に備える、という発想が欠かせません。
アクセスをただ均等に分けているだけ
均等分配だけが仕事だと思われがちですが、それは一面にすぎません。定期的に各サーバーの生死を確認するヘルスチェック、同じ利用者を同じ先へ導くセッション維持、暗号化通信を肩代わりするSSL終端など、可用性を支える役割を幅広く担っています。単なる分配機ではなく、サービスの司令塔に近い存在だと捉えると理解が深まります。
会話での使われ方
キャンペーン当日のアクセス集中に備えて、Webサーバーを3台に増やしてロードバランサーの後ろに並べる構成を提案します。1台落ちても残りでさばけるので、去年みたいなダウンは避けられます。
社内のインフラ設計会議で、インフラ担当者が上長に対して次回セール向けのサーバー構成を提案している場面。前年のダウン障害を踏まえた報告と提案のトーンです。
この料金プランですと、ロードバランサーはマネージド型を採用します。お客様が機器を保守する必要はなく、トラフィックが増えた分だけ自動で処理能力が広がる仕組みです。
システム開発の商談で、ベンダーの営業がクライアント企業の担当者へインフラ構成を説明している場面。専門用語をかみ砕いて安心感を与える提案のトーンです。
ロードバランサーってリバースプロキシと何が違うんですか？設定画面に両方出てきて混乱してます。
チームのSlackで、新人エンジニアが先輩に用語の違いを尋ねている場面。設定作業でつまずいた素朴な質問のトーンです。
ロードバランサーとリバースプロキシの違い
ロードバランサーとリバースプロキシは、どちらもサーバーの手前に立ってアクセスを受ける点が似ているため混同されがちです。主眼を置く目的が異なる点を表で整理します。
| 比較観点 | ロードバランサー | リバースプロキシ |
|---|---|---|
| 主な目的 | 複数サーバーへの負荷分散と可用性の確保 | クライアントとサーバーの仲介・代理応答 |
| 仕組み | 届いたアクセスを複数の後段サーバーへ振り分ける | 窓口として受け、背後のサーバーへ中継する |
| 得意な場面 | アクセス集中・障害への耐性を高めたいとき | キャッシュ・SSL終端・セキュリティを担わせたいとき |
実際には多くのリバースプロキシ製品が負荷分散機能を備えており、両者の役割は重なります。分散を主目的にするか、仲介や代理応答を主目的にするか、という力点の違いで捉えると整理しやすくなります。
【まとめ】ロードバランサーの3つのポイント
- アクセスをさばく案内係：複数のサーバーへ交通整理し、負荷が一箇所に偏るのを防ぐ装置です。
- 止まらないサービスを作れる：1台が故障しても残りで処理を継続し、サーバーを足すだけでアクセス増にも応えられます。
- 装置自体の冗長化を忘れない：ロードバランサーが単一障害点にならないよう、2台以上で備える設計が実務の前提になります。
よくある質問
-
Qロードバランサーは何のために使うのですか？
-
A
アクセスを複数のサーバーに分散させ、サービスを落とさず快適に保つために使います。AWSは負荷分散の目的として、可用性の向上・スケーラビリティ・セキュリティ・パフォーマンスの4つを挙げています。1台に集中させないことが、安定運用の第一歩になります。
-
Qロードバランサーにはどんな種類がありますか？
-
A
大きく分けると、振り分けの仕組みでL4型とL7型の2つがあります。L4はIPアドレスとポート番号で機械的に割り振り、L7はURLやCookieなど通信内容を読んで振り分けます。提供形態でも、専用機器のハードウェア型、無料で組めるソフトウェア型、クラウドのマネージド型に分かれます。
-
Qロードバランサー自体が壊れたらどうなりますか？
-
A
1台構成だと、そこがボトルネックになりサービス全体が止まります。この単一障害点を避けるため、実務ではロードバランサーを2台以上並べて冗長化するのが一般的です。片方が故障しても、もう片方が処理を引き継ぐ設計にしておけば安心です。
-
Qロードバランサーとリバースプロキシとの違いは何ですか？
-
A
力点の置き方が違います。ロードバランサーは複数サーバーへの負荷分散と可用性の確保が主目的で、リバースプロキシはクライアントとサーバーの仲介や代理応答が主目的です。ただし多くのリバースプロキシは負荷分散機能も持つため、実際には役割が重なり合う場面が多くあります。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| C10K問題 | サーバーが大量の同時接続で処理しきれなくなる問題。負荷分散が有力な打ち手になる |
| バーストトラフィック | 突発的なアクセス集中。ロードバランサーで複数サーバーに分散させて耐える |
| AWS | ELBというマネージド型ロードバランサーを提供する代表的なクラウド |
| スループット | 負荷分散の導入効果を測る指標。単位時間あたりに処理できる量を示す |
| フェールセーフ | 障害時も安全側に倒す設計思想。LBのヘルスチェックや冗長化と発想が通じる |
【出典】参考URL
https://aws.amazon.com/jp/what-is/load-balancing/ ：ロードバランシングの定義、4つの目的（可用性・スケーラビリティ・セキュリティ・パフォーマンス）、アルゴリズム、Code.orgのトラフィック400%急増時の処理事例の根拠
https://www.kagoya.jp/howto/it-glossary/network/loadvalancer/ ：ロードバランサーの定義、負荷分散の仕組み、L4/L7の振り分け方式、配置方式の根拠
コメント
ロードバランサーを実際に使う場面は想像できたでしょうか。「自分の仕事だとこういう場面かも」という気づきがあれば、コメントで共有してもらえるとうれしいです。