NEC WebOTX ホワイト・ペーパー NEC WebOTX と F5 BIG-IP を適用した、 快適なデータトラフィック インフラ構築の実現 ～ WebOTX WORKS 協業活動による成果 ～ 2007 年 10 月 初版 日本電気株式会社 第二システムソフトウェア事業部 日本電気株式会社 i NEC WebOTX ホワイト・ペーパー 目次 1. はじめに....................................................................................................................................................................１ 2. Webソリューションの最適化................................................................................................................................２ 3. 4. 5. 2.1 WebAccelerator Moduleについて................................................................................................................２ 2.2 検証環境 ..........................................................................................................................................................３ 2.3 検証のシナリオ...............................................................................................................................................４ 2.4 結果..................................................................................................................................................................４ 負荷分散装置制御....................................................................................................................................................６ 3.1 BIG-IP iControl SDKについて.......................................................................................................................６ 3.2 検証..................................................................................................................................................................７ 3.3 まとめ ..........................................................................................................................................................１２ NGNに向けて.......................................................................................................................................................１３ 4.1 実証実験の環境...........................................................................................................................................１３ 4.2 複雑なシーケンスの検証...........................................................................................................................１４ 4.3 スケールアウトの検証...............................................................................................................................１５ おわりに................................................................................................................................................................１８ 日本電気株式会社 ii NEC WebOTX ホワイト・ペーパー 1. はじめに 本ホワイト・ペーパーは、WebOTX WORKS1の活動においてF5 ネットワークスジャパン様と共同で行っ た、NEC WebOTX製品とF5 BIG-IP Local Traffic Managerを適用したインフラ構築の実証実験の報告です。 WebOTX WORKSとは、WebOTXを技術基盤として採用して頂くパートナー様に対し、販促・技術面で体 系的に支援するプログラムのことです。今回は、この活動に基づく共同作業として両社の製品を用いて、以 下の 3 つの検証を行いました。 (1) Web ソリューションの最適化 Web 環境におけるネットワークの最適化とパフォーマンス向上についての検証です。BIG-IP Local Traffic Manager に「WebAccelerator Module」を組み込み、WebOTX Application Server 上で動作する Web アプリケーションの応答速度の変化を計測しています。Web 層には、グループウェア・ポータ ル製品を配置しました。 (2) 負荷分散装置制御 WebOTX Application Server には、稼働中の業務アプリケーションに対して負荷の変動に応じた、適 切なリソースを配分する機能があります。この機能の特徴の中には、負荷分散装置 (ロードバランサ) を動的に制御することで、クライアントからのリクエストを別のホストに自動切換えさせるものがあ ります。ここでは WebOTX Application Server が BIG-IP Local Traffic Manager によって提供される 「iControl SDK」インタフェースを介して、その制御を問題なく協調動作できるかについて検証して います。 (3) NGN に向けて 来たる NGN (Next Generation Network) 時代に向けて、WebOTX では SIP アプリケーション・サー バの提供を始めました。この検証ではトラフィックの多い SIP アプリケーションを想定し、WebOTX SIP Application Server 上で動作する SIP サーブレットを BIG-IP Local Traffic Manager により SIP プ ロトコル負荷分散する検証を行っています。より快適な分散制御を追及するため、BIG-IP で提供され る「iRules」による SIP プロトコル制御を実施しています。 以降の章は、これらの検証試験の詳細な報告です。また、これらの報告は 2007 年 9 月 5 日に行われた F5 ネットワークスジャパン様主催の「F5 Customer Conference 2007」においても行っています。 なお、検証に用いた BIG-IP Local Traffic Manager は、以降の説明では「BIG-IP LTM」と略します。 1 詳細については、http://www.nec.co.jp/WebOTX/works/index.html を参照してください。 日本電気株式会社 １ NEC WebOTX ホワイト・ペーパー 2. Web ソリューションの最適化 Web 技術の進化とともにコンテンツの表現幅はますますの広がりを見せています。それに併せて、配信す る情報の大容量化にも拍車がかかっています。例えば、表現力を増すための手法として、Ajax に代表される ような技術が多用されてきています。また RSS の利用が一般化され、複数の RSS 情報コンテンツを連結し て 1 つの画面に組み込むことも可能になってきています。このような技術は、静的な HTML を表示する場合 に比べて多くの HTTP 通信が発生するため、ブロードバンド環境を前提としていることがほとんどです。一 方クライアントの環境に目を向けてみると、フルブラウザを搭載した携帯電話からのアクセスの急増や、帯 域幅が狭い海外 WAN を経由するアクセスなど、依然として遅延の大きな環境が存在することも事実です。 従って、日々の IT 環境変化に耐えうる広域なサービスを維持するためには、Web サーバの負荷を軽減さ せつつも、なおかつ WAN 経由の通信性能を向上させるという、難しい課題に取り組む必要があります。 この実証実験では、WebAccelerator Module を組み込んだ BIG-IP LTM を利用して、WebOTX Application Server上で動作するWebアプリケーションの応答速度がどのくらい高速化できるかに着目して検証します。 2.1 WebAccelerator Module について WebAccelerator Module は Web ブラウジングの高速化に特化した BIG-IP LTM のアドオンです。 WebAccelerator Module の主要な機能は以下のとおりです。 ・ ダイナミック・キャッシング コンテンツをキャッシュすることにより、Web サーバまでリクエストを伝播することなくレスポンス を返すことができます。 ・ ダイナミック・コンプレッション HTTP 圧縮を動的に施すことで、使用帯域を減らします。 ・ ダイナミック・コンテンツ・コントロール ブラウザのキャッシュの有効性を制御し、不必要な HTTP リクエストを減らします。 ・ マルチ・コネクト Web ブラウザと Web サーバの間で複数のコネクションを張り、複数のコンテンツ(ファイル)を並列 に転送する機能です。 通信速度が 10Mbps 以上もあるようなイントラネット内では、概ね快適な Web アクセスが整います。し かしながら、インターネット・インフラの整備が遅れているような海外地域からアクセスする場合には、低 い帯域の WAN を経由することになります。Web コンテンツを公開する側は、自身のサイト外のインフラに は関与することができないため、性能は WAN 回線側に委ねなければならないジレンマが生じます。このよ うなケースにおいて、自サイトのインフラ側に対して性能課題の解法を提供するのが、WebAccelerator Module です。 日本電気株式会社 ２ NEC WebOTX ホワイト・ペーパー ここでは、この解を検証することを目的として、低速な WAN 回線の環境を構築しました。 2.2 検証環境 検証試験を行った環境について説明します。 クライアントが WAN を経由して WebOTX Application Server 上で動作している Web アプリケーションにアクセスするという状況を想定しています。 ・WebOTX AS ・StarOffice21 (ポータル) ・Webブラウザ WAN (300ms) BIG-IP 6400 (WebAccelerator) ・WebOTX AS (Webサーバ) ・Webブラウザ 社内LAN 図 1 WebAccelerator Module 効果を検証する構成 サーバサイドのネットワークは、前段に WebAccelerator Module を組み込んだ BIG-IP 6400 (v9.4)を設置 し、その背後に Web サーバおよび WebOTX Application Server を設置しています。従って、クライアント が送信した HTTP リクエストは、まず BIG-IP 6400 に到達し、Web サーバを経由して、最後に WebOTX Application Server が受け取ります。WebAccelerator Module の効果を検証することが目的であるため、負荷 分散は行っていません。つまり BIG-IP 6400 のプールに登録する Web サーバは 1 台のみです。 WAN をエミュレートするため、クライアントと BIG-IP 6400 との間には遅延装置を設置しています。遅 延装置へは 300ms の通信速度を発生させるように設定しています。 WebOTX Application Server上で動作するWebアプリケーションとして、NECのビジネスポータル製品で ある「StarOffice21/らくらく情報共有ポータル2」を使用しています。この製品は、グループウェア、ポータ ル、ディレクトリ機能をオールインワンで提供する、Webブラウザ・ベースの統合コラボレーティブアプリ ケーション環境です。この製品はWebOTX Application Serverのサーブレット/JSPコンテナを動作基盤とし ています。この製品を選定した理由は、私達が普段よく利用するビジネスポータルを検証試験の環境に採用 することで、より実社会に即した状況下での結果を得ることにあります。 2 StarOffice21 の詳細については、http://www.nec.co.jp/gw/ を参照してください。 日本電気株式会社 ３ NEC WebOTX ホワイト・ペーパー 2.3 検証のシナリオ 検証のシナリオは、Web ブラウザを利用したビジネスポータルの一般的な操作を想定しています。まずロ グイン画面を表示し、ログイン処理を行った後にメイン画面に遷移します。その後、別の画面に二度遷移し ます。そして各々の画面において、何らかの操作をすることによって Web サーバへリクエストを送信して から画面表示が完了するまでの時間を計測します。この試行を WebAccelerator Module の有効/無効を切り替 えて実施し、それぞれの結果を比較します。 図 2 性能を検証する、対象ポータル画面の遷移 ただし、Web ブラウザがキャッシュを持っているかどうかにより性能に大きく差が出るため、キャッシュ を持っていないパターン(初回アクセス)と、既にキャッシュを持っているパターン(繰り返しアクセス)の 2 つ のパターンで性能を測定しています。 2.4 結果 まず、Web ブラウザがキャッシュを持っていないパターンの結果を、以下のグラフに示します。 WebAccelerator Module を有効にすることで全ての画面表示が高速化できたことが読み取れます。最も高速 化できたのはメイン画面の表示で、1.97 倍の改善結果を得ました。 初回アクセス ログイン メイン画面 画面切替1 画面切替2 (秒) 0 5 10 WebAcceleratorあり 15 20 WebAcceleratorなし 図 3 初回アクセス時の各画面の表示性能 日本電気株式会社 ４ NEC WebOTX ホワイト・ペーパー 初めてアクセスした際、Web ブラウザは Web アプリケーションに関する特性情報を何も持ち合わせてい ません。それにも関わらず高速化できた大きな要因は、WebAccelerator Module がキャッシュ(ダイナミッ ク・キャッシング)と圧縮(ダイナミック・コンプレッション)を行って、HTTP 通信を最適化した結果と考え られます。 次に、Web ブラウザがキャッシュを持っているパターンの結果を、以下のグラフに示します。キャッシュ が存在するために、WebAccelerator Module を無効にした状態でも前述の初回アクセスより十分高速です。 WebAccelerator Module を有効にした状態では、さらに全ての画面表示で高速化できたことが読み取れます。 最も高速化できたのはログイン画面の表示で、2.54 倍でした。 繰り返しアクセス ログイン メイン画面 画面切替1 画面切替2 (秒) 0 2 4 WebAcceleratorあり 6 8 WebAcceleratorなし 図 4 2 回目以降の繰り返しアクセス時の各画面の表示性能 WebAccelerator Module による Web Web ブラウザがキャッシュを持っている状態でも高速化できたのは、 ブラウザのキャッシュの制御(ダイナミック・コンテンツ・コントロール)により、不必要な HTTP 通信が大 幅に減少した結果だと考えられます。 「StarOffice21/らくらく情報共有ポータル」はビジネスポータルという性質上、一画面中のオブジェ また、 クト(画像などのコンテンツ)が比較的多い構成になっています。このような画面でも高速化できたのは、オ ブジェクトを並列ダウンロードできるようにWebAccelerator Module が複数のコネクションを制御している (マルチ・コネクト)ためだと考えられます。 日本電気株式会社 ５ NEC WebOTX ホワイト・ペーパー 3. 負荷分散装置制御 WebOTX Application Server V7.1 Enterprise Edition は、グリッド技術を応用した Working Domain Coordinator という機能を持っています。Working Domain Coordinator は、負荷が高くなった業務に対し、 負荷の低い業務で余っている処理能力(サーバ)を動的に割り当てることで、過負荷の状態を解消します。 Working Domain Coordinator は、高負荷の業務を検知すると、次に示す動作をします。説明の便宜上、高 負荷になった業務を「業務 A」 、低負荷の業務を「業務 B」とします。 (1) 業務 B を実行しているサーバの一部を BIG-IP LTM から切り離す (2) 切り離したサーバ上で実行している業務を、業務 B から業務 A に切り替える (3) そのサーバを BIG-IP LTM に再登録する 図 5 Working Domain Coordinator の動作概念 上記手順の(1)と(3)では、Working Domain CoordinatorがBIG-IP LTMを制御する必要があります。そこで、 WebOTXはBIG-IP LTMを制御するための手段として、BIG-IPが提供しているiControlというAPIを利用してい ます。3 3.1 BIG-IP iControl SDK について BIG-IP では、負荷分散装置に各種の設定を行うために「BIG-IP iControl SDK」というオープンな開発キッ 3 iControl が提供するインタフェースを介した BIG-IP 装置の自動制御機能は、WebOTX V7.1 の次のバージョンで正式にリリースする予定 です。 日本電気株式会社 ６ NEC WebOTX ホワイト・ペーパー トが提供されています。BIG-IP iControl SDK の各種設定は、SOAP 通信による Web サービスを用いて制御 します。 BIG-IP iControl SDK のオペレーションには BIG-IP コントロール用に様々なものが用意されています。 WebOTX Application Server が行う振り分け制御では、振り分け先アプリケーションの追加、同削除、およ び、振り分け先アプリケーションの論理グループであるプール名を取得するオペレーションを使用します。 3.2 検証 (1) 設定 実際の BIG-IP LTM を用いた振り分け制御の設定には、WebOTX Administrator 製品に含まれる統合運用 管理ツールを使用します。このツールは BIG-IP LTM との連携設定において、親和性の高いパラメータ 入力フィールドを備えています。それによって、簡単な設定操作でサーバの切り離しや再登録を行うこ とができます。 図 6 統合運用管理ツールのBIG-IP LTM制御設定の画面例4 (2) 負荷分散 次に Working Domain Coordinator がどのようにして高負荷業務の負荷を平準化するのかを検証してい きます。 4 本画面は開発中のイメージです。将来の正式リリース版では変更される可能性があります。 日本電気株式会社 ７ NEC WebOTX ホワイト・ペーパー (3) 構成図 以下に検証の対象となる環境を示します。COMPUTER1 から 3 が負荷分散制御の対象のマシンです。 それぞれCOMPUTER1では業務A、 COMPUTER2と3では業務Bが稼動中です。 また、 Working Domain Coordinator がこれらの 3 台の COMPUTER の負荷監視を行っています。ここでは業務 A にクライアン トからのアクセスが集中し、高負荷状態になることが予想されると仮定します。 図 7 Working Domain Coordinator と BIG-IP LTM の制御概略 以降、WebOTX の運用管理画面を参照しながら COMPUTER1 から 3 の状態を説明します。 なお、運用管理画面の状態の流れは、WebOTX の Web サイトで Flash 動画としても公開中です。次の URL をご覧ください。(http://www.nec.co.jp/WebOTX/download/info.html#20070905f5cc) 日本電気株式会社 ８ NEC WebOTX ホワイト・ペーパー ① 定常状態：実行中のドメインの AP 層キュー滞留数が 0 であり、すべての業務が定常状態であることが 分かります。 図 8 定常状態における統合運用管理ツールの表示 ② 高負荷発生：業務 A に対してアクセス(高負荷)を発生させると、COMPUTER1 の domain11 の AP 層 キュー滞留数が上限値 15 を超えて 20 となり、業務 A が高負荷状態になったことが分かります。 図 9 負荷上昇時における統合運用管理ツールの表示 日本電気株式会社 ９ NEC WebOTX ホワイト・ペーパー ③ 高負荷検出：業務 A が動作する COMPUTER1 の domain11 のキュー滞留数 20 に変化がなく、業務 A の継続的な高負荷状態を検出したことが分かります。 図 10 負荷上昇の検出時における統合運用管理ツールの表示 ④ ドメインの切り替え (その 1)：COMPUTER2 と 3 を比較してより負荷の低い COMPUTER3 を選択し て、業務 B が動作している domain32 を停止します。 図 11 初期のドメイン切り替え制御時における統合運用管理ツールの表示 日本電気株式会社 １０ NEC WebOTX ホワイト・ペーパー ⑤ ドメインの切り替え (その 2)：COMPUTER3 で domain31 を起動し、業務 A が実行中の状態になっ たことが分かります。 図 12 ドメイン切り替え制御の完了時における統合運用管理ツールの表示 ⑥ 高負荷状態の解消：クライアントからの業務 A に対するアクセスが COMPUTER1 の domain11、お よび COMPUTER3 の domain31 に分散され業務 A の高負荷状態が解消されたことが分かります。 図 13 制御処理が完了したことを確認する統合運用管理ツールの表示 日本電気株式会社 １１ NEC WebOTX ホワイト・ペーパー 3.3 まとめ WebOTX は、BIG-IP iControl のアプリケーション・プログラミング・インタフェースを利用できたことで、 理想的な分散制御の実現手段を備えることができるようになりました。それらの要素には、多くの利点を挙 げることができます。 まず、運用管理者に対する利点は、運用操作の簡易性をもたらすことです。WebOTX Application Server と BIG-IP LTM を SOAP で接続するための必要パラメータは、画面ツールによって直感的に分かりやすい入 力インタフェースを供給することができました。このことは、運用者に対して複雑なインフラ知識を要求す ることなく、簡単な設定操作だけで負荷分散装置とアプリケーション・サーバを絡めたミッションクリティ カル運用環境を実現することを示唆しています。 一方、WebOTX 側の利点としては、Working Domain Coordinator が業務アプリケーションの過負荷を検 知した時点から、迅速に BIG-IP LTM 負荷分散装置の制御を実施して、サーバ全体を安定稼動に導ける点を 挙げることができます。従来の Working Domain Coordinator における負荷分散装置制御は、各負荷分散装置 ベンダーが公開する専用コマンドを WebOTX の運用管理ツールへ指定する方式のみでした。この場合、 Working Domain Coordinator は、指定のコマンドを外部呼出しすることで処理します。外部コマンドの起動 には、必ずオーバーヘッドが生じます。さらに、ベンダー専用コマンドを指定する手段は、運用者がコマン ド・インタフェースをスタディしなければならないことを意図し、負担が増えます。さらに、指定したコマ ンド・インタフェースの入力ミスなどの人間系ミスを引き起こす可能性が高くなります。 以上の効果を WebOTX が BIG-IP iControl から得られたのは、先の検証項目で示したとおりです。すなわ ち、運用管理者は簡単な設定操作を行うのみで Working Domain Coordinator と BIG-IP LTM を連携動作させ ることができたこと、Working Domain Coordinator は負荷が高い業務を自動的に検出し、負荷が低い業務を 負荷が高い業務に切り替えることが可能であることを確認することができました。 日本電気株式会社 １２ NEC WebOTX ホワイト・ペーパー 4. NGN に向けて NGNではSIP5 (Session Initiation Protocol) というプロトコルに基づいて呼制御を行っています。呼制御と はIP電話や動画のストリーミング等のセッションを開始したり、切断したりするもので、まさにNGNにおけ る通信の基盤と言えるプロトコルです。 WebOTX SIP Application ServerはSIP Servlet API6をサポートしており、SIPに対応したアプリケーション を開発・実行することができます。例えば、IP電話のようなリアルタイム通信の特性を活かしたWebベース のサービスや、WebアプリケーションからSIP端末を制御するシステム等を容易に開発することができます。 またNECが参加するNGNフィールドトライアルでは、小売店支援システムの基盤としてWebOTX SIP Application Serverが採用されています。 図 14 WebOTX が参加する、NGN フィールドトライアル実験 今回は SIP を取り扱う大規模なシステムを想定しながら、負荷分散装置として BIG-IP 8400 を採用した際 の有効性について検証を行いました。以下ではその詳細について説明を行います。 4.1 実証実験の環境 SIP の負荷分散する目的で BIG-IP LTM を企業などが導入する場合、BIG-IP LTM と WebOTX SIP Application Server を企業の内部 LAN に配置し、WAN 側に位置する SIP 端末と LAN 側の SIP 端末が通話す ることが最も多いと考えられます。実証環境は同一 LAN 内ではありますが、2 つの SIP 端末を WAN 側にあ るものと仮定して、実際のユーザ環境で使用される構成を想定して試験を実施しました。 実証試験環境で使用した設備を以下に示します。 5 6 RFC 3261 (http://www.ietf.org/rfc/rfc3261.txt) で基本仕様が規定されています。 JSR 116 (http://jcp.org/en/jsr/detail?id=116) で仕様が規定されています。 日本電気株式会社 １３ NEC WebOTX ホワイト・ペーパー 図 15 WebOTX SIP Application Server と BIG-IP LTM の構成 項番 1 項目 機器名称 WebOTX SIP Application Server 7 数量 Express5800 2 2 SIPソフトフォン (X-Lite ) ノート PC 2 3 SIP 端末 (NEC TE25-A) NEC 製 SIP 対応電話機 2 4 負荷分散装置 BIG-IP 8400 1 BIG-IP LTM に対する設定として必要な項目を以下に示します。 ・ BIG-IP LTM のプールには、 WebOTX SIP Application Server を必要台数登録します(本環境では 2 台)。 ・ 通信を処理するバーチャルサーバを設定します。 ・ WebOTX SIP Application Server との間でSIP のメッセージを適切に送受信するためのiRule をバー チャルサーバに適用します。 ・ SIP パーシステンスを有効にします。 4.2 複雑なシーケンスの検証 SIP のメッセージシーケンスの中で最も重要なレジスト制御と呼制御が問題なく動作することを確認しま した。これらが問題なく動作することで、この他の多くの SIP メッセージは問題なく動作するものと判断で きます。 7 X-Lite は、CounterPath Solutions Inc. (http://www.counterpath.com/) からダウンロードできるフリーソフト。 日本電気株式会社 １４ NEC WebOTX ホワイト・ペーパー 大項目 レジスト制御 中項目 端末立ち上げ試験 検証内容 結果 BIG-IP LTM の外側の端末が WebOTX に対して登録さ OK れることを確認する。 呼制御試験 正常試験 BIG-IP LTM 間で発信／着信試験を行う。 OK 準正常試験 BIG-IP LTM 間で発信／着信のキャンセル試験を行う。 OK 異常試験 BIG-IP LTM 間で発信／着信の異常系試験を行う。 OK 実際のSIPメッセージの流れは「図 16 シーケンス検証でのSIPメッセージの流れ」のようになります。 図 16 シーケンス検証での SIP メッセージの流れ SIP端末(図 16では左側のX-Lite(B) )からのSIPリクエストメッセージは、BIG-IP LTMに設定した仮想IPア ドレスに対して送信され、BIG-IP LTMがこれを受け取ります。BIG-IP LTMは、iRulesに従い、SIPリクエス トメッセージをWebOTX SIP Application Server(C)に送信します。WebOTX SIP Application Server(C)は、こ のメッセージをプロキシし、TE25-A(E)に送信します。TE25-A(E)が返すSIPレスポンスメッセージは、この 逆のルートを通り、BIG-IP LTMを通してX-Lite(B)に返されます。 SIP端末(図 16では右側のX-Lite (F) )からのSIPリクエストメッセージは、BIG-IP LTMに設定した仮想IPア ドレスに対して送信されます。BIG-IP LTMは、iRulesに従い、SIPリクエストメッセージをWebOTX SIP Application Server(D)に送信します。WebOTX SIP Application Server(D)は、このメッセージをプロキシし、 WAN側のSIP端末TE25-A(A)に送信します。TE25-A(A)が返すSIPレスポンスメッセージは、この逆のルート を通り、BIG-IP LTMを通してX-Lite(F)に返されます。 4.3 スケールアウトの検証 BIG-IP LTM に新たな WebOTX SIP Application Server を追加することで、スケールアウトが実現できるこ とを検証しました。 日本電気株式会社 １５ NEC WebOTX ホワイト・ペーパー SIP は、SIP 端末間のセッションを制御するプロトコルであり、電話の会話データなどは SIP 以外のプロ トコルで送受信されるため、ブラウザが使用する HTTP に比較すると、実運用での SIP のメッセージの送受 信回数は少ないと言えます。しかし、SIP では、1 回のセッション確立時に、SIP 端末間でメッセージが数 回送受信されます。そのため、SIP を利用する場面においても、大量の SIP のメッセージ処理のため SIP サ ーバに負荷が掛かることが考えられます。そのとき、BIG-IP LTM のプールに新たな WebOTX SIP Application Server を登録することで、SIP 端末の設定変更などを行うことなく、スケールアウトが可能となります。 発呼側 着呼側 性能試験ツール (クライアント1) WebOTX SIP Application Server 性能試験ツール (クライアント2) WebOTXを追加 WebOTX SIP Application Server 図 17 スケールアウト検証環境の構成 スケールアウト検証環境の構成を「図 17 スケールアウト検証環境の構成」に示します。性能試験ツー ルにはSIP検証用として定評のあるフリーソフト「SIPp 2.08」を使用しました。図中の左側に位置する 2 台 のクライアントPC上でSIPpを実行し、SIPリクエストの「INVITE」と「BYE」メソッドを繰り返し送信し ます。WebOTX SIP Application Serverは、SIP端末として動作し、 「INVITE」や「BYE」を受け取ると、 「200 OK」 レスポンスを返します。 SIPpからのINVITEに対する200 OKがWebOTX SIP Application ServerからSIPp に返されたとき、ひとつの呼(Call)が成立したことになります。 5.38 クライアント1 9.79 WebOTX 1台 WebOTX 2台 10.29 クライアント2 15.48 (Call/Sec) 0 5 10 15 20 図 18 スケールアウトによる性能の変化 8 SIPp は、http://sipp.sourceforge.net/ からダウンロードできるフリーソフト。 日本電気株式会社 １６ NEC WebOTX ホワイト・ペーパー 結果を「図 18 スケールアウトによる性能の変化」に示します。クライアント用のPCのスペックに違い があるため、クライアント 1 と 2 の性能値は同じ値にはならないことに注意してください。WebOTX SIP Application Serverを 1 台から 2 台にスケールアウトしたとき、クライアント 1 では、1.8 倍、クライアント 2 では、1.5 倍性能が向上しています。クライアント 1 と 2 の合計では 1.6 倍になります。 この結果から、BIG-IP LTM に登録する WebOTX SIP Application Server の数を増やすことにより、利用者 の SIP 端末への設定変更の必要もなく、スケールアウトを容易に問題なく行えることが確認できました。 日本電気株式会社 １７ NEC WebOTX ホワイト・ペーパー 5. おわりに WebOTX WORKS がアプリケーション・サーバ分科会のような形で活動を始めて、1 年が過ぎました。こ のホワイト・ペーパー執筆時点で参加して頂いたベンダーが、まもなく 30 社に迫ろうとしています。その 間、WebOTX 製品関係者は多くのベンダーの方々の新鮮なアイディアに触れる機会が与えられ、そこからコ ンピュータ・ソフトウェアを取り巻くインフラ・システムへ携わっているステークホルダーの裾野の広さに、 再認識させられる場面に多々遭遇できました。 このことは WebOTX 製品関係者にとって貴重な財産であります。と同時に、その財産をいかにたくさん WebOTX WORKS パートナーをはじめとする全てのエンドユーザに、WebOTX が持てる能力をプラスアル ファしながら還元できるかを見つめなおす日々でもありました。 WebOTX アプリケーション・サーバの典型的な用途は、サーブレット/JSP を中心にした Web システムの 実行基盤にあります。それゆえに、ソフトウェア・ベンダーと関わることが多いのですが、今回の F5 ネッ トワークジャパン社様との縁は、負荷分散装置を主軸にするベンダーとあって、第三の方向において大いな る発展をもたらす形となりました。 従来の WebOTX アプリケーション・サーバでは、Web コンテナや EJB コンテナ、JMS サーバ、トラン ザクション・サービス、RMI-IIOP 通信などの自らが提供するホワイト・ボックスの範囲でひたすら性能強化 に努めていました。そのような中、BIG-IP LTM が提供する WebAccelerator Module への出会いは、ひとつ の衝撃でありました。つまり、IT システムとは単一アプリケーション・サーバだけで高性能化に貢献できる のではなく、優れた負荷分散装置などを含めたトータルで高性能システムが成り立つものだと体感した訳で す。 同様の意識は、WebOTX の Working Domain Coordinator 機能にもありました。WebOTX の Standard / Enterprise Edition は、競合他社に追従を許さない、ユニークな高信頼 TP モニタ・システムを備えています。 WebOTX の中で稼動している業務アプリケーション群に対して、 変動する負荷状態に即応して多重度を自律 調整することで、複数の業務アプリケーションの中からピンポイントで並列動作させるべき対象を抽出する ことができます。さらに、クライアントからのリクエストは TP モニタ内のリスナを通過する訳ですが、リ ナスの中で待ち行列に収容されているリクエスト・キーの中から、業務アプリケーションへ事前定義された 優先度や負荷変動状態に基づいて、最適な順序への並び替えや流量の制御をする機能も備えています。 これらは、いわばアプリケーション・サーバ内、ロードバランサのようなものです。WebOTX は、さらに 一段上を行く高信頼の実現手段を模索していました。そこから生み出されたものが、アプリケーション・サ ーバ自体がネットワーク上に点在する負荷分散装置までも制御の対象とすることで、業務アプリケーション を他の WebOTX ドメインへシームレスにプロビジョニングを実現しようという発想です。それが、Working Domain Coordinator です。実は、WebOTX は Working Domain Coordinator 機能を組み込む設計段階で、負 荷分散装置の内部インタフェースをコールできれば、より柔軟な機能に仕上がるのではないかと考えていま した。そんな最中に BIG-IP iControl に出会った訳であり、まさに運命的に導かれた感覚を得ました。 WebOTX の Working Domain Coordinator による BIG-IP LTM 制御の効用については、ホワイト・ベーパ ーの中で説明したとおりです。WebOTX と BIG-IP との組み合わせは、親和性に優れていると言っても過言 ではありません。 日本電気株式会社 １８ NEC WebOTX ホワイト・ペーパー もう 1 つ、WebOTX 製品と BIG-IP との関係において親和性をより強固にする検証試験を行いました。そ れが、WebOTX SIP Application Server を適用した SIP リクエストの負荷分散試験です。 今や、クラスタ化された Web アプリケーション・サーバ環境において、HTTP/HTTPS リクエストを負荷 分散装置で振り分けさせることは定常的に行われています。現在、ネットワーク分野でホットに話題を集め ているものに NGN があります。近い将来、NGN が商用化されると、それまでの IT システムに SIP の活用 場面が一気に押し寄せてくると予想しています。IT とキャリアが融合されると、HTTP サーブレットと SIP サーブレットを統合したアプリケーション構造に注目されていくでしょう。 WebOTX SIP Application Server は、Web/SIP 統合型コンテナを装備する J2EE アプリケーション・サー バとして、HTTP と SIP のサーブレットが 1 つのアプリケーション・モジュール単位で実行する機能を提供 しています。この形態のアプリケーションを企業システムに適用した場面を想定してみましょう。HTTP サ ーブレットへは、HTTP/HTTPS プロトコルでリクエストが到着します。アプリケーション・サーバには負 荷分散装置を設置するでしょう。一方、SIP サーブレットへは SIP/SIPS プロトコルでリクエストが到着し ますので、HTTP サーブレットと同様に負荷分散装置でクラスタリングしたいと考えるのは自然なことです。 ここでシステム構築技術者は、現在採用しようとしている負荷分散装置が SIP プロトコルの分散でも実績 があるのか? あるいは、周辺の SIP 端末・装置・サーバとの接続実績があるのか? などの「実績」を気に されることでしょう。このホワイト・ペーパーや WebOTX の情報を見た方ならば、 「WebOTX SIP Application Server と BIG-IP LTM ならば実証済み」ということが理解できることでしょう。 このような安心感を利用者に伝達することも WebOTX WORKS 活動の大きな役割でもあります。その 1 つの成果である、F5 ネットワークスジャパン社様との協業作業が、皆様のアプリケーション・サーバ分野の ソリューションとして一助になれば幸いです。 ご案内 F5 ネットワークスジャパンについては、WebOTX WORKS のパートナー紹介サイト http://www.nec.co.jp/WebOTX/works/partner_f5.html をご覧ください。 日本電気株式会社 １９