Web アプリケーションが遅いと顧客から苦情があったり、社内のエンドユーザーからデータベースファイルの取得に時間がかかり過ぎるとの報告がヘルプデスクに寄せられたりする場合、ロードバランサーに問題がある可能性が考えられます。 これらの苦情や報告に適切に対処できなければ、顧客やエンドユーザーはいらだちを募らせます。嫌気がさした顧客は競合他社のサイトを試そうとするかもしれず、社員は生産性が下がって不満を募らせるでしょう。どちらの場合もビジネス継続において大きな問題となり得ます。
顧客とエンドユーザーがアプリケーションを気分よくスムーズに使えることは非常に重要なので、アプリケーションの遅延を防ぐのに有用なロードバランサーの需要は高まっています。Market Research Reports のレポートによると、世界市場は今後5年間で毎年9％以上成長し、2025年には2019年よりも約36％多い19億ドルになると予想されています。
ロードバランサー市場の成長を牽引しているのは、AWS、Microsoft、Google などの主要なパブリッククラウドプロバイダです。ロードバランサーを使ってクラウド環境の負荷を分散することで、付加価値が上がります。ロードバランサーは、オンプレミスやプライベートクラウドのデータセンターでも重要な役割を果たします。これらの環境のマーケットリーダーには、F5 Networks、Citrix Systems、HPE、IBM、Imperva、NGINX、Radware が含まれます。
トラフィックを効率的に誘導
負荷分散ソリューションであるロードバランサーは、複数のコンピューティングリソースのワークロードを最適な配分になるよう振り分けて分散させます。リソースには、複数のインスタンスを持つ仮想化サーバー、サーバークラスター、ネットワークインフラストラクチャデバイス、ストレージなどが含まれます。負荷分散によって、リソースの使用率とスループットを最大化すると同時に、応答時間を短縮し、単一のリソースが過負荷になるのを防ぐことができます。
ロードバランサーを日常生活の中のシーンになぞらえて例えると、都市の中心部に向かう複数の道路が交差する、交通量の多い交差点で交通整理をする交通巡査のような役目を果たします。交通巡査、トラフィック・コップ、は、各車が交差点に近づくと、（同じように都心に向かう道路のうち）交通量が最も少ない道路に進むよう指示を出します。ある道路の交通量が多くなり過ぎると、一時的にその道路への侵入を遮断することもあります。
ロードバランサーも、交通巡査と同じように、トラフィックを調整します。顧客やエンドユーザーがアプリケーションやデータベースにアクセスしようとすると、物理クラスター内のどのサーバーまたは仮想サーバー内のどのインスタンスのトラフィックが現在最も少ないかを確認して、アクセス要求を最適なリソースに送信します。また、交通渋滞が起きた道路への遮断と同様に、サーバーやネットワークデバイスリソースに問題が発生してトラフィックが滞ってしまった場合、ロードバランサーはそのリソースへのアクセスをシャットダウンできます。
ロードバランサーのアルゴリズム
ロードバランサーは、様々なアルゴリズムを使用して、サーバークラスターまたは複数の仮想サーバーインスタンスの間でリクエストを分散する方法を決定します。それぞれの環境に適した手法は、ワークロードなどによって異なってきます。
| 手法 | アルゴリズム |
最小帯域幅 | その時点で最も少ないトラフィックを処理しているリソースを選択 |
最小パケット | 指定された期間に受信したパケットが最も少ないリソースを選択 |
ラウンドロビン | トラフィックを均等にローテーションして、それぞれのリソースを1回に１つずつ選択 |
最小の接続 | アクティブな接続の数が最も少ないリソースを選択 |
最小応答時間 | リソースの応答時間をテストし、応答時間が最も速い（使用率が最も低い）リソースを選択 |
ハッシュ | ヘッダー、IP アドレス、ポート番号、ドメイン名などの着信パケットのハッシュデータに基づいてリソースを決定 |
カスタムロード | CPU 使用率、メモリ、応答時間など、システム管理者が定義した属性に基づいてリソースの負荷をテストし、結果を組み合わせて全体的なリソースの負荷を決定 |
上記リストの最初の4つの手法は、インストールと保守は簡単ですが、提供できるサービス・レベルは限定的です。後半の３つの手法（最小応答時間、ハッシュ、カスタムロード）は、より複雑で IT管理者の関与も必要になりますが、顧客とエンドユーザーにとってのアプリケーションの応答時間がはるかに速くなる可能性があります。
ハードウェア・ロードバランサーとソフトウェア・ロードバランサー
ロードバランサー・アプライアンスを購入することも、ネットワークインフラストラクチャの既存のデバイスにソフトウェア・ロードバランサーをインストールすることもできます。どちらの場合も、ギガビットのアプリケーショントラフィックを安全に処理できます。
複数のロードバランサー・インスタンスを単一のデバイスに統合できる仮想化機能が含まれているアプライアンスもあります。そのようなアプライアンスを使えば、柔軟なマルチテナント・アーキテクチャが実現できます。
ソフトウェア・ロードバランサーは、ハードウェアのアプライアンスと同じパフォーマンスを提供でき、一般的なハイパーバイザ上、アプリケーションコンテナ内、またはベアメタルサーバー上の Linux プロセスとして実行できます。特殊な使用ケースや技術要件に合わせた高度な設定も可能です。
OSI レイヤにおける位置づけ
ロードバランサーは、オープンシステム相互接続（Open Systems Interconnection、OSI）モデルの7つのレイヤにおいて、トランスポート層（L4）かアプリケーション層（L7）のどちらかで機能します。L4 バランサーは、パケットに使用される TCP ポートと UDP ポート、およびパケットの送信元と宛先の IP アドレスに基づいてルーティングを決定します。ネットワークアドレス変換を実行しますが、各パケットの内容を検査することはありません。
L7 バランサーは、もう少し詳細まで介入します。リソース間でトラフィックを分散するときに、HTTP ヘッダーや SSL セッション ID などの幅広いデータをチェックします。したがって、負荷分散のための計算量は多くなりますが、トラフィックを深く分析して処理するので、より効率的な負荷分散が可能です。
地球規模でバランスの取れたアプリケーションパフォーマンス
アプリケーションに最適な負荷分散ソリューションがどのようなものであるかを判断するには、ロードバランサーに関係する以上のような要因を理解した上で考察することが大切です。地理的に広い領域に散在する Web アプリケーションをプロビジョニングする場合は、グローバルサーバーの負荷分散についても考慮する必要があります。グローバルサーバーの負荷分散が可能なロードバランサーを利用すれば、アプリケーションの負荷分散を複数のデータセンターに拡張でき、大量のトラフィックを効率的に分散することが可能になります。
適切なロードバランサーを利用することで、顧客とエンドユーザーに重大な遅延が発生しないようにすることができます。そうすることで、ユーザーエクスペリエンスが向上し、アプリケーションの遅延が原因の苦情やヘルプデスクへの問い合わせを大幅に削減することができます。