負荷分散装置（ロードバランサー）とは？ わかりやすく10分で解説

負荷分散装置（ロードバランサー）の基本

ロードバランサーは、利用者からの通信を複数のサーバーへ振り分け、性能と可用性を高めるための仕組みです。主な役割は、通信の振り分け、異常サーバーの切り離し、障害時の迂回です。

ロードバランサーとは？

ロードバランサーは、利用者からの通信（リクエスト）を複数のサーバーへ振り分け、特定のサーバーに負荷が偏らないようにする仕組み（装置・ソフトウェア・クラウドサービス）です。これにより、処理性能（スループット）と可用性を高め、アクセス集中や一部故障が起きてもサービスを継続しやすくなります。

Webサーバーは、ユーザーからのリクエストを受け取り、アプリケーション処理やデータベース参照を行い、結果を返します。アクセスが急増するとCPUやメモリ、I/Oが逼迫し、応答が遅れたり、タイムアウトが増えたりすることがあります。ロードバランサーは、このような状況でサーバーを“束ねて”運用するための基盤になります。

ロードバランサーが行う負荷分散とは？

ロードバランサーが行う負荷分散は、受け付けた通信を複数のサーバーへ振り分け、全体としての処理能力と安定性を高める考え方です。単純な「均等配分」だけでなく、サーバーの状態や応答状況に応じて振り分け先を変える、といった制御も含まれます。

代表的な機能として、次のようなものがあります。

• 振り分け（ロードバランシング）：ラウンドロビン、最少接続（Least Connections）などのアルゴリズムで配分
• ヘルスチェック：死活監視（HTTP/HTTPSやTCPなど）により、異常なサーバーを自動的に切り離す
• 障害時の迂回：一部サーバーが故障しても、正常なサーバーへ自動的に振り分ける

この仕組みにより、単一サーバーに負荷が集中することを避け、レスポンス低下や停止リスクを抑えられます。

ロードバランサーの種類と特徴

ロードバランサーは「どこで動作するか（L4/L7）」や「どのようにネットワークへ接続するか（構成）」で分類できます。ここでは構成の代表例として、Two-Arm（インライン）とOne-Arm（片腕）を紹介します。

Two-Arm（インライン）構成は、クライアント（インターネット側）とサーバー側ネットワークの間にロードバランサーを挟み、通信を通過させる構成です。仮想IP（VIP）宛ての通信を受け、バックエンドサーバーへ転送します。ネットワーク設計上の影響が大きい一方、制御の自由度が高いのが一般的です。

One-Arm（片腕）構成は、ロードバランサーをサーバー側ネットワークに接続し、同一インターフェース（同一セグメント）で受けと転送を行う構成です。戻り通信の経路を整合させるため、SNAT（送信元変換）を使う、ポリシールーティングを組む、戻りもロードバランサー経由にする、といった設計が必要になる場合があります。ネットワーク事情に合わせて採用されます。

なお、製品やサービスによっては、L4（TCP/UDP中心）・L7（HTTP/HTTPS中心）で機能が異なり、SSL/TLS終端、WAF連携、URLやヘッダ条件での振り分けなど、アプリケーション寄りの制御が可能なものもあります。

ロードバランサーの重要な役割

ロードバランサーは、性能と可用性を両立させるための重要な役割を担います。主な効果は次のとおりです。

• 処理性能の底上げ：複数サーバーを束ねて処理能力を確保しやすくする
• 可用性の向上：ヘルスチェックにより異常ノードを切り離し、サービス継続を支える
• 運用性の向上：サーバー追加・交換・メンテナンスを段階的に行いやすくする

また、特定のユーザーの通信を同じサーバーへ誘導するセッションアフィニティ（スティッキーセッション）を提供する製品もあります。ただし、これだけでアプリケーションの整合性が保証されるわけではありません。セッション管理方式（サーバー内保持／共有ストア利用など）と合わせて設計することが重要です。

負荷分散装置（ロードバランサー）の活用例

ロードバランサーは、アクセス集中への対応、障害時の継続運用、計画メンテナンス時の切り替えなどで使われます。

Webサイトの安定運営

ロードバランサーは、アクセスを複数サーバーへ分散し、ピーク時でも処理が偏りにくい状態を作ります。結果として表示速度やタイムアウトの悪化を抑え、ユーザー体験の安定につながります。

ページ表示が遅くなると離脱につながりやすいため、応答速度の維持はユーザー体験だけでなくビジネス面でも無視できません。

サーバー故障時の切り替え

サーバー故障時のリカバリーにもロードバランサーは有効です。ヘルスチェックで異常を検知し、故障したサーバーへの振り分けを止めることで、サービス全体の停止を避けやすくなります。

ただし、切り替えの速さや検知条件は設定に依存します。監視方式（HTTP/HTTPSのステータス、TCP疎通など）と閾値を適切に設計することが重要です。

サーバーのメンテナンス作業

ロードバランサーは計画メンテナンスにも役立ちます。メンテナンス対象のサーバーを一時的に切り離し（ドレイン／メンテナンスモード）、処理中の通信を整理したうえで作業できます。サービスを止めずに更新しやすい点は、運用では大きなメリットです。

セッション継続の支援

スティッキーセッションにより、同一ユーザーの通信を同一サーバーへ誘導できる場合があります。例えば、サーバー内にセッション情報を保持する構成では、セッションの継続性を保ちやすくなります。

一方で、スケールアウトや障害耐性を重視するなら、セッション情報を共有ストアへ逃がす（外部セッション管理）など、アプリ側の設計で整合性を担保する方法も検討が必要です。

DNSラウンドロビンの特徴と仕組み

DNSラウンドロビンは、負荷分散の一手段として古くから使われてきた方法です。ロードバランサーと比べてシンプルで導入しやすい反面、制御できない要素も多くあります。

