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

　アプリケーションスイッチの大半は、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）。

　このように、冗長化と負荷分散を実現することが優先するならローエンド機器で十分であり、一方で複数の重要なサービスを安定して提供する必要があるのならハイエンド機器が必要だろう。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などアプリケーションスイッチの主要ベンダーは、仮想化・統合化を積極的に採用し、システムのサービス利用に適した製品や技術を次々にリリースしている。アプリケーションスイッチはユーザーの要望や期待に応えつつ、その市場はまだまだ成長を続けそうだ。