jump to navigation

Webアプリケーションのロードバランス 10月 11, 2009

Posted by hyhy in 技術情報.
Tags:
trackback

拡張性のある企業Webアプリケーションを作るには、クライアント側とサーバ側の両方のコンポーネントをよく検討する必要があります。しっかりしたコードベース、厳正に実装されたキャッシュ、圧縮技術を用いたコンテンツアクセラレーションは、高いパフォーマンスを得るための最適な土台作りに役立ちます。

 大手ポータルサイトを例に、これらは動的なWebアプリケーションであり、データベーストランザクションを実行し、コンテンツをリアルタイムで構築して表示します。単なる画像やHTMLの固定コンテンツを表示するサイトよりも多くの処理を行っています。同一サイト(Webアプリケーション)を繰り返し利用するユーザーも多く、こうした人々は常に一定の(あるいは前回よりも優れた)パフォーマンスを期待しています。パフォーマンスが期待に反すれば、そのサイトはユーザーベースをライバルに奪われるおそれがあります。ユーザーがクリックするたびに、一定の負荷がサーバに課されます。このクリックが数百万回も発生すれば、サーバの負荷はたちまち増大します。

 サーバの能力は有限なので、すべてのユーザーの要求に応じるにはサーバを集合的に利用するしかありません(このサーバの集合のことをサーバファームと呼びます)。しかし、各サーバは個別に動作しているわけですから、負荷の上昇に伴って要求を複数のサーバに分散し、ユーザーに提供されるパフォーマンスのレベルを均等に保つ必要があります。ロードバランスは、受け取った要求を複数のサーバに分散するためのプロセスです。

 1台かそれ以上のサーバがダウンした場合、ロードバランサは処理能力の減退を認識し、要求を適切に振り分ける必要があります。このようにエンドユーザー側から見たパフォーマンスを落とさずに処理を続ける機能もロードバランスの一部であり、これを”高可用性”と呼びます。

 簡単に言えば、ロードバランスとは、サーバファームへの一本化されたエントリポイントを提供し、負荷をファーム内のすべてのサーバに分散化することです。ロードバランスは、HTTP Webアプリケーションのみならず、FTPなどの他のプロトコルを使うアプリケーションや、チャットアプリケーションにも有効です。

■ロードバランスの方式
一般的なロードバランスのソリューションはハードウェアとソフトウェアの両方から構成されますが、純粋にソフトウェアまたはハードウェアのみで機能するソリューションもあります。

1)ソフトウェアベースのロードバランサは、すべてのクライアントが接続するサーバ上で動作します。ロードバランサのソフトウェアはポートをリッスンし、サーバファーム内のどのサーバに要求を処理させるべきかを判断します。ソフトウェア型のロードバランサは、リバースプロキシキャッシュに似ています(ただし、通常はキャッシュを備えていません)。サーバに代わって、受け取った要求をサーバに振り分けるのがその役目です。従って、ユーザーがサーバ本体に直接通信することはできません。ロードバランサは、要求元のクライアントがバックエンドサーバに直接通信することがないようにします。これは実質的に1つのセキュリティ層となります。このタイプのロードバランサをオープンソースで製品化した例が、Apacheのmod_proxy_balancerエクステンションです。

2)ハードウェアベースのロードバランサは、ルーティング、トンネリング、またはIP変換に基づいて機能します。取り扱いが複雑になるので、このタイプの導入を検討している場合はエキスパートの力を借りてセットアップや構成を計画することをお勧めします。

 要求の処理を担当するサーバをロードバランサが選択するときには、さまざまな方法が使われます。ランダムに選択する、あるいはラウンドロビン方式で割り振るというシンプルなやり方もありますが、商業製品として提供されているもっと複雑なソリューションでは、サーバの負荷、トラフィックの状況、サーバとエンドユーザーとの隣接レベル、地理的な位置、最新の応答時間なども考慮してサーバが選択されます。

 多くのソリューションでは、HTTPS(SSL対応接続)の使用が必須です。このようなアプリケーションでは、暗号化と復号のオーバーヘッドが生じるため、ハードウェアやソフトウェアのリソースが集中的に消費されます。過大な処理負荷を緩和するために、SSL接続だけを扱う特殊なハードウェアを設置し、暗号化と復号のタスクをこれに任せてWebサーバの負担を軽くできます。この方法と似ていますが、1台のサーバにセキュリティ処理(ユーザーの認証と承認)を割り振り、他のWebサーバがコンテンツの要求と応答の処理に専念できるようにすることも可能です。

 ロードバランサは、サーバの応答をバッファ化することもできます。負荷が高くなってきたらロードバランサが応答をバッファまたはキャッシュから取り出して返すようにすれば、サーバの処理能力を節約して、他の優先度の高いタスクに振り向けることが可能になります。

 ロードバランサはサーバの「健康診断」を実施して、ダウンしたサーバまたは過負荷状態のサーバを認識できます。サーバの稼働状況の診断は、ほぼリアルタイムに行うことも、定期的に行うこともできます。異常なサーバが見つかった場合は、それぞれのソリューションの要件や機能に応じて手動または自動で正常なサーバに置き換えます。

 大規模なポータルは、ハッカーからさまざまな手口で攻撃され、深刻な脅威にさらされることがあります。例えば、同じURLを連続して要求してDoS(Denial of Service:サービス停止)攻撃や分散DoS(Distributed Denial of Service)攻撃を実行するプログラムは、サーバに極度の負荷を与えます。ロードバランサは、このような攻撃を緩和または阻止する能力を備えています。

