ロード・バランシング

ロード・バランシングは、プロキシー・サーバーとアプリケーション・サーバーを 透過的にクラスター化することによって、Web サイトの可用性 およびスケーラビリティーを向上させます。 バックエンド処理能力は透過的に追加することができるため、 IT インフラストラクチャーのスケーラビリティーがかなり向上されます。

複数のコンテンツ・ホストのロード・バランシング

複数のホストにコンテンツの複製を置いて大量の要求を満たすことはできますが、その場合はそれらホスト間のロード・バランシングを取る方法が必要です。ドメイン・ネーム・サービス (DNS) は基本的なラウンドロビン・ロード・バランシングを提供できますが、これがうまく実行できない場合もあります。

複数のコンテンツ・ホストのロード・バランシングを行うための、より高度なソリューションの 1 つとして、図 5 に示す Load Balancer の Dispatcher コンポーネントを使用する方法があります。 この構成では、すべてのコンテンツ・ホスト (5 の番号が付いたマシン) に同じコンテンツが保管されます。これらのホストはロード・バランシングが行われるクラスター を形成するものとして定義され、Load Balancer マシン (4) のネットワーク・インターフェースの 1 つに、そのクラスター専有のホスト名および IP アドレスが割り当てられます。 1 の番号の付いたマシンの 1 つを使用しているエンド・ユーザーがファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通ってその企業の内部ネットワークに入ります。 URL が Dispatcher のホスト名および IP アドレスにマップされているため、Dispatcher が要求をインターセプトします。 Dispatcher は、現在クラスター内のどのコンテンツ・ホストが要求に応えるために最も適しているかを判断し、要求をそのコンテンツ・ホストに転送します。MAC 転送方式が構成されている場合、このコンテンツ・ホストはファイル X を直接クライアントに返します (すなわち、ファイル X は Load Balancer を通りません)。

図 5. 複数のコンテンツ・ホストのロード・バランシング
この図は複数のコンテンツ・ホストのロード・バランシングを描いたものです
注:
Dispatcher は、以下の 3 つの転送方式を提供します。

デフォルトでは、Dispatcher は DNS などのラウンドロビン・ロード・バランシングを使用しますが、その場合でも DNS の欠点の多くが解消されます。 Dispatcher は、DNS と異なり、コンテンツ・ホストが使用不可またはアクセス不能かどうかを追跡しているため、使用不能なコンテンツ・ホストにクライアントを向けることがありません。また、Dispatcher は、新しい接続、活動状態の接続、終了した接続を追跡し、コンテンツ・ホストの現在の負荷を考慮します。 Load Balancer の advisor および manager コンポーネントを活動化すると、ロード・バランシングをさらに最適化することができます。これらのオプション・コンポーネントは、コンテンツ・ホストの状況をさらに正確に追跡して、ロード・バランシングの決定プロセスに追加情報を取り入れます。 manager を使用すると、決定プロセスで使用される各種の要因に異なる重みを割り当てて、ロード・バランシングをサイトに合わせてさらにカスタマイズすることができます。

複数のリバース・プロキシー・サーバーのロード・バランシング

Load Balancer の Dispatcher は、複数の Caching Proxy マシンのロード・バランスを取ることもできます。 企業の Web サイトの人気がある場合、単一の プロキシー によって効率的に処理できる量を超える要求がコンテンツに対して寄せられて、プロキシー のパフォーマンスを低下させる可能性があります。

複数の Caching Proxy システムで単一のコンテンツ・ホストのためのプロキシー機能を実行することができますが (図 1 に示した構成に類似)、複数の プロキシー・サーバー が必要なほどサイトへのアクセスが多い場合は、Load Balancer によるロード・バランシングが行われる複数のコンテンツ・ホストが必要になることがあります。図 6 は、この構成を示しています。 4 の番号が付いた Dispatcher は 2 つの プロキシー・サーバー (5) からなるクラスターのロード・バランスを取り、7 の番号が付いた Dispatcher は 3 つのコンテンツ・ホスト (8) からなるクラスターのロード・バランスを取ります。

図 6. 複数のリバース プロキシー・サーバー およびコンテンツ・ホストのロード・バランシング
ここに示されたグラフィックは、複数の プロキシー・サーバー およびコンテンツ・ホストのロード・バランシングを示しています。

4 の番号が付いた Dispatcher のクラスター・ホスト名は、企業の Web コンテンツの URL で使用されるホスト名です (すなわち、インターネット側から可視の Web サイトの名前です)。 7 の番号が付いた Dispatcher のクラスター・ホスト名は、インターネット側からは不可視であるため、任意の値にすることができます。 例えば、ABC Corporation という会社の場合、4 の番号が付いた Dispatcher のホスト名には www.abc.com が適切ですが、7 の番号が付いた Dispatcher には http-balancer.abc.com などの名前を付けることができます。

