Jun.- 2010 1
はじめに
業種に関わらず、いまや仮想化はデータセンターにおける新たなテクノロジーから、あらゆる規模 の組織やエンタープライズで標準的に利用されるツールになってきました。2007 年 8 月に Rackspace が行った仮想化に関する調査では、72 パーセントの回答者が本番環境に仮想化アプ リケーションを展開するのに意欲を示しており、仮想化に強い安心感を持っていることが明らかと なりました 。その後、Shavlik Technologies が行った調査では、75 パーセントの回答者がすでに本 番環境のサーバの半分を仮想化していたことがわかりました 。著名なリサーチ会社の調査を含 むその以外の最近の調査でも、このような傾向が確認されています。仮想化の普及率から、大半 の組織ですでにデータセンターの仮想化を採用していることも実証されています。 仮想化は広く採用されている一方、今なおさまざまな課題を抱えています。2008 年初めに CIO.com が実施した調査では、仮想化環境を導入し管理するうえで、多くの課題があることを示し ています。なかでも最大の課題（64 パーセント）は、サーバの作業負荷を分散させてアプリケーショ ンの性能を維持することでした。 仮想化技術がさらに広く利用されるようになるにつれ、採用した人たちは IT の俊敏性とビジネスに おけるニーズの変化への対応をさらに向上させるため、データセンターの他のコンポーネントの仮 想化にも取り組みました。ネットワークベンダーやアプリケーションネットワークベンダーは、従来 の物理的なデバイスの仮想化製品を提供するよう急きたてられており、仮想ネットワークアプライ アンス製品がどんどん増えています。 しかし、アーキテクチャに関する適切な理解がなければ、これらの仮想ネットワークアプライアンス を効果的に導入することが困難になる可能性があります。サーバの仮想化がデータセンターの ネットワークやアプリケーションネットワークインフラの仮想化は、データセンターに襲いかかる 仮想化という津波の第二波といえるでしょう。データセンターにおいて、アプリケーション配信コン トローラ（ADC）を仮想化する場合、その役割からサーバを仮想化するのとは異なり、ハードウェ アベースの物理 ADC を単純にソフトウェアベースの仮想 ADC に置き換えるという戦略は、アー キテクチャ上無理があります。しかし、データセンターやエンタープライズネットワークのしかるべ き場所では、従来の物理 ADC に加え仮想 ADC をあわせて導入したり、またスタンドアロンのソ リューションとしても利用することも可能です。この物理 ADC と仮想 ADC の併用モデル－ハイブ リッド型のアーキテクチャであれば従来の高い信頼性や拡張性、性能を損ねることなく、さらに仮 想 ADC の柔軟性を活かしたダイナミックなデータセンターを構築できるようになります。仮想 ADC および物理 ADC による
ハイブリッド型 ADN アーキテクチャの構築
BIG-IP LTM
仮想アプライアンス
の活用
Jun.- 2010 2 アーキテクチャ全体に及ぼす影響はわずかですが、ネットワークアプライアンスの仮想化はネット ワークインフラを構成するコンポーネントが相互に依存している関係上、大きな影響を生じる可能 性があります。場合によっては、従来の物理アプライアンスを単純に仮想アプライアンスに置き換 えることが好ましくない、あるいは技術的に難しい場合もあります。アプリケーションによっては サーバ仮想化に適していないものがあるのと同じように、すべてのネットワークコンポーネントを仮 想アプライアンスに置き換わるべきではありません。このため、組織は最終的に物理アプライアン スと仮想アプライアンスの両方で構成されるネットワークアーキテクチャを構築することになるで しょう。信頼性や運用安定性を犠牲にせずに必要とする柔軟性や拡張性を向上させるには、この ようなハイブリッドのアーキテクチャが必要となるのです。 仮想アプリケーション配信コントローラ（仮想 ADC）の登場により、組織はアプリケーション開発の ライフサイクルのどの時点でも、このソリューションを組み込むことができるようになります。仮想 ADC の導入によってネットワークアーキテクチャを変更する必要はほとんどありませんが、物理ア プリケーション配信コントローラ（物理 ADC）の代替として仮想 ADC をネットワークに組み込むと問 題が起こる可能性があります。 500 人以上の従業員を抱える組織では、ビジネスの俊敏性の向上に基づいて成功を評価する傾向がさらに強まっ ています。
出典： CDW’s Server Virtualization Life Cycle Report（CDW のサーバ仮想化ライフサイクル報告書）、2010 年 1 月
vADC の導入が向いている組織
vADC を導入することで恩恵を受けることのできる組織としては、以下の 3 つが考えられます。 エンタープライズ・データセンター 独立系ソフトウェアベンダー クラウドプロバイダおよびホスティングプロバイダエンタープライズ・データセンターへの導入
ネットワーク管理者およびネットワーク設計者 仮想 ADC がテスト環境や、品質保証（QA）のための検証環境に導入される場合、その恩恵を一番 受けることができるのは、ネットワーク管理者とネットワーク設計者でしょう。サーバ仮想化といっ しょに仮想 ADC を展開することで、組織は物理デバイスに大きな投資をせずに実稼働環境を構築 できます。アーキテクチャのコンポーネントすべてにわたり仮想化を採用すれば、新しいソリュー ションのテストと既存のポリシーの最適化を独立した環境で実施でき、その後本番環境に移行でき ます。Jun.- 2010 3 開発者およびアプリケーション設計者 開発者およびアプリケーション設計者は、アプリケーション配信技術やアプリケーションを統合する ことのメリットは理解しているものの、物理デバイスを準備するにはコストや時間がかかるため、こ のような統合をできずにいます。また、本番環境で稼働している物理 ADC を開発のために使用す ることは推奨されていないため、アプリケーション配信技術の統合についてはほとんど検討されな いままとなっています。仮想 ADC を展開することでこうした技術を使用できれば、開発者がそれぞ れ特定のアプリケーションの設計や導入に併せて、アプリケーション配信プラットフォームが備える 高速化機能、セキュリティ、最適化、カスタマイズを組み込み、これを活用することが可能になりま す。 仮想ネットワークを柔軟で扱いやすいものにするには、ネットワークコンポーネントがプログラム可能であるかという ことが重要です。サービスプロバイダはプログラム可能なネットワークコンポーネントによって、カスタマイズされたプ ロトコルを実装し、多様なサービスを展開できるようになります。したがって設計決定では、「どのくらいプログラム可 能性が認められるべきか」、そして「これをどのように公表すべきか」という問題に対し満足のいく回答ができなけれ ばなりません。
出典： “A Survey of Network Virtualization（ネットワーク仮想化に関する調査）”、2008 年 10 月、著者 N.M. Mosharaf Kabir Chowdhury その他
独立系ソフトウェアベンダー
物理および仮想アプリケーション、そしてネットワークコンポーネントの両方を管理できる管理シス テム、あるいはオーケストレーションシステムがないことで、多くの仮想化モデルやクラウドコン ピューティングモデルの導入が複雑になっています。クラウドコンピューティングや仮想化を導入す るメリットの多くは、オンデマンドのプロビジョニングにより IT プロセスを自動化し協調できることか らもたらされます。仮想 ADC が企業内の開発者や設計者にとってメリットとなるのとほぼ同じよう に、独立系のソフトウェアベンダーにとっても仮想 ADC により費用効果の高いツールを得られます。 管理ソリューションに仮想 ADC を組み込み、それを活用してアプリケーション配信技術がもたらす 新しい手法を活用したアプリケーション環境を構築できます。クラウドコンピューティング環境
クラウドプロバイダやホスティングプロバイダ、そしてそのサービスを利用する顧客は、仮想 ADC を導入した企業以上とはいかないまでも、それと同じくらいの恩恵を仮想 ADC から得ることになり ます。こうしたサービス環境は非常にダイナミックであり、仮想化 ADC にもたらす柔軟性と迅速な 拡張性が必要になります。従来の物理 ADC も柔軟性と拡張性の両方を満たしているものの、何千 もの顧客のアプリケーション配信環境を独立して運用する能力は仮想 ADC ほど高くありません。 クラウドプロバイダとホスティングプロバイダは仮想 ADC を導入して、クラウドベースのアプリケー ションと併せてエンタープライズおよびキャリアクラスのアプリケーション配信技術を顧客が利用で きるようにすることで、競合他社のサービスとの差別化を図ることができます。顧客が自分たちの 仮想 ADC を利用できるようにすれば、プロバイダが物理 ADC を顧客に用意する必要性が軽減さJun.- 2010 4 れます。その結果、クラウドコンピューティングプロバイダのインフラ内で構成およびコンポーネント を独立して運用しなければならないという懸念も軽減されます。 クラウドプロバイダとホスティングプロバイダの顧客は、クラス最高の物理 ADC の機能を仮想アプ ライアンスとして利用できます。あるクラウド環境で提供される仮想 ADC を利用することで、顧客は アプリケーション配信テクノロジーが提供するセキュリティ、可用性、パフォーマンスの機能と切り 離してアプリケーションを移行できるため、そのプロセスはこれまで以上に簡単になります。つまり、 クラウド環境用にアプリケーションを書きなおす必要があるか、それとも単にアプリケーションと仮 想 ADC の両方を導入するかほどの違いがあるのです。アプリケーション配信技術とアプリケーショ ンを一つにまとめることができれば、アプリケーション配信サービスにアクセスするのにプロバイダ に頼る必要がなくなるため、企業はクラウドプロバイダに関してさらに多くの選択肢を得られるよう になります。
アーキテクチャ上の課題
仮想 ADC が既存の物理 ADC に取って代わるだろうと推測するのは、時期尚早かもしれません。 場合によっては単純に置き換えるという戦略もあるかもしれませんが、その影響を考えると、物理 ADC を保持（あるいは入手）し、仮想 ADC を介してその機能を補強することが推奨されます。 最適なアプリケーション配信ネットワークのアーキテクチャでは、物理および仮想の両方のアプリ ケーション配信コントローラを活用することにより必要となる移動性（モビリティ）、拡張性（スケーラ ビリティ）、適合性（アダプタビリティ）を確保し、ダイナミックなデータセンターの構築を可能にしてい ます。柔軟で適合性がありながら、拡張性が高く十分に機能するアプリケーション配信ネットワー クを設計するためのハイブリッドのアプローチは、ネットワーク、あるいはアプリケーション配信ネッ トワークのコンポーネントを仮想化している組織で最も成功を収めています。拡張性（スケーラビリティ）
仮想ネットワークアプライアンスの需要を喚起しているのは拡張性、とりわけオンデマンドで自動 的に拡張できることです。これはこれまでネットワークの容量が足りたくなった時点で、容量の大き な別のデバイスとリプレースするか、あるいは物理 ADC を追加して対応しなければならない制約 からの解放を目指しています。物理的な代替デバイスを調達する時間やインストールなど設置に かかる時間により、重大なサービス停止を招く可能性があります。もし単純に追加の仮想 ADC を 「スピンアップ」して容量不足に対処できれば、より迅速で費用もかからず、シームレスな拡張がで きます。仮想 ADC への拡張はより迅速で低コストですが、よいことばかりではありません。実際、 移行によってネットワークや配信されるアプリケーションのパフォーマンスや安定性に影響を及ぼ すおそれがあるからです。 仮想ネットワークアプライアンスは、複数のインスタンス間でリクエストやトラフィックを分散すること で拡張性を確保するべきと考える人が多いです。これは通常、物理 ADC に期待される役割ですが、Jun.- 2010 5
単純にその役割が物理 ADC から仮想 ADC に移るわけではありません。それは、仮想 ADC はキャ パシティも仮想化されているからです。つまり、仮想 ADC の拡張性のためには、これまでと同じよ うに物理 ADC が必要になります。 スケールアウト 物理 ADC の役割が仮想 ADC に移行できない理由は、ネットワークコンポーネントが他のコンポー ネントを仮想化するからです。つまり、トラフィックはあるデバイス上の複数のインスタンスに分散さ れるのです。完全に仮想化されたアーキテクチャでは、新たな仮想アプライアンスを単にスピン アップすることで、スケールアウトが可能であると考えられています。これにより、アクティブ・アク ティブ（あるいは n-アクティブ）構成が可能になります。この構成では、すべてのインスタンスがトラ フィック／リクエストを積極的に受け付けて処理しています。問題はここにあります。ネットワークの 観点から見ると、このような構成を実装するにはすべてのトラフィック／リクエストが向けられる共 通の MAC アドレスを、すべてのインスタンスが共有しなければならないため、どのインスタンスも すべてのトラフィック／リクエストを受け付けて処理しているのです。その後、どのインスタンスがト ラフィック／リクエストを処理するかを個々のソリューションが決定しなければなりません。このアー キテクチャは本質的に、アップストリームスイッチをハブに変えて、ネットワークトラフィックを複製し ます。ソリューションがスケールアウトされればされるほど、このようなブロードキャスト動作によっ てさらに多くの帯域幅が使用されます。これにより、トラブルシューティングがさらに難しくなるのは いうまでもありませんが、特にクラウドコンピューティングなど可視性がすでに限定されているよう な環境では、ネットワークの容量や性能に悪影響を及ぼす可能性があります。 スケールアップ スケールアップは容量を増やす方法として追加の計算リソースを利用することでネットワークの問 題を解消します。この方法は効果的ではありますが、制限があり、スケールアウトとは異なり、実 装においては従来のネットワークコンポーネントをスケールアップするのと同じくらいサービス停止 の影響が生じます。計算リソースを増やすには、多くの場合新しいハードウェアが必要となり、一 般的なハードウェアと専用ハードウェアとの置き換えに違いはありません。 さらに、スケールアップでは、仮想ネットワークアプライアンスが超えることのできない容量の上限 があります。アドレス可能なメモリに対する制限では、接続指向の「リスト」を内部で維持することに 重点を置くネットワークソフトウェアにより、固有の性能低下が引き起こされることがあり、拡張性 が制約されます。この接続指向の「リスト」は、大きくなりすぎるとアクセスするのに非常に長い時 間がかかります。 仮想ネットワークアプライアンスをスケールアップすることにより、専用ハードウェアとの統合で向 上させた性能や効率性も完全に無効になります。専用ハードウェアで見られるパケット処理エンジ ン、アルゴリズムによる高速化処理、そしてプロトコルの最適化は、一般的なハードウェアに移行 した場合と同じ性能率を達成することはできません。 ハイブリッド型の拡張性
Jun.- 2010 6 物理 ADC と仮想 ADC のどちらを導入するのが適切なのかを判断する場合、その中心的な機能を 決定するというのが重要です。例えばルータや負荷分散など、トラフィック／リクエストを集約し、デ バイスあるいはネットワーク全体に分散させるソリューションの場合、仮想ネットワークアプライア ンスの拡張に伴う課題により、仮想化に適しているとはいえません。次に従うべき指針は、もしソ リューションが物理 ADC によってすでに負荷分散されている場合、仮想 ADC で処理してもやはり 物理 ADC がほぼ確実に必要になるだろうということです。例えばネットワークファイアウォールのよ うなソリューションが現在負荷分散されていないとしても、物理モデルから仮想モデルに移行する 際は、仮想アプライアンスを拡張するため負荷分散ソリューションを実装することが必要になりま す。 これは、本番環境で仮想 ADC を検討する余地がないということではありません。逆に、仮想 ADC は物理 ADC やその他仮想ネットワークアプライアンスを非常にうまく補完します。しかし機能に よっては仮想モデルを導入することはアーキテクチャの面からみて有益ではない場合があります。
適合性（アダプティビティ）
仮想ソリューションを実装するもう一つの理由として挙げられるのが、システムへ柔軟に対応でき る適合性です。確かに、問題に対処するという差し迫ったビジネスや技術上のニーズがある場合、 物理 ADC よりも仮想 ADC のほうがはるかに容易にかつ迅速に展開できます。これは、一時的な 「修正」が必要な場合に特に当てはまります。Web アプリケーションのセキュリティなど、アプリケー ション配信に関連する技術をオンデマンド形式でダイナミックに展開できれば、IT はサービス停止 の影響もほとんどなく、ビジネスや技術的な要求の変化に対応できるようになります。 仮想 ADC を使用して既存の物理 ADC 実装を補強すると、アプリケーション、あるいは部門レベル でのニーズに基づいて機能をさらに分割するのに役立ちます。このように機能を分割することで、 組織内のさまざまなニーズの優先度がぶつかり合うことを防ぐことができます。このアーキテク チャは、クラウドコンピューティングやホスティングプロバイダのアーキテクチャと類似しており、 別々のアプリケーション配信レイヤに展開されている専用あるいは顧客特有の仮想 ADC と物理 ADC を組み合わせることで、マルチテナント型のソリューションが実装されます。移動性（モビリティ）
移動性は、ユーザおよびアプリケーション両方の属性を表すのに使われます。まずユーザにおけ るアプリケーション配信上の課題は、場所、デバイス、ネットワークの状態といったユーザコンテキ ストに基づいて、アプリケーションごとに最適な配信方法を定め、これを実施することです。物理 ADC が導入されている環境では、コンテキストに関する情報は複数のアプリケーション配信モ ジュールで共有することで、適切なアクセスが許可あるいは拒否され、またそのコンテキストに応 じた最適な高速化・最適化ポリシーを適用するようにします。仮想 ADC にも同じ機能がありますが、 プラットフォームとなる物理サーバが単一インスタンスによって同じ機能を展開するのに必要なリ ソースを提供できるかどうかについては議論の余地があります。複数の仮想 ADC を展開することJun.- 2010 7 で機能を分けることは、確かにアーキテクチャ上は理にかなった選択肢ではありますが、このよう な分割をすることで機能全体でのコンテキストを共有できず、データパスでさらに多くの接続（ホッ プ）が必要になることでパフォーマンスの低下を招きます。別々の仮想 ADC インスタンスに機能を 移動させる前に、どの機能がユーザコンテキストへのアクセスを必要としているか、そしてどの機 能がこのようなアクセスを必要としないのか熟慮して判断しなければなりません。 次にアプリケーションの場合、移動性は例えばデータセンターからデータセンターへ、またはクラウ ドプロバイダへと、物理的に異なる場所でアプリケーションを移動することを示します。現在のクラ ウド環境では、物理 ADC の容量の制約上、顧客が利用する環境は仮想 ADC で構築されるのが 一般的と考えられています。高速化、オフロード、スクリプトによるネットワークの統合、セキュリ ティを物理 ADC に依存しているアプリケーションは、クローニングポリシーの実行可能性、そしてあ る環境から別の環境に移行できるアプリケーション特有の「パッケージ」に展開できるのかを検証 する必要があります。
推奨されるベストプラクティス
ダイナミックインフラへ向けて推奨されるベストプラクティスは、アプリケーションのセキュリティ、 Web アクセラレーション、アクセス制御といった複数の高度なアプリケーション配信機能は物理 ADC を主な集約ポイントとして展開し、サーバおよびアプリケーションのオフロード機能を実行、高 いスループットが必要なアプリケーションに対応することです。仮想 ADC は、ネットワークでのスク リプト制御などアプリケーションがさらに複雑な計算処理を必要とする環境で、特定のアプリケー ションの処理を対象とすべきです。この場合、計算リソースを専用にすることで拡張性を持たせる ため、特定の作業負荷に対してのみ処理することが望ましくなります。これらの仮想 ADC は、オフ ロード機能が実行される物理 ADC のバックエンドのレイヤで展開しなければなりません。 さらに仮想 ADC は、迅速な開発や統合をサポートし、カットオーバーまでに要する時間を削減する ため、開発部門や品質保証部門の環境に最も適しています。これらの環境では、ネットワーク、セ キュリティ、アプリケーションのチーム間での連携が仮想 ADC によってさらに強化されます。これは、 投資コストや物理 ADC に関連して発生する運用コストを負担せずに、より幅広い関係者が各種の アプリケーション配信テクノロジーにアクセスしやすいようにすることで実現されます。 その環境ごとの特定のニーズを考慮し、仮想 ADC あるいは物理 ADC を導入するメリットとデメリッ ト、また仮想 ADC と物理 ADC 両方を利用したハイブリッド型のアーキテクチャを採用することのメ リットを評価することが重要です。以下の表に、仮想 ADC と物理 ADC それぞれのメリットとデメリッ トをまとめてあります。この表を参照すると、仮想 ADC あるいは物理 ADC をどのようなときに使用 すべきかを判断するのに役立ちます。Jun.- 2010 8
仮想 ADC アーキテクチャに関する検討
メリット 説明 迅速な展開 仮想 ADC はソフトウェアソリューションとして、物理アプライアンスよりもはる かに迅速に開発プロセスに組み込むことが可能 特定の処理負荷に対する コスト効率 アプリケーションや用途、展開プランによっては、物理アプライアンスはコス ト高になることがあり、企業はその導入をあきらめるか部分的な導入に限 定するかしなければならない。仮想 ADC は、特定のアプリケーションに対し てコスト効果の高い方法で導入可能で、その処理専用のソリューションとな る 障害の分離 あるアプリケーションの問題で、多数のアプリケーションのフロントエンドに ある物理デバイスにトラブルが生じた場合、冗長ユニットにフェイルオー バーする。しかしそうなると、すべてのアプリケーションに影響が及ぶ。仮想 ADC は特定のアプリケーションの処理だけをしているので、こうした不具合 を分離しトラブルの波及範囲を限定できる 管理 ハイパーバイザ・ベンダーの全体的な管理フレームワークに組み込まれる ことで、仮想 ADC の移動と管理を簡略化可能。仮想 ADC を特定のアプリ ケーションと関連づけることは、エコシステムの観点からも重要 デメリット 説明 可用性 専用の物理 ADC で実現したのと同程度の可用性は、汎用サーバハード ウェアでは実現困難 セキュリティ 完全に独立したシステムではなく、共有環境が前提となるため、仮想アプラ イアンスのセキュリティはハイパーバイザ・ベンダーと汎用サーバのベン ダーに依存してしまう 拡張性 高負荷でオフロードが必要なサービスがハードウェアを直接利用できない。 汎用サーバにはオフロード専用の ASIC はない。これらが仮想 ADC の拡張 およびスループットに影響を及ぼす物理的 ADC アーキテクチャに関する検討
メリット 説明 可用性 物理 ADC のハードウェアの設計では、高速なフェイルオーバーと信頼性を 実現するため、キャリアクラスの強化が施されている。冗長コンポーネント （電源、ファン、RAID、内部ハードウェア監視システム）、シリアルベースの フェイルオーバーにより、連続稼働時間と MTBF（平均故障間隔）において 非常に優れた数値を達成している。こうした目的のハードウェアコンポーネ ントはコストがかかるため、ADC ソフトウェアと統合できない セキュリティ ほとんどの物理 ADC アプライアンスはセキュリティが強化されており、ベン ダーが独占所有権を持っている。物理 ADC は他のベンダーのセキュリティ 実装に依存せず、セキュリティ実装が欠如していることもない。ハイパーバ イザの場合、既知の脆弱性、あるいはおそらくは未知の脆弱性が存在す る。このように仮想アプライアンスのセキュリティは、ハイパーバイザ・ベン ダーに依存してしまう 拡張性 物理 ADC のなかには、高性能 L4 処理、SSL、圧縮といった機能向けに独 自の高速ブリッジやオフロード ASIC を備えているものがある。このおかげ で、多くのアプリケーション、特に遅延の影響からサービス品質を守らなけ ればならない高性能／高スループットのアプリケーションは、物理 ADC がコ スト効果の高い集約ポイントとなるJun.- 2010 9 管理 物理 ADC には特別な自動管理機能が備わっており、物理デバイスに障害 が発生した場合アクセス、診断、修正を行うことができる。アプリケーション 配信機能がデータセンター全体に分散されるのではなく、単一のデバイス に集中されているため、管理を簡単に行える デメリット 説明 迅速な展開 物理的な製品の出荷、ラッキング、スタッキング、ケーブル配線に時間がか かり、また設置・稼働のためのコストもかかる。そのためアジャイル開発環 境や品質保証の検証環境には適していない 障害の分離 あるアプリケーションの問題で、多数のアプリケーションのフロントエンドに ある物理デバイスにトラブルが生じた場合、冗長ユニットにフェイルオー バーする。しかしそうなると、すべてのアプリケーションに影響が及ぶ。物理 ADC と仮想 ADC を組み合わせることで、不具合の分離と拡張の両方を同 時に実現できる
