負荷分散だけじゃない、Web高速化装置の魅力【前編】

意外に長い？ 10年の歴史に見るアプリケーションスイッチの効用

アプリケーションスイッチの歴史は、その前身を含めて10年と長い。機能・性能とも大きく進化したが、ユーザーニーズはあまり変化していない。その基本機能を理解するとWebサイトで重宝される理由が見えてくる。

公開 2008年07月23日 08時00分

更新 2012年09月04日 18時49分

著者

岸部貞治

[ネットマークス]

印刷する Googleで優先するソースとして追加

　ロードバランサ、負荷分散装置、レイヤー4（L4）スイッチ、L7スイッチ、Webスイッチ、アプリケーションフロントエンド（AFE）、アプリケーションデリバリコントローラー（ADC）――。「アプリケーションスイッチ」は、その前身が約10年前に市場に登場して以来、その製品としての進化の過程を歩む中でいろいろな名称で呼ばれ、特にWebサーバトラフィックの高速化、最適化に大きく寄与してきた。

　1996年ごろのギガビットイーサネットやL3スイッチの登場をきっかけに、LANはイーサネット、プロトコルはTCP/IPが事実上の標準となった。当時の技術的な背景としては、ASIC（特定用途向けIC）による高速化や、それまで汎用サーバ＋ソフトウェアだったファイアウォールなどを専用ハードウェアに組み込んだ「アプライアンス製品」の普及があった。そのような中で、今のアプリケーションスイッチの草分けとなる、L4スイッチであるAlteon Networks（現Nortel Networks）の「ACEdirector」や、負荷分散アプライアンスであるF5 Networksの「BIG-IP」が登場した。

　ご存じの通り、L2スイッチはイーサネットフレームを、L3スイッチはTCP/IPなどのパケットを処理するためのスイッチである。これに対しアプリケーションスイッチは、より上位のレイヤーであるセッションやトランザクション、つまりアプリケーションを処理するスイッチである。アプリケーションスイッチと呼ばれるゆえんはここにある。当初は専用アプライアンスだったSSLアクセラレータも、2000年ごろにはアプリケーションスイッチに内蔵されるようになった。ここ数年ではTCPコネクション集約やHTTPデータ圧縮など、さらに高速化、高機能化が進んでいる。

　インターネットの広帯域化やWebコンテンツの普及・大容量化などを背景に、アプリケーションスイッチのマーケットも確実な成長を遂げ、今では全世界で10億ドル規模、日本でも100億円以上の市場といわれている。製品の登場から10年、その間に機能・性能は劇的に進化したが、アプリケーションスイッチに対して利用者が求めるものは、基本的に大きくは変化していない。ここではユーザーの要求やそれを実現する機能をひもときながら、アプリケーションスイッチの基本をより正しく理解していただきたいと思う。

アプリケーションスイッチへの要求（1）：負荷分散と冗長化

　かつてのホストコンピュータ全盛の時代、より高性能・高信頼性を求めるには、そのマシン自体の性能や信頼性を向上させるしかなかった。そしてオープンシステムへと変化した現在、サーバ単体の信頼性が飛躍的に向上、さらにシステム全体の性能や信頼性を向上させるためにサーバを冗長化して負荷を分散させるようになった。そのようなオープン化の流れの中で登場したのが、ロードバランサやL4スイッチと呼ばれる製品だった。

　例えば1台のサーバを冗長化するとき、同じ機能を実現するサーバを2台用意し、1台を正系（アクティブ）、もう1台を副系（スタンバイ）とし、正系のサーバに障害が発生した際に、副系のサーバに切り替える。つまりサーバ2台のうち1台は、障害が発生しないと使われないことになる。2台あるのなら両方とも同時に利用すれば、信頼性の向上だけでなく性能の向上にもつながる。これが、アプリケーションスイッチへの要求で最も基本となる負荷分散と冗長化である。

アプリケーションスイッチによる負荷分散

　アプリケーションスイッチでは、どのような仕組みで負荷分散を行い、システムの性能や信頼性の向上を実現しているのかを説明しておこう（図1）。

図1●負荷分散の概要

スイッチ上に「仮想サーバ」を設定する（IPアドレス＝VIP）
スイッチ配下に「実サーバ」を配置する。このとき実サーバのIPアドレスは、クライアントからは見えない
クライアントはVIPへ向かってアクセスする
スイッチは、あるアルゴリズムに従って負荷を分散する
サーバの生死を常に確認（ヘルスチェック）し、「死んでいる」サーバは対象外とする

　この中で、アプリケーションスイッチ特有の重要な機能として「負荷分散アルゴリズム」と「ヘルスチェック」が含まれている。

負荷分散アルゴリズム

　負荷分散アルゴリズムとは、どのようなルールに従って複数台のサーバにデータを振り分けるかを指す。代表的なアルゴリズムには以下のようなものがある。

アルゴリズム	内容
ラウンドロビン	リクエストを複数台のサーバに順番に割り当てる。サーバごとに割り当ての重み付け（ウエート）をかけることがある
最小コネクション数	各サーバに接続しているTCPコネクションが最も少ないものにリクエストを割り当てる。サーバごとに重み付け（ウエート）をかけることがある
応答時間	最も応答時間が早いサーバへリクエストを振り分ける

サーバのヘルスチェック

　負荷分散の際、信頼性を維持するには、配下のサーバを常に死活監視（ヘルスチェック）し、利用可能なサーバのみを負荷分散の対象とする手段が必要となる。代表的なヘルスチェックの方法には以下のようなものがある。

ヘルスチェック方法	内容
・ICMPチェック（L3レベル）	対象サーバがICMP（ping）に応答するかどうかを確認し、サーバとIP通信が可能かどうかを見る
・TCPチェック（L4レベル）	対象サーバに対し、稼働しているTCPポート番号（HTTPであれば80番）で3ウェイハンドシェイクを行い、サーバ上でHTTPなどのアプリケーションが動作しているかどうかを確認する
・アプリケーションチェック（L7レベル）	実際のアプリケーションによる通信を行い、正しい応答が得られるかどうかを確認する

　後者になるほど、より正確な死活監視ができる。半面、ヘルスチェックは数秒ごとに行うことが多く、同様に後者になるほどスイッチやサーバへの負荷も掛かる。

　負荷分散と冗長化は、その登場の背景から見ても、アプリケーションスイッチを利活用するほぼすべてのケースに適用できる機能だといってよいだろう。

アプリケーションスイッチへの要求（2）：サーバのオフロード

　以上のような負荷分散により、複数台のサーバを用意すれば性能と信頼性を向上させることができる。一方で、サーバを必要以上に増やすことなくシステムの性能を高められれば、ハード／ソフトを含めたサーバのコストを抑えることもできる。つまり、サーバの負荷を軽減（サーバオフロード）するのだ。

SSLアクセラレーション

　サーバ負荷軽減としてまず求められるのが、SSLアクセラレーションである（図2）。インターネットショッピングなどで用いられるHTTPS（HTTP over SSL）は、SSLの鍵交換や暗号化／復号の処理のため、通常のHTTP通信よりサーバに負荷が掛かる。このSSL処理をアプリケーションスイッチ上で代わりに行い、サーバとの間はHTTP通信とすることで、サーバに掛かる負荷を大幅に軽減できる。

図2●SSLアクセラレーションの仕組み。サーバは通常のHTTPのみを処理する

　SSLアクセラレーションは、クレジットカード決済可能なインターネットショッピングサイトや、インターネットバンキングなど、特に電子決済系で通信の暗号化を必要とするWebサイトには必須の機能といえる。

TCPコネクション集約

　HTTPなどに代表されるTCP通信は、通信の信頼性を高めるため、セッションの確立から、一定量のデータ転送ごとの通信確認、セッションの終了確認までを行う。このため、特にクライアントからのリクエストが集中するサーバでは、TCPセッションの確立や終了による負荷が無視できない。これを改善するのが、TCPコネクション集約である（図3）。アプリケーションスイッチとサーバとの間で一定数のTCPセッションを確立し、クライアントからのリクエストはそのセッション内に含めることで、TCPセッション開閉のオーバーヘッドを減らし、サーバの負荷を飛躍的に下げることができる。

図3●TCPコネクション集約の仕組み。TCP接続の開閉によるオーバーヘッドが減るためサーバの負荷が下がる

　TCPコネクション集約は、サーバアプリケーションが高価であるなど、何らかの理由によりサーバ台数が増やせない場合に大きな効果が期待できる。

　なおTCPコネクション集約とは異なるが、携帯電話など通信速度が比較的遅いクライアントが多い場合、サーバからのセッションを早めに解放し、クライアントとアプリケーションスイッチが継続してコンテンツを提供する「TCPバッファリング」も、サーバとのTCPセッションにかかわる負荷を下げる技術として有効だ。

コンテンツキャッシュ

　Webサーバ上で頻繁に使われるコンテンツをキャッシュし、サーバの代わりに応答させるリバースキャッシュは、かねてよりサーバの負荷軽減策として用いられてきた。アプリケーションスイッチの中には、搭載メモリの一部をキャッシュ用に割り当てることで、リバースキャッシュを実現しているものがある。コンテンツキャッシュは、静止画像やテキストなど、静的なコンテンツが多く含まれるWebサイトの高速化に大きな効果が期待できる。

HTTPコンテンツ圧縮

　HTTPコンテンツ圧縮は、WebサーバからのコンテンツをGZIPなどの形式で圧縮してトラフィックを削減する技術だ。サーバからのコンテンツデータを、クライアント送信前にアプリケーションスイッチであらかじめ圧縮し、クライアントのWebブラウザでデータを展開する（図4）。クライアントとの通信帯域（トラフィック）削減のほか、応答時間の短縮などによるサーバ負荷軽減の効果が期待できる。また送受信データの削減により、パケットロスや遅延時間の影響を受けにくくなる。

図4●HTTPコンテンツ（オブジェクト）を圧縮してトラフィックを減らすことでレスポンスが向上する

　HTTPコンテンツ圧縮は、圧縮が期待できるコンテンツ、つまりテキストや圧縮率の低い画像などに効果がある。一方で圧縮率の高いJPEGなどの画像はほとんど効果が得られない。

　ここで挙げた機能の多くは、「WAN高速化装置」（関連記事「WAN高速化装置の導入効果が得られる条件とは？」参照）でも搭載されていることが多い。同じくアプリケーションの性能を向上させるものだが、両者が異なるのは、WAN高速化装置が拠点間に対向で設置するのに対し、アプリケーションスイッチはサーバ側にのみ設置する点だ。アプリケーションスイッチが特定のWebサーバやアプリケーションなどの高速化を目的としているため、サーバ側の設置のみである程度の効果が得られるよう設計されている。

アプリケーションスイッチへの要求（3）：セッション維持

　サーバ負荷分散によって、クライアントからのリクエストを均等に振り分けることができるが、その一方で負荷分散させたくない場合もある。例えばショッピングサイトで、ユーザーのショッピングカートに品物が入っている間は、同一のサーバで処理をさせたいことがある。これを実現するのがセッション維持機能だ。パーシステンス機能（「持続性」の意味）やスティッキー機能（「ねばねばした」の意味）と呼ばれることもある。以下に、セッション維持の代表的な2つの方法を紹介する。

IPアドレスによるセッション維持

　最も簡単かつ確実な方法は、同一のクライアントIPアドレスからのリクエストを同じサーバに振り分けることである。ただし、プロキシサーバ経由のアクセスが多いなど、クライアントIPアドレスに偏りがあると、サーバへ負荷を均等に分散できないことがある。このようなときは、セッション開始時にラウンドロビンなどで通信するサーバを決め、以降セッション終了まで同じIPアドレスからのリクエストを同じサーバへ振り分けることもできる。

上位レイヤー情報によるセッション維持

　IPアドレスによるセッション維持が使用できないときは、より上位のレイヤーであるCookieやURIによる情報を使ってセッションを維持することができる。図5の例で見ると、まずセッション開始時にサーバやアプリケーションスイッチでCookieを設定する。そして次回以降のアクセスでは、アプリケーションスイッチがHTTPセッションを終端して、設定されたCookieの値を読み取り、同一のサーバへ振り分けられるようになるというものだ。

図5●Cookieによるセッション維持

　携帯電話は、セッション中にIPアドレスが変更されることがあるため、IPアドレスによるセッション維持ができない。またSSL通信では、Cookieなどの情報も暗号化されるため、IPアドレスによるセッション維持が使えない場合がある。そこで、SSLアクセラレーション処理時に併せて復号し、URIなどの情報を用いてセッション維持を行う必要がある。

　ここまでは、アプリケーションスイッチの基本として、負荷分散と冗長化、サーバ負荷軽減、パーシステンスの3つの要求と、その実現方法について説明してきた。次回は応用編として、そのほかの拡張機能について紹介し、製品・技術に関するトレンドを踏まえた製品選択のポイントを解説しよう。

＜筆者紹介＞

岸部貞治

ネットマークス技術本部企画推進部技術企画室長

会社設立以来、ネットワーク関連商品・ソリューションの企画・マーケティング・検証などの業務に従事。1998年ごろに初めてL4スイッチと出会い、以降アプリケーションスイッチへの劇的ともいえる変化を常に目の当たりにしてきた。

印刷する

この記事の著者

岸部貞治

意外に長い？ 10年の歴史に見るアプリケーションスイッチの効用