1 の番号の付いたクライアント・マシンの 1 つのブラウザーから、8 の番号の付いたコンテンツ・サーバーに保管されているファイル X にアクセスする必要があるとします。HTTP 要求はインターネット (2) を経由してゲートウェイ (3) から企業の内部ネットワークに入ります。ルーターは、4 の番号が付いた Dispatcher に要求を送り、この Dispatcher は、ロード・バランシング・アルゴリズムに従って、現在その要求の処理に最も適している プロキシー (5) に要求を渡します。 キャッシュ (6) にファイル X が入っている場合、プロキシー は、4 の番号が付いた Dispatcher をバイパスして、ファイルを直接ブラウザーに返します。

キャッシュにファイル X が入っていない場合、プロキシー は、ヘッダーの起点フィールドに自身のホスト名が入った新規要求を作成して、それを 7 の番号が付いた Dispatcher に送信します。 Load Balancer は、現在その要求の処理に最も適しているコンテンツ・ホスト (8) を判別して、そこに要求を送ります。コンテンツ・ホストはストレージからファイル X を取り出し、7 の番号が付いた Dispatcher をバイパスして直接 プロキシー に返します。プロキシー は、必要に応じてファイル X をキャッシュに入れ、4 の番号が付いた Dispatcher をバイパスしてブラウザーに転送します。

複数のフォワード・プロキシー・サーバーのある Load Balancer

インターネット・アクセスを多数のクライアントに提供すると、 インターネット・アクセスの要求が大量に発生し、 単一のプロキシーで効率よく要求に対処できなくなる可能性があります。 Caching Proxy が要求で過負荷になると、クライアントへの応答時間はおそらく、直接のインターネット・アクセスよりも 遅くなります。 また、Caching Proxy が、障害が起こした場合や、ネットワーク障害が原因でアクセス不能になったりした場合、 インターネット・アクセスが不可能になります。 これに対する解決策は、複数の Caching Proxy マシンをインストールし、 それらのマシンの間の負荷のバランスをとるために Load Balancer の Dispatcher を使用することです。

Dispatcher を使用しないで複数の Caching Proxy マシンで真の透過プロキシーを実現できるのは、 ご使用のルーターが、複数の Caching Proxy に同一タイプのトラフィックをルーティングすることが可能な場合に限定されます。 ただし、すべてのルーターでこれがサポートされるわけではありません。Dispatcher なしで、複数の Caching Proxy マシン上で通常のフォワード・プロキシー・サービスを提供することは可能ですが、 Caching Proxy マシンのうちの 1 台を 1 次プロキシーとして使用するように、クライアント・ブラウザーを明示的に構成する必要があります。その Caching Proxy に障害が起こった場合や、過負荷またはアクセス不能になった場合は、 エンド・ユーザーがインターネットにアクセスできなくなる可能性があります。 そのような状態が発生するのを回避するため、プロキシー自動構成 (PAC) ファイル (説明は、透過フォワード Caching Proxy (Linux システムのみ) にあります) を作成することができます。このファイルは、ブラウザーに対して 1 つ以上の 2 次キャッシング・プロキシーにフェイルオーバーするように指示します。 PAC ファイルは、Caching Proxy マシン間の負荷のバランスを取るものではありません。 ただし、1 つの Caching Proxy が別の Caching Proxy よりも非常に多くの要求を受信した場合、その ブラウザー・クライアントへの応答時間が遅くなり、パフォーマンスが低下する可能性があります。 すべてのクライアントで同様のパフォーマンスが得られるようにするには、 それぞれの Caching Proxy がほぼ同数のブラウザーによって 使用されるように構成し、また配分の追跡は手動で行うようにして、 ブラウザーを追加または除去する際に負荷が均等になるようにしなければなりません。

図 7 は、Dispatcher が Caching Proxy マシンのクラスターのロード・バランスを取るネットワーク構成を示しています。 Dispatcher マシンのネットワーク・インターフェースの 1 つが、クラスターの専有ホスト名および IP アドレスを持つように構成されています。 クライアント・ブラウザーは、それらのインターネット要求をクラスター・ホスト名に送信するように構成されます。 例えば、1 というマークの付いたクライアント・マシンのうちの 1 台にあるブラウザーが、コンテンツ・ホスト (7) 上のファイル X にアクセスする必要があるとき、ブラウザーはその要求をクラスターのホスト名またはアドレスに送信します。 そこで、Dispatcher (2) は要求をインターセプトし、要求を適切な Caching Proxy (3) に送信します。Caching Proxy は新規の要求を作成して、それを企業のゲートウェイ (5) およびインターネット (6) 経由で受け渡し、必要に応じて戻りファイルをそのキャッシュ (4) に格納します (詳しい説明は、フォワード Caching Proxy にあります)。

注:
透過プロキシー・フィーチャーは、Linux システムでのみ使用可能です。
図 7. 複数のキャッシング・プロキシーをロード・バランシングするための Dispatcher の使用。
このグラフィックは、複数のプロキシーのロード・バランシングを示しています。

Dispatcher は、Caching Proxy マシンのうち 1 台が使用不可になるとそれを検出し、自動的に要求を 他のマシンに送付します。 これにより、インターネット・アクセスを中断することなく、保守のために Caching Proxy マシンをシャットダウンすることができます。 Dispatcher には、数多くの構成オプションがあり、 これを使用することによりロード・バランシング決定の際に考慮される要因を制御することができます。 また、補助の Dispatcher プログラムを Caching Proxy マシンにインストールして、それらの状況をモニターし、 その情報を Dispatcher に戻すこともできます。 詳細については、「WebSphere® Application Server Load Balancer 管理ガイド」を参照してください。 複数の Caching Proxy を使用することにより、効率性が損なわれる可能性があります。 これは、異なるクライアントが異なる Caching Proxy マシンからファイルを要求した場合に、複数の Caching Proxy が同じファイルをキャッシュに入れることがあるためです。 このような冗長性を除去するには、リモート・キャッシュ・アクセス (RCA) を構成することができます。 これは、定義済みのグループのすべてのプロキシーが、それらのキャッシュのコンテンツを相互にシェアできるようにするものです。 RCA グループのプロキシーはすべて、同じアルゴリズムを使用して、指定した URL を どの Caching Proxy が担当するのかを判別します。 Caching Proxy は、担当ではない URL をインターセプトした場合、その担当の Caching Proxy に要求を受け渡します。 担当の Caching Proxy は、要求を満たすために必要な処理を実行します。 キャッシュから取り出すか、または、関係のあるコンテンツ・ホストに要求を転送して、戻されたファイルを適宜 キャッシュに入れるかします。 次に、担当の Caching Proxy はファイルを元の Caching Proxy に受け渡し、元の Caching Proxy はそれを要求エンド・ユーザーへ引き渡します。

RCA グループでは、特定の URL を担当する Caching Proxy が障害を起こした場合、 (クライアント要求を受け取った) 元の Caching Proxy は直接、コンテンツ・ホスト (または、定義されている場合は、バックアップ Caching Proxy サーバー) にアクセスします。このことは、 RCA グループ内の少なくとも 1 つの Caching Proxy が正しく機能しているかぎり、ユーザーがファイルにアクセスできることを意味します。

この構成は、複数の Caching Proxy マシン間での要求のロードのバランスをとるために Dispatcher を使用することで、インターネット・アクセスに対する高い要求を満たします。 潜在的な問題が 1 つあります。 それは、Dispatcher が single point of failure であることです。 ディスパッチャーに障害が起こった場合や、ネットワーク障害によりアクセス不能になった場合、ブラウザー・クライアントは、 Caching Proxy にもインターネットにも到達できません。 これに対する解決策は、図 8 に示されているように、1 次 Dispatcher のバックアップとして機能する別の Dispatcher を構成することです。

図 8. ハイ・ アベイラビリティーのインターネット・アクセスを提供するための 1 次およびバックアップ Dispatcher の使用。
このグラフィックは、複数のプロキシーのロード・バランスを取る 1 次およびバックアップの Dispatcher を示しています。

1 の番号が付いたマシンの 1 つで稼働しているブラウザーは通常、ファイル X に対する要求を、1 次 Dispatcher (2) に送ります。1 次 Dispatcher は、Dispatcher のロード・バランシング基準を基にして選択した Caching Proxy (4) にその要求を送付します。 Caching Proxy は新規の要求を作成して、それを企業のゲートウェイ (6) を使用してインターネット (7) 経由でコンテンツ・ホスト (8) に送付し、必要に応じて戻りファイル X を、そのキャッシュ (5) に格納します (プロセスのこの部分についての詳しい説明は、フォワード Caching Proxy を参照してください)。

この構成では、バックアップ Dispatcher (3) は、1 次ディスパッチャーが作動可能である限り、 ロード・バランシングを実行しません。1 次 Dispatcher とバックアップ Dispatcher は、ハートビートと呼ばれるメッセージを定期的に交換して、互いに相手の状況を追跡します。 バックアップ Dispatcher は、1 次 Dispatcher の障害を検出すると、1 次 Dispatcher のホスト名および IP アドレスに送られた要求をインターセプトして、ロード・バランシングの処理を自動的に引き継ぎます。 また、2 つの Dispatcher を相互ハイ・ アベイラビリティーのために構成することもできます。この場合、2 つの Dispatcher はそれぞれ別々のキャッシング・プロキシー・クラスターのロード・バランシング をアクティブに実行し、同時に相手のバックアップとしても働きます。詳細については、「WebSphere Application Server Load Balancer 管理ガイド」を参照してください。

Dispatcher は一般に大量の処理リソースまたはメモリー・リソースを消費しないので、Dispatcher マシンで他のアプリケーションを実行することができます。設備費を最小限に抑えることが重要な場合は、 Caching Proxy と同じマシンでバックアップ Dispatcher を実行することもできます。そのような構成を示したのが、図 9 です。この場合、バックアップ Dispatcher は、Caching Proxy と同じマシン (3) で実行されます。

図 9. Caching Proxy マシンにバックアップ Dispatcher を配置する。
このグラフィックは、複数のプロキシーのロード・バランスを取る 1 次およびバックアップの Dispatcher を示しています。