負荷分散装置（ロードバランサー）とは？ わかりやすく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アドレスを登録し、名前解決の応答で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ラウンドロビンは導入しやすい反面、キャッシュの影響や障害時の追従遅延など制約があるため、用途と要件を見極めたうえで使い分けることが大切です。

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