注意： 本製品は既に生産⁄販売を終了しております。

インターネット Web サーバのスケーリング

• Cisco LocalDirector の製品情報ページ

1997 年のインターネットの成長は脅威的なものになりました 1996 年の中頃では、ほとんどの企業の Web サイトは懐疑的に始められた実験的なものでした。しかし、1997 年の中頃までには、これらの同一の Web サイトが、カスタマやその他のパートナにサービスを提供するためにミッション・クリティカルなアプリケーションになりました。各企業では、固有な目的で Web テクノロジーの実装を始めています。たとえば、金融サービス関連の大手企業は、Es-Trade のような電子商取引のパイオニアに脅威を感じています。Bell 社では、Microsoft の Sidewalk が先鞭を付けたことに対抗し、オンラインの「Yellow Pages」を実現中です。CNN on line では、ニュース情報のリアルタイムでの配信には Web テクノロジーが最適であることを実感しました。

「かろうじて足りる」程度の Web サイトのパフォーマンスが突如として「重大なボトルネック」となり、企業にカスタマや財産を失わせる原因となりました。新たに大量に殺到するカスタマや Web ブラウザを、便利でクリエイティブな大量のコンテンツにすばやくアクセスさせる必要があります。新しいコンテンツは動的で画像の多いものになってきたため、パフォーマンスの問題がさらに増大しています。帯域幅に対する需要の増加とサーバ・パフォーマンスに対する要求の増加が組み合わさり、Web サイトのパフォーマンス、構築、スケーリング、管理が重要な関心事および焦点になってきました。

現在では 2 千万以上の Web サイトが存在し、情報の総量は気が遠くなるほどの量です。しかし、企業にとってより重要な事項は、競争相手も同じか、または重複した情報およびアプリケーションを所有していることです。カスタマのほとんどは、ダウンロードが遅い Web サイトには多くの時間を割こうとしません。経験的に見ても、Web サイトの閲覧者はすぐに「中止」をクリックしてダウンロードを止めてしまいます。そのようなテクノロジーは、閲覧しているユーザをサーチ・エンジンの出力に「戻し」、競争相手のサイトへのリンクをクリックするよう奨励しているようなものです。また、新しいテクノロジーにより、その Web サイトあるいはインターネットではダウンロードが遅いかどうかを、カスタマがブラウザを通じて判断できます。

この文書では、Web サーバ・システムのパフォーマンスを検証するモデルについて説明します。次に、このモデルを使用して、シングル・サーバ・モデル、DNS（Domain Name System）のラウンドロビン方式によるサーバ・ファーム、および Cisco LocalDirector などのロード・バランシング・ソリューションのような代案となる Web サイトを検討します。そして最後に、LocalDirector のサーバ管理技術について考察します。

Web サイトのパフォーマンス評価には、要求される結果の定義と適切な方法の選択が含まれます。Web サーバのパフォーマンスには、サーバの入出力（I/O）、ディスク・スピード、WAN 帯域幅、アプリケーションのスピードなど、限りない数の要素が影響します。これを分析するには、パフォーマンスに関する一般的な広い範囲のカテゴリを定義します。このようなレベルの分析には、一般的な問題に対応できるという強みがある点において、キューイング・セオリが最も適切な方法になります。

キューイング・セオリを使用した調査は、Web サーバのパフォーマンスに影響を与える重要な要素を判別するために行われます。サーバの応答時間や、この応答時間に影響を及ぼすさまざまな要素を分析し、サーバのパフォーマンスを判別します。サーバ接続が追加されるにつれて応答時間が徐々に長くなる結果が示され、ある時点で応答時間が無限大に近づく漸近線が形成されます。この漸近線は、このサーバ・システムの最大キャパシティを表しています。図 1 は、典型的な応答時間曲線と最大キャパシティを示しています。

図 1：標準応答時間

開発されたさまざまなモデルにより、次の 3 つの一般的な変数がサーバの応答時間曲線の変動に大きな影響を与えることが示されています。つまり、これらの変数が変更された場合、サーバ・システムのパフォーマンスとサーバの最大キャパシティに劇的な変化が現れることになります。

• ネットワークの帯域幅
• サーバのパフォーマンス
• 平均ファイル・サイズ

ネットワークの帯域幅またはサーバのパフォーマンス（メモリ、CPU、I/O など）を増加させると、応答曲線は右側にシフトし、パフォーマンスのプロファイルが向上します。サーバの最大キャパシティも向上します。サーバがボトルネックになっている場合、ネットワーク帯域幅を増加させてもシステムのパフォーマンスに与える影響はわずかです。ネットワーク帯域幅がボトルネックになっている場合、サーバのパフォーマンスを増加させてもシステムのパフォーマンスに与える影響はわずかです。図 2 では、サーバがボトルネックで、帯域幅が十分なときに、サーバのパフォーマンスを向上させた場合の影響を示しています。

図 2：セッション分配アルゴリズムによるパフォーマンスの向上

ファイル・サイズが Web サーバのパフォーマンスに与える影響は、余り直感的ではありません。多数の大きなファイルを扱う Web サーバは使用可能な帯域幅とサーバの処理能力をより多く必要とするため、大きなファイルによってシステムのパフォーマンスは低下し、応答時間は長くなります。調査では、ファイル・サイズが小さいときには、ファイル・サイズのわずかな変化でもサーバのパフォーマンスに大きな影響を与えますが、ファイルサイズがすでに大きい場合、ファイル・サイズの変化によりサーバのパフォーマンスはそれほど大きな影響を受けないことが分かっています。

モデリングの取り組みが継続されるにつれて、より高度なモデリング方式が実装されるようになり、サーバのパフォーマンスに大きな影響を与えるために、対話型で非常に動的なコンテンツが期待されます。経験的な実証では、Web サイトの管理者がフォーム、サーチ・エンジン、対話的なアプリケーションなどを追加すると、サーバ・システムのパフォーマンスは急激に著しく低下することが示唆されています。サーバの応答曲線は左側にシフトします。株式取引、フォーム、サーチ・エンジン、データベース検索などのアプリケーションを使用している Cisco LocalDirector のカスタマからは、サーバが提供できる接続の数が著しく、おそらくは指数関数的に低下することが報告されています。

通常、企業では、Web サイトにミッドレンジのサーバを使用し、そして帯域幅はおそらく T1 回線を使用してサービスを開始しています。その後、帯域幅を追加し、サーバがボトルネックになります。この時点では、より性能の高いサーバが実装されます。企業にとって、ボトルネックの解消のために 1 年に 3～4 回もサーバをアップグレードすることは珍しいことではありません。しかし、単一のより高性能のサーバへのアップグレードを続けることは、よいスケーリング・ソリューションとは言えません。

シングル・サーバの環境では、他の問題もいくつか発生します。シングル・サーバでは、シングル・ポイント障害が発生します。シングル・サーバ・ソリューションでは、サーバの管理およびアップグレードを計画したり実現することが困難です。ハイエンドなコンピュータ性能の領域では、コンピュータの性能を増加させる費用は手が出ないほどに高価なものになります。また、好ましくないアーキテクチャのために、ハイエンド・コンピュータ・システムの高機能をアプリケーションが活用できないことも頻繁に生じます。

コンピュータのアップグレードを何度か行った後、企業はおそらく分散型サーバ・アーキテクチャへ移行することになります。つまり、HTTP（Hypertext Transfer Protocol）要求をサーバのファームへ分散させるように Web サイトが設計されます。各サーバのコンテンツはミラーされます。多くの場合、ロード・バランシングは「DNS ラウンドロビン」という方式によって実行されます。

DNS ラウンドロビンは、サーバの集合へ負荷をリニアに分散させるバインドの実装です。たとえば、A、B、および C の 3 つのサーバの例を考えます。サーバ A によって最初の要求が取得され、B では 2 番目の、そして C では 3 番目の要求が取得されます。リニア・ローテーションが再度繰り返されます。図 3 では、DNS のラウンドロビン・アーキテクチャを示しています。

図 3：DNS ラウンドロビン