DNSラウンドロビンとは？

DNSラウンドロビンは、1つのドメイン名に対して複数のIPアドレスを登録し、名前解決の応答でそれらを返すことで接続先を分散させる方式です。実装によっては応答順を入れ替えることで、複数サーバーへ負荷を分散させます。専用装置が不要で、DNS設定を工夫するだけで“分散”の形を作れます。

DNSラウンドロビンの負荷分散

DNS応答が複数IPを返せば、クライアントはそのいずれかへ接続します。結果として、アクセス先が分散する可能性があります。

ただし、DNSはキャッシュ（リゾルバやクライアント側）やTTLの影響を受けます。そのため、理論どおりに均等に配分されるとは限りません。また、CPU使用率やレスポンスタイムなど、サーバーの“現在の状態”に基づく振り分けは基本的に行えません。

DNSラウンドロビンの注意点

DNSラウンドロビンは、導入しやすい一方で次のような弱点があります。

• 障害時の追従が遅れやすい：DNSキャッシュにより、落ちたIPが一定時間参照され続けることがある
• 振り分けの制御が難しい：クライアントやリゾルバの実装差で偏りが起きることがある
• ヘルスチェックが標準ではない：“生きているIPだけ返す”には別途仕組みが必要になる

これらの性質から、可用性や制御性を重視する大規模サービスでは、ロードバランサーやGSLB（グローバル負荷分散）など、より高度な方式が選ばれることが多いです。

DNSラウンドロビンの活用例

DNSラウンドロビンは、小規模な分散や簡易的な冗長化を始める段階で使われることがあります。あるいは、クラウドやCDNの構成と組み合わせて、段階的に高度な負荷分散へ移行する設計も考えられます。

ロードバランサーとDNSラウンドロビンの比較

可用性や制御性を重視するならロードバランサー、簡易さと導入しやすさを優先するならDNSラウンドロビンが候補になります。このセクションでは、両者の違いを判断しやすい順で整理します。

両者の利点・欠点の比較

ロードバランサーは、ヘルスチェックや切り替え、振り分けアルゴリズムなどを組み合わせ、可用性と制御性を高めやすいのが特長です。一方で、導入・運用コスト（設計、設定、監視、冗長化など）が発生します。

DNSラウンドロビンは低コストで始めやすい反面、キャッシュの影響で障害時の追従が遅れたり、均等配分が保証されなかったりします。運用要件が厳しい場合は、単独での採用は慎重に判断する必要があります。

価格面の比較

ロードバランサーは、ハードウェア／ソフトウェア／クラウドサービスなど形態により費用が変わります。高機能なほどコストは上がりますが、要件によっては障害対応や運用負荷を減らせるため、結果として総コストを抑えられる場合もあります。

DNSラウンドロビンはDNS設定で実現できるため、追加コストは抑えやすい傾向です。ただし、障害時の制御を補う仕組みを別途用意するなら、その分の費用や運用も考慮が必要です。

機能面の比較

ロードバランサーは、ヘルスチェック、重み付け、条件分岐（L7）、SSL/TLS終端など、要件に合わせた制御が可能です。特に、障害検知と自動切り離しは可用性の観点で大きなポイントになります。

DNSラウンドロビンは、IPを順番に返すという静的な方式であり、状態に応じた制御は基本的にできません。設計上の前提として“偏りや追従遅延が起こり得る”ことを織り込む必要があります。

ケースによる適用の違い

大規模なトラフィックや厳密な可用性が求められる場合は、ロードバランサーが適しています。逆に、低コストで簡易的に分散したい小規模用途では、DNSラウンドロビンが選択肢になることがあります。

最終的には、求める可用性（切り替えの速さ、許容停止時間）、制御の粒度、運用体制とコストを総合して選ぶことが重要です。

ロードバランサー選定のポイント

ロードバランサー選定では、想定アクセス量、障害時の切り替え要件、運用のしやすさ、セッション設計との相性を先に固めることが重要です。ここを曖昧にしたまま製品比較に入ると、必要な機能を見誤りやすくなります。

アクセス量の見積もり

まずはアクセス量の見積もりです。ピーク時の同時接続数、リクエスト数、スループット、SSL/TLS処理の負荷などを見積もり、余裕を持った構成を検討します。

将来的な増加（キャンペーン、事業拡大）も踏まえ、スケールアウトや冗長化がしやすいかも確認が必要です。

障害対策の要件

障害検知と切り替えは重要な評価ポイントです。ヘルスチェックの方式、判定条件、切り替えの挙動（どの程度の時間で除外するか）、復帰条件などを要件に合わせて設計できるかを確認します。

メンテナンス性

メンテナンス時にトラフィックを段階的に移せるか、設定変更の影響を限定できるか、冗長構成で無停止に近い更新ができるか、といった運用性も重要です。運用手順と合わせて、実際の運用として無理なく実施できるかを確認しましょう。

セッション継続・アプリ設計との相性

スティッキーセッションが必要か、セッションを外部ストアに集約するかなど、アプリ側の設計と合わせて検討します。特にECや会員系など、ログイン状態や処理継続が重要なサービスでは、要件を明確にしたうえで選定することが重要です。

まとめ

ロードバランサーは、サーバー群を束ねて性能と可用性を高めるための仕組みで、ヘルスチェックや切り替え、柔軟な制御により運用の安定化へ貢献します。一方、DNSラウンドロビンは導入しやすい反面、キャッシュの影響や障害時の追従遅延など制約があるため、用途と要件を見極めたうえで使い分けることが大切です。

どちらを選ぶ場合でも、「求める可用性」「切り替えの速さ」「制御の粒度」「運用体制とコスト」を整理し、システム要件に合う方式を選択しましょう。