■DNSベースのロードバランス
インターネットのDNS(Domain Name System)は、ドメイン名をIPアドレスに解決する仕組みです。ラウンドロビン型のDNSロードバランスは、特別なハードウェアやソフトウェアのコンポーネントを必要としないロードバランス方式として人気があります。DNSロードバランスを実装するには、DNSの基本とDNS解決のプロセスを十分に理解する必要があります。

 例えば、ブラウザからhyhy.wordpress.comというURLが要求されたとします。ブラウザはhyhy.wordpress.comのサーバに到達する必要がありますが、その前にこのURL文字列をwordpressサーバのIPアドレスに変換しなければなりません。DNSは、URL文字列のドメイン部分(ここではwordpress)をIPアドレスに変換します。

 ブラウザ側は、まず解決済みのアドレスが自分のキャッシュに入っていないかを確認します。最近hyhy.wordpress.comを開いたことがあれば、そのIPアドレスはブラウザのローカルDNSキャッシュに残っています。キャッシュにあれば、そのIPアドレスを使って接続を直接開きます。hyhy.wordpress.comを指すIPアドレスがキャッシュに複数ある場合は、サーバとのHTTP接続が成立するまで順番にIPアドレスを試していきます。
※ブラウザのDNSキャッシュは、ブラウザのHTTPコンテンツキャッシュとは別に存在します。

IPアドレスがキャッシュにないか、キャッシュ内のIPアドレスがどれも有効ではない場合は、あらためてIPアドレスを取得する必要があります。ブラウザは、名前をIPアドレスへと解決するためにオペレーティングシステムと通信します(オペレーティングシステムにもDNSキャッシュがあり、キャッシュ内のIPアドレスをブラウザに通知できることがあります)。

 オペレーティングシステムにドメインのIPアドレスがキャッシュされていなければ、DNSサーバ(ドメインネームサーバ)に問い合わせが発行されます。ユーザーマシンにあるローカルリゾルバは、ルートDNSサーバに問い合わせを発行します。これに応じて、ルートサーバはアドレスが取得されるまで次々とサブDNSサーバと通信します。取得されたアドレスはブラウザに返されます。一致するIPアドレスが見つからない場合は、エラーコードが返されます。

DNSの仕組みを理解したという前提で、ラウンドロビン方式の説明に戻ります。ユーザーからのDNS要求に対するDNS応答を適切に扱うには、1組のサーバをラウンドロビン方式で操作します。例えば、1つのDNS要求に対して複数のIPアドレスを応答するのも、この方式の実装例です。クライアントがIPアドレスを要求すると、ブラウザはDNS応答の最初のIPを試します。このアドレスが無効であれば次のIPを試す、という流れで手続きは進みます。サーバIPに正常に接続するたびに、返されるIPの順序も変わります。従って、クライアントがIPを要求すると前回とは別のIPが返されることになり、実質的に負荷が複数のサーバに分散されます。

 このテクニックは、WebサーバとFTPサーバの両方で負荷分散に効果があります。世界各国のユーザーからアクセスがあるようなサーバに地理的なロードバランスを提供する方法として、これはよく使われます。要求にタイムリーに応じるには、サーバの方も世界各地に分散して配置すると有効です。要求元のクライアントからなるべく近い場所にあるサーバで要求を扱うことは、明らかに理にかなっています。このようなロードバランスを設定するには、クライアントの地域や隣接する場所にあるサーバのIPリストをDNS要求で返されるIPリストの先頭に配置します。使用できるローカルサーバが複数ある場合は、要求ごとに順序を変えてDNSリストを入れ替える(負荷を均等にする)ことができます。

 残念ながら、単純明快さを長所とするこの方式にも欠点があります。例えば、稼働状況の自動チェックを行わない場合、セットになっているローカルサーバがすべてダウンしたときも、DNS応答に含まれるその地域のIPリストにダウン中のサーバIPが残ってしまいます。また、ラウンドロビン方式のDNSロードバランスでは各ユーザーからの負荷の大小は考慮されず、単に要求が順番にサーバに割り振られるに過ぎません。このような問題を克服するには、サーバの可用性と負荷を調べる機能を実装します。ご想像のとおり、このような機能はあっという間に複雑化するため、大規模ポータルでは自前でサポートするよりもこの分野で実績のある商用プロバイダを頼るのがよいでしょう。(CDNについては別途)

 ロードバランスのソリューションを検討する際に着目すべきはパフォーマンス、信頼性、拡張性の3点であり、さらに各自の要求事項や予算に基づいて各ソリューションの長所・短所を判断してください。

参考サイト

広告
%d人のブロガーが「いいね」をつけました。