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

SaaS時代のアプリケーションスイッチはこう選ぶ

製品の登場から10年、アプリケーションスイッチの機能・性能はもはや成熟期にあり、単純に価格や性能だけで比較や選択はできない。それなら、「どう使いこなすか」で選択しよう。

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

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

著者

岸部貞治

[ネットマークス]

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

　約10年前に登場したアプリケーションスイッチは、インターネットトラフィックの増大とともに、主にWebサーバトラフィックの高速化・最適化に大きく寄与してきた。前回「意外に長い？ 10年の歴史に見るアプリケーションスイッチの効用」は、アプリケーションスイッチの基本である3つの要求（負荷分散と冗長化、サーバオフロード、パーシステンス）と、その実現方法について説明した。今回は応用編として、そのほかの拡張機能や利用例などを説明するとともに、製品・技術に関するトレンドを紹介する。また、それらを踏まえた上でアプリケーションスイッチ製品の正しい選択ポイントについて解説していく。

不正攻撃も守る　アプリケーションスイッチの拡張機能

　アプリケーションスイッチは、ネットワーク上を流れるトラフィックからHTTPなどのアプリケーションの情報を取得し、制御することができる。この特徴を生かして、セキュリティやトラフィック制御・管理などの拡張機能を備える製品が多い。ここではその機能の幾つかを取り上げる。

セキュリティ機能の付加

　アプリケーションスイッチがWebサーバのフロントエンドに配置されることから、Webサーバ群を保護するために、ファイアウォールやIDS／IPS（侵入検知／防御システム）機能を併せ持つことが多い。ファイアウォール機能では、パケットフィルタはもちろんステートフルインスペクション機能を持つ製品もあるなど、別途専用機を追加することなく、スイッチ配下のサーバ群を保護することができる。

　また、WebサーバがDoS（サービス妨害）攻撃の対象となることが多いため、これらを防ぐIDS／IPS機能を持つことがある。例えばSYNフラッド攻撃（※）に対しては、アプリケーションスイッチの基本機能でもあるディレイドバインディング技術（図1）により、SYNフラッドを除く正常な通信のみをサーバへ振り向けることで、Webサーバを保護することができる。またSYNフラッド攻撃を防ぐSYNクッキーを、サーバに成り代わって生成できる製品もある。

図1●ディレイドバインディング技術（＠IT「DoS攻撃防御製品の仕組みと特徴」より）

※注　ハンドシェイクが確立しないTCP接続を大量に試みることでサーバの機能を停止させようとするDoS攻撃の1つ。

　さらに、SQLインジェクションやクロスサイトスクリプティング（XSS）などから防御するためのWAF（Webアプリケーションファイアウォール）機能や、ワームやスパムメールを遮断する機能をアプリケーションスイッチに統合した製品が登場している。

トラフィック管理

　アプリケーションスイッチは、企業の基幹システムやインターネットサービスにおける重要なサーバとの通信を集約して制御する位置付けにある。このため、システムやサービスごとの可用性や信頼性を高めるため、トラフィック管理機能を持つことが多い。

　こうした機能を持つアプリケーションスイッチでは、サービスごとの重要度の違いや、同じサービスの場合にはPCやケータイといった端末の違い、登録／非登録などユーザーステータスの違いなどによって、提供するサーバやトラフィックの優先度を変えることができる（図2）。

図2●トラフィック制御の例。同じURLあてのトラフィックでも、端末の種類によってサーバを切り替えたりトラフィックの優先度を変えることができる

　さらにはサービスごと、サーバごとのトラフィックの帯域を制御する機能を備えた製品もある。帯域制御といっても、単純なポート番号単位だけではなく、アプリケーションスイッチの特性を生かして、URL単位での帯域監視・制御などが可能なほか、サーバごとの使用帯域を基に負荷分散することもできる。

アプリケーションスイッチの応用例

　アプリケーションスイッチの大半は、Webサーバのトラフィック高速化／最適化に使われているが、そのほかの代表的な応用例を幾つか紹介する。

サーバ負荷分散

　まず、当然ながらアプリケーションスイッチをWebサーバ以外の負荷分散に利用することができる。レイヤー4（ポート番号）レベルであれば、ほとんどのサーバの負荷分散・冗長化が可能であると言ってもよい。一部のプロトコルについて、例えばIP電話で利用されるSIP（Session Initiation Protocol）サーバや、Microsoft／IBM／Oracleなどが提供する特定アプリケーションサーバを、プロトコル情報を理解した上で負荷分散できる製品もある。

ファイアウォールの負荷分散

　アプリケーションスイッチを用いれば、ファイアウォールの負荷分散やオフロードによるトラフィックの最適化が可能だ。ただしファイアウォールは、ルータなどと同様、ネットワーク上の通過点に設置され、自分あて以外のトラフィックを処理するために用いられる（このような機器を「透過型デバイス」と呼ぶ）。このため、Webサーバのときとは異なる構成をとることになる。

　ファイアウォール負荷分散は、図3に示すように、複数台のファイアウォールをアプリケーションスイッチで挟む構成となる。この技術を応用すれば、同じ透過型デバイスであるルータやIDS／IPSなどの負荷分散に応用することも可能だ。

図3●ファイアウォール負荷分散の構成例。ファイアウォールにはセッション管理機能があるため、行きと帰りは必ず同じファイアウォールを通さなければならない。そこで、アプリケーション単位や、送信元／送信先両方のIPアドレスの組み合わせでどのファイアウォールを通すかを決定する

WANリンクの負荷分散

　安価なWAN回線の普及やインターネットの高速化／低価格化により、一般企業でもWAN回線やインターネット接続を冗長化・負荷分散するところが増えてきた。ここでもアプリケーションスイッチが活躍する。

　インターネット回線の負荷分散（インバウンド）の例を図4に示す。ここでは1つのインターネット向けサービスを、BGP（Border Gateway Protocol）などの技術を使わずに、ISP回線ごとに変換するIPアドレスを切り替えることで負荷分散を実現している。もちろん、企業における外向けインターネット回線の負荷分散（アウトバウンド負荷分散）や、拠点間のWAN回線冗長化にも応用が可能である。

図4●インターネット回線の負荷分散。アプリケーションスイッチがDNSサーバとして機能し、同じサービスでも複数の経路で別々のIPアドレスを返信する

グローバル負荷分散

　アプリケーションスイッチは、1つのサイト内に設置されたサーバだけでなく、複数のサイトに配置されたサービスのトラフィックを負荷分散（グローバル負荷分散）することもできる。グローバル負荷分散技術は以前から実現されていたものの、国土の小さい日本での採用例は少なかった。しかし近年は、ディザスタリカバリ（災害復旧対策）に有効として注目を集めている。

アプリケーションスイッチの正しい選び方

　これまでアプリケーションスイッチの技術・利用面を解説してきたが、それらを踏まえて、実際に製品を選択するときにどのような点を考慮すべきかまとめておく。

導入の目的を明確にしよう

　前回紹介したように、アプリケーションスイッチには魅力的な機能がたくさんあり、目移りしてしまうほどである。ただしこれらの機能すべてが、すべてのWebサイトに有効とは限らない。

　当たり前のことだが、まずは導入の目的を明確にしよう。具体的には、アプリケーションスイッチに求めるべき重要な機能・性能は何か、向こう1年間に必要となる事項は何かを決定しよう。とはいえ、アプリケーションスイッチの導入経験がなければ分からないことも多いので、そのときはメーカーやベンダーに気楽に相談すればよい。

アプリケーションスイッチを過信しない

　まれにだが、アプリケーションスイッチは何でもできる万能な機器だと思っている人を見かける。確かに豊富な機能を持っており、サーバ回りに求められる多くの要件は実現できるが、一方で何らかの原因で本来の性能が出せなかったり、トラブル発生時に問題解決が遅れたりする可能性がある。

　前項にも関連するが、アプリケーションスイッチで実現すべき機能を絞り込み、ほかのネットワーク機器やサーバとの機能分担を明確にすべきだろう。

比較表をうのみにしない

　皆さんは複数のベンダー・製品を検討する際、比較表を求めたことがあるだろうか。ベンダーに比較表の作成を要求した場合、提示される比較表は自社製品に有利なように書かれ、まず公平に評価されてないと思った方がよい。また多くの機能が記載されていると、前述の通り不要な機能などに惑わされる原因になりかねない。

　最終的に比較表で導入を決めるときには、各ベンダーから提供された情報を基に必要な項目だけに限定したものを自ら作成してみるとよいだろう。

ベンダーの能力を見極めよう

　製品が登場したころはベンダーによって機能が大きく異なることもあったが、今では基本的機能はどこもほとんど変わらないと言っていい。一方で、ネットワークとサーバ両方の技術要素が関係するため、同じ製品を扱っていても、ベンダーや技術者によってそのスキルレベルに差が出ることがよくある。以下の点でベンダーの実力を見極める必要がある。

提案／コンサルティング能力
システム構築能力
トラブルシューティング力

　具体的には、ベンダーに対しあらかじめ明確にした導入目的を提示し、製品選択の理由や具体的な構成などを含めた提案を依頼してみよう。その回答から、数字だけではない、導入実績やベンダーの真の技術力を見極めることができるかもしれない。

運用・管理の視点も考える

　企業のシステム運用・管理において、ネットワーク管理者とサーバ管理者は異なる場合がある。アプリケーションスイッチの導入、その後の運用・管理をどちらの担当者が行うかということも、選択のポイントになり得る。

　製品によって、コンソールベースのCLI（Command Line Interface）や、WebやJavaベースのGUI（Graphical User Interface）などの設定方法がある。また日常の管理項目や機器故障時の交換手順なども、製品によって大きく異なることがある。

ローエンドか、ハイエンドか

　大手ベンダーが高機能のハイエンド製品を提供する中で、市場にはよりシンプルな機能を低コストで実現する製品が出回り始めた。以前は購入に数百万円掛かったが、今では100万円以下で購入できるものもある。その一方で、高機能・高性能な製品には、数千万円クラスのものもある。つまり、以下のようなアプリケーションスイッチの二極化現象が起きている（表1）。

表1●製品の二極化
種類	概要	価格帯
ハイエンド機器	データセンターなどの利用を前提に、より高性能・高機能を実現した製品	数百万～数千万円
ローエンド機器	負荷分散・サーバオフロードなど基本的機能を実現し、安価に提供する製品	数十万円～

　このように、冗長化と負荷分散を実現することが優先するならローエンド機器で十分であり、一方で複数の重要なサービスを安定して提供する必要があるのならハイエンド機器が必要だろう。MTBF（平均故障間隔）など機器単体の信頼性は使用する部品に左右されるため、どちらが高いとは一概に言えない。

　では、提供するサービスが高い信頼性を求める場合は、どちらを選ぶべきだろうか。一般論としては、ハイエンド機器は突発的なトラフィックに対処できることも含め、高い信頼性を実現しているといえる。またハイエンド機器でも、機能追加をオプションで提供することが多いため、当初利用する機能を限定すれば導入コストを抑えることができる。

最後に――アプリケーションスイッチの将来

　サーバの世界では、多くの拠点に分散したサーバを1カ所に統合する「サーバ統合」が進み、ハードウェア資産を有効活用するためのVMwareやXenなど「サーバ仮想化」の技術が積極的に採用されている。そのような統合化・仮想化の波が、アプリケーションスイッチへも押し寄せている。

　また、ガソリン価格高騰の影響などからグリーンITが強く叫ばれるようになった最近では、SaaS（Software as a Service）がより注目を集めるなど、システムを「所有」から「利用」へ切り替えるところが少なくない。データセンターへの集約やSaaSの積極的活用が進む中、PaaS（Platform as a Service）や、CaaS（Communicaton as a Service）という言葉も登場しており、アプリケーションスイッチの導入形態もこれからは必然的に「所有」から「利用」へと変わることになる。

　事実、米Cisco Systems、加Nortelや米F5 Networksなどアプリケーションスイッチの主要ベンダーは、仮想化・統合化を積極的に採用し、システムのサービス利用に適した製品や技術を次々にリリースしている。アプリケーションスイッチはユーザーの要望や期待に応えつつ、その市場はまだまだ成長を続けそうだ。

＜筆者紹介＞

岸部貞治

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

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

印刷する

この記事の著者

岸部貞治

SaaS時代のアプリケーションスイッチはこう選ぶ