最初の印象として、この方式は分散サーバ・システムとして優れたアーキテクチャに見えます。しかし、さらに検証を行うと、DNS ラウンドロビンには、サーバの管理に関する一連の特有の問題があることが分かります。この方式ではすべてのサーバを平等に扱い、負荷やアベイラビリティを判断しません。クライアントの接続時間の変化や、ダウンロードされているコンテンツの量により、負荷は動的に変動します。通常のインターネットのコンテンツとトラフィックがある 4 台のサーバによる環境では、1 台のサーバにトラフィックの 75 パーセントが集中することがあり、この時点でサーバが動作しなくなります。このシナリオでは、DNS ラウンドロビン方式のもうひとつの弱点が示されています。サーバが故障した場合でも、このサーバは引き続き要求を受け取ろうとするため、クライアント側では「server not available」というメッセージを受信することになります。サーバの管理では、別の問題が発生します。OS やアプリケーションのアップグレードなどでサーバ管理者がメンテナンスのためにサーバをオフラインにする必要がある場合、このサーバの IP アドレスが DNS で変更され、インターネット全体に浸透するまでには 2 日間を要する場合があります。その間、カスタマは存在しないサーバからの情報を要求することになります。

シスコ・システムズの LocalDirector は、信頼性の高いリアルタイムな組み込み型オペレーティング・システムを備えた統合ソリューションであり、TCP/IP のトラフィックを複数のサーバ間に高度にロード・バランスさせます。LocalDirector では、あらゆる TCP アプリケーションをサポートしていますが、この文書では、Web サーバのスケーリングに重点を置いています。

LocalDirector は、要求を行うクライアントに対し、「仮想」サーバとして動作します。すべてのトラフィックは、DNS を経由して仮想 IP アドレス（仮想サーバ）に誘導されます。次に、これらの要求はサーバ上にある実際の一連の IP アドレス（実サーバ）に分散されます。仮想 IP アドレスの定義は DNS 内のアドレスであり、ほとんどの場合はドメイン名に対応します。実 IP アドレスは、LocalDirector の背後にある実サーバに物理的に配置されています。図 4 はこの設定を表しています。

図 4：LocalDirector によって最大化されたサーバ・ファームのキャパシティ

LocalDirector の方式では、サイト管理者は Web サイトのキャパシティを徐々に向上させることができ、さらにサーバを簡単に追加、削除および再配置して、トラフィックの急増に対応できます。図 5 に示すサーバの応答曲線は、LocalDirector によりサーバ・ファームのキャパシティが最大化される様子を表しています。左側にある最初の 2 台のサーバの応答曲線は、個々のサーバを示しています（サーバ A とサーバ B が個別に要求を処理した場合）。最も右側にある曲線は、サーバ A とサーバ B が LocalDirector の背後にある場合のキャパシティを表しています。DNS ラウンドロビン方式では、サーバの応答曲線は右側に張り出しますが、右側に張り出す量とキャパシティの総量は不安定になることがあります。つまり、DNS ラウンドロビン方式での負荷の分散には一貫性がなく、そのため応答曲線は左右に変化します。一方 LocalDirector では、負荷は適切に分散され、応答曲線は一貫性を持って最適化されます。

図 5：パフォーマンスの向上

分散環境において、Web サイトのパフォーマンスの重要な構成要素はサーバの管理です。

当然のようですが、メンテナンス目的でサーバをサービスからはずすための簡単で効率的な方法を提供している市販製品は、今までありませんでした。LocalDirector では、これを簡単に行うことができます。LocalDirector では、1 つのコマンドによりサーバをサービスからはずすことができます。新しい接続はサービス外になったサーバには送られません。また、他の接続を終了させることができます。接続がすべてなくなった時点で、サーバでのメンテナンスを開始できます。

LocalDirector は、アプリケーションに依存しないハードウェアとオペレーティング・システムです。さらに、LocalDirector では、各サーバへのソフトウェア・モジュールの読み込みを必要としません。したがって、サーバ管理者は、LocalDirector の背後に UNIX、NT、および Macintosh を配置して、1 台の仮想サーバとして見せることができます。この設定により、サーバ・システムの管理性が大きく向上します。

LocalDirector では、サーバのアベイラビリティに基づいて、サーバを透過的および自動的にサービス対象の内外に配置します。サーバにハードウェアの障害が発生した場合、そのサーバは自動的にサービスからはずされます。HTTP またはアプリケーション・デーモンに障害が発生した場合、LocalDirector により、そのサーバはサービスからはずされます。ネットワーク・トラフィックが追加されることはなく、モニタ機能も透過的です。

また、効率的なサーバ管理には、IP アドレスの制御も必要です。LocalDirector では、最大 8000 個の仮想 IP アドレスと実 IP アドレス、および仮想ポート・アドレスと実ポート・アドレスがサポートされています。大規模な例として、ある Web ホスティング企業では、200 個の仮想 IP アドレスとドメイン名を所有し、これら 200 個の 仮想 IP アドレスの背後に、800 個の IP アドレスを持つ「実サーバ」を所有しています。また、LocalDirector では、実サーバに対する未登録の IP アドレスも設定できます。

LocalDirector では、ポートを含むために仮想 IP アドレスと実 IP アドレスの概念が拡張されます。ポートにより TCP アプリケーションが識別され、さらにポートをアプリケーションのエントリ・ポイントと見なすことができます。通常、ポート 80 は Web アプリケーションの入り口になります。図 6 では、仮想ポートと実ポートの概念を示しています。

図 6：仮想ポートと実ポート

この例では、IP アドレス 204.31.33.1 のポート 80 に向けられたトラフィックが、実 IP アドレス 192.168.1.1 のポート 80 および 192.168.1.1 のポート 8001 にロード・バランスされています。IP アドレス 204.31.33.1 のポート 20 へのトラフィックは、実 IP アドレス 192.168.1.1 のポート 20 へ誘導されます。ポート 80 またはポート 20 へ向けられなかったトラフィックは拒否されます。

仮想ポートと実ポートの概念により、LocalDirector では次のことが実行されます。

• アプリケーション特有のサーバ・ファームの設定 - 1 つの仮想 IP アドレスと複数の仮想ポートを使用することで、FTP（File Transfer Protocol）トラフィックをファーム A に、HTTP トラフィックをファーム B に送るようにでき、サーバを特定のタスク向け、およびより効率的なリソースの割り当てに使用できるようにします。
• サービスに基づいたサーバへのアクセスの拒否または受け入れ - LocalDirector では、HTTP トラフィック以外の TCP トラフィックをすべて拒否してセキュリティのレベルを向上させることができます。
• サーバおよびサーバ上のすべてのサービスを停止させず、1 つのサービス・デーモンだけを停止させる - 複数の Web デーモンを同じサーバ上で稼働させることができ、これらの Web デーモンの 1 つに障害が起きた場合、そのデーモンだけを（サーバ全体ではなく）サービスからはずします。これにより、サーバ・ファームの信頼性が向上します。

また、アプリケーションもボトルネックになり、どれほど高性能のコンピュータの中央演算処理装置（CPU）でもパフォーマンスが向上しない場合があります。

LocalDirector では、管理者は同一のコンピュータ上でデーモンの複数のインスタンスを実行でき、これにより、システム全体の帯域幅を向上させることができます。

インターネット Web サイトがカスタマや主要パートナをサポートするミッション・クリティカルなアプリケーションになったため、企業では Web サイトのパフォーマンスを慎重に分析しています。Web サーバのパフォーマンスを測定するためにモデルが開発され、その結果、応答時間は徐々に増加して無限大に近づく漸近線を形成することが示されました。さらに、帯域幅、サーバ・パフォーマンス、およびファイル・サイズによって応答曲線の全体の結果が決定されます（これがサーバ・システムのパフォーマンスになります）。

サーバの応答曲線を分析に使用することで、次の 3 つの Web アーキテクチャを検討しました。シングル・サーバ・ソリューション、DNS ラウンドロビン方式、および Cisco LocalDirector です。分析の結果、Cisco LocalDirector によりサーバ・システム全体のパフォーマンスが徐々に、またスケーラブルに向上することが示されています。LocalDirector の強力な管理機能には、サーバを容易にオンライン⁄オフラインにする方法、アプリケーションに依存しないオペレーティング・システム、IP アドレスの管理、および、アベイラビリティに基づいてサーバをサービス対象にしたりはずしたりする透過的かつ自動的な方法が含まれています。しかし、さらに重要な事項は、管理者がより強力で高いパフォーマンスを持つ Web サイトを管理できるようにすることです。