ロードバランサーとは？ 定義、種類、ネットワーキング

ロードバランサーの定義

現実世界に道路交通の誘導を行う警官がいるように、デジタル世界にはロードバランサーが存在します。戦略的に配置されると着信トラフィックを適切に振り分け、特定のサーバーだけに負荷が偏らないようにします。

着信トラフィックを監視し、最も余裕のあるサーバーへ振り分けます。もし応答がない場合は、次に利用可能なサーバーが要求を処理します。

企業環境では着信トラフィックの処理に複数のサーバーを用いますが、トラフィックの誘導が不十分だと、最初に到達したサーバーやアクセスしやすいサーバーへ流れることがあります。例えば、大半のサーバーがファイアウォールに守られている中、一台だけファイアウォールがない場合、容易にアクセスできるそのサーバーへ自動的にトラフィックが向かいます。

このため、一台のサーバーに全負荷が集中し、性能低下や応答の遅れを招く恐れがあります。ここでアプリのロードバランサーを導入することで、この問題を解消できます。

特定のサーバーへの負荷集中を防ぎ、リクエストと応答の速度向上を図ります。配置的には、ロードバランサーはアプリのバックエンドサーバーの入口に設置され、オリジンサーバーに先んじてクライアントの要求を受け付けます。

これはソフトウェア型またはハードウェア型のツールがあり、ソフトウェア型の場合は事前に設定されているため、インストールやセットアップの手間がなく、シンプルなログインで利用できます。

一方、ハードウェア型ロードバランサーは専用のセットアップと設置が必要で、必ずしも好まれるわけではありません。いずれの場合も目的は同じです.

reverse proxy とロードバランサーの概念を明確にすることは重要です。reverse proxy はクライアントの要求をサーバーへ中継しますが、アプリ型ロードバランサーのようにサーバー群へ要求を分散しません。

API gateway とロードバランサーにも注目する価値があります。API gateway は、APIがサーバーと連携し応答を伝達するために用いる仕組みで、ロードバランシングとは少し異なります.

動作の仕組み

シンプルな流れで動作します。ロードバランサーは複数のアルゴリズムを用い、サーバーの空き状況を確認後、要求を余裕のあるサーバーへ振り分けます。同様の処理がすべての要求に対して行われます.

‍

ロードバランシングアルゴリズム

• Static 

この方式はサーバーの状態を考慮せず、どのサーバーが過負荷なのか、または空いているのかを判断しません。そのため、誤ったサーバーへトラフィックが流れる可能性があります.

設定は容易ですが、性能に不具合が生じやすく、稼働していないサーバーに要求を送る場合もあります。代表例は次の2つです:

• RR (ラウンドロビン) は、あらかじめ決めた順番でサーバー群に要求を送ります.
• クライアント側の任意またはランダムなロードバランサーは、任意の2台のサーバーを選び、接続数の少ないサーバーに要求の詳細を渡します.

• Dynamic 

より進化したアルゴリズムで、サーバーの健康状態、現在の負荷、保留中の要求数、平均応答時間などの情報を事前に取得し、それを基にトラフィックの振り分けを行います.

このアルゴリズムはさらに次のように分類されます:

1. リソースベース: 各サーバーの混み具合を確認し、常に最も空いているサーバーに新たな要求を送ります.
2. ‍ジオロケーションベース (GSLB): 各地域のサーバーに均等にトラフィックが分散されるよう管理し、局所的なサーバーの過負荷を回避するとともに、遠隔のサーバーも有効に利用されるようにします.

やや複雑なアルゴリズムであるため、設定には高度な知識が必要ですが、精度の高い最適なトラフィック振り分けが実現されます.

‍

利用される場所

ロードバランシングは、インターネットトラフィックの効果的な処理とサーバーの有効活用が求められるすべての場面で利用されます。ウェブアプリ、ウェブサイト、企業向けアプリなどが代表的な例です.

クラウド型やソフトウェア型のロードバランサーを用いることで、均等なトラフィック分散を容易に実現できます.

ローカルネットワークにおいても、トラフィックを途切れることなく分散させるためにこの手法が用いられます。ただし、複雑なネットワークインフラのため、最適な要求処理にはADCや専用のロードバランシング機器などの追加リソースが必要となる場合があります.

ハードウェア型とソフトウェア型のロードバランサー

ロードバランシングには、ソフトウェア型とハードウェア型のソリューションがあり、それぞれ独自の動作原理と機能を有しています.

例えば、ハードウェア型は面倒なセットアップと設定が必要な一方、ソフトウェア型はプラグアンドプレイで、設定の手間がほぼありません.

ソフトウェア型ロードバランサーはコンパクトで、あらゆる面で柔軟な設定が可能です。対してハードウェア型は複雑で多機能なツールとなり、一度に膨大なトラフィックを処理できます.

ハードウェア型では高度な仮想化機能が利用でき、ソフトウェア型もそれに類する機能を提供します.

管理者はハードウェア型で運用や機能の管理がより容易になり、使用方法や管理者の役割範囲、複数のアーキテクチャを定義できますが、ソフトウェア型はカスタマイズ性に制限があります.

ハードウェア型のセットアップや保守には高いコストがかかるため、高い負担に耐えられる大企業向けの選択肢となります.

ソフトウェア型ロードバランサーは非常に手頃な料金体系が用意され、必要な分だけ支払う形となるため、エンドユーザーがセットアップや設置に関与しなくてもコストが重くならない点も魅力です.

‍

ロードバランシングの利点

毎日大量のトラフィックを扱う組織は、効果的なトラフィック振り分けを実現するためにこの手法を採用する必要があります。多数の問い合わせ対応やリソース最適化など、さまざまなメリットがあります。代表的な利点は以下の通りです.

• 高い柔軟性 

既存のサーバーグループに対してサーバーの追加や削除が可能で、アーキテクチャ全体への影響を最小限に抑えながら柔軟な運用が実現されます。保守中でもトラフィック振り分けは継続されます.

• 途切れのない拡張性 

トラフィックが増加しても、必要に応じて仮想または物理サーバーを追加できるため、十分な処理能力を確保できます。追加されたサーバーは自動で認識され、ロードバランサーに取り込まれ、ダウンタイムはほぼ発生しません.

• 堅牢な冗長性 

ロードバランシングにより運用上の障害が起こる確率が低減されます。万が一サーバー障害が発生した際も、ロードバランサーが次の稼働中のサーバーに要求を振り分けるため、応答の遅延を防ぐことができます.

‍

サーバーグループの動的構成

性能を維持するためには、常にサーバーの入れ替えが必要となります。稼働中のサーバーを停止し、新たなサーバーを追加する必要があり、これはAWSのユーザーが頻繁に経験する現象です.

AWSのクラウドコンピューティングツールであるEC2は従量課金制ですが、サーバーのスケーラビリティは確保されています。Elastic ロードバランサー（AWSコンポーネント） もこの方式を採用しています.

トラフィック急増時には自動でスケールアップが行われ、ロードバランサー の導入によりサーバーの追加や削除がスムーズに行われ、現行の処理や性能に影響を及ぼしません.

セッション維持（スティッキーセッション）

ロードバランシングをより深く理解すると、スティッキーセッション、すなわちセッション維持という概念に出会います。アプリのロードバランシングの一環として、サーバー間の連携を強化します.

通常、ユーザーのセッションデータはブラウザにローカル保存され、再利用や再処理が行われるまで保持されます。例えば、ECサイト利用者がカートに商品を残し、その後処理しない場合、データはローカルに保存されます。しかし、その間にサーバーの処理内容が変更されると、取引が行われないなどの重大な不具合につながる恐れがあります.

セッション維持を利用することで、セッション中のサーバーが変更されることを防ぎ、こうした問題を容易に回避できます.

効果的なロードバランサーは必要に応じてセッション維持を活用します。これにより、アプリのサーバー間親和性が高まるだけでなく、アップストリームのサーバーがキャッシュ処理時に高い性能を維持でき、途中でサーバーが切り替わることも防ぎます.