要点
様々なバージョンのデータ・サービスについて記した多くの記事が出回っていますが、どのバージョンを選んだらいいのかを明確に示した記事は見当たりません。同様にエンドポイントやチャンネルがアプリケーションの性能にどのように影響を与えるのかについて詳細を記した記事も見当たりません。
Adobeでは4つのバージョンのデータ・サービスを挙げているものの、それらは大きく2つのバージョンに分けられます。一つはオープン・ソースのBlaze Data Servicesでもう一つはLiveCycle Data Services(LCDS)と呼ばれるプロプライエティ版です。どちらの製品もメッセージ仲介サーブレットを通してFlexとJavaとの間の接続を確立するという最も重要な機能を提供しています。どちらもリモート・プロシージャ・コールと、ActionScript Message Format (AMF) と呼ばれるバイナリ・プロトコルを通したメッセージングを使ってサーバと通信を行います。Adobeではこれら2つの中心的な製品の上にサポートを付加したバージョンや拡張機能を含むスイーツ製品を提供しているのです。
Gorilla Logicにおける私達の経験ではこれら2つの製品間の主な違いはサポートの有無とデータ・マネジメント＊機能です。性能と拡張性の違いについては議論の余地があります。LCDSは追加的なエンドポイントやクライアント通信のためのチャンネルを提供しています。Adobeはこれら追加機能の主な優位性は改善された拡張性にあると公言しています。ところが通信の基本的な手段はどれもHTTP上のAMFなので、サーバやクライアントの設定に依らず同じ性能なのです。
LCDSが提供する別の付加機能はデータ・マネジメント＊です。この機能はFlexで作られたクライアントとJavaで作られたサーバ・アプリケーションの間でリアル・タイムによる競合を回避しながらデータを同期する処理を提供します。さらにJDBCやHibernate、その他のアダプタ＊を通した永続化機構へデータ・サービスを接続するためのアセンブラやアダプタ＊も提供します。
では、4つのバージョンとはどのようなものでしょうか。
- Blaze Data Services - 無償で使えるオープン・ソース版
- LiveCycle Data Services Community Edition - サポート付きのBlaze DS
- LiveCycle Data Service Single-CPU License - 付加機能を持った商用版の無償バージョンでシングルCPUに限定されている
- LiveCycle Data Services - サポートの付いた有償の商用版
AdobeがLiveCycle Data Services Enterprise Suiteと呼ぶスイーツ製品もあります。この製品には中心となるデータ・サービスにいくつかの製品を追加しコンテンツ・サービスやPDF Generation、Forms、そしてDigital Signaturesといったツールを使ったドキュメント出力出来るようになっています。
こうして見ると、論理的に考えて主に以下の三つの着眼点から(どの製品を選択するかという)判断をすることになります。
- サポートが必要でしょうか。(作成する)アプリケーションが、例えばミッション・クリティカルなアプリケーションのようなサポートを必要とするアプリケーションであるかどうかということです。
- データ・マネジメント・サービス＊が必要でしょうか。(作成する)アプリケーションがデータの同期処理やマネジメント・サービスを必要とするかどうかということです。
- LCDSの提供する追加的なエンドポイントやチャンネルが必要でしょうか。Adobeによると同時接続数百を超える可能性がある場合にはLCDSの追加的なエンドポイントやチャンネルが必要になるとのことです。但し、これについては議論の余地があります。サーバが処理することの出来る同時接続数は、例えばスレッド数やI/Oのスループットなどいろいろな要素に依存します。またJavaのアプリケーション・サーバをスケールアウトするように、複数のサーバに対してロード・バランスをすることで大量の同時接続を処理することも出来るのです。
この記事の最後にある比較表は異なるバージョン間の概要を示しています。
それぞれのエンドポイントの概要 - ServletとNIO
データ・サービスにおけるエンドポイントとはサーバがクライアントからの接続を監視する方法のことです。Blaze DSとLCDSの両方における標準のエンドポイントはアプリケーション・サーバ上で動くサーブレット・ベースのエンドポイントです。これはweb.xmlで設定されたメッセージ仲介サーブレットを使うもので、通常のサーブレット・チェーンの一部に含まれます。これによってBlaze DSやLCDSは既存のJavaアプリケーション・サーバ上にデプロイすることが出来るのです。他のJavaサーブレットによるエンドポイントと同様にクライアントからの接続一つずつに対してサーバ上では別々のスレッドが必要となります。
NIOエンドポイントはまったく別の動きをします。NIOとはJava New Input / Output（Javaの新しい入出力）を意味します。NIOエンドポイントはスタンドアロンで稼働するNIOベースのソケット・サーバを生成します。NIOの利点は一つのスレッドが複数の入出力ストリームを管理することが出来るのでより少ないスレッド数でより多くの数のクライアントをさばけるという点です。
NIOを使う際に問題となる点は以下のようなものです。:
- クライアントはクライアント側のプロキシを通してNIOエンドポイントにアクセスすることが出来ません。
- (NIOエンドポイントとの)接続は標準のサーブレット・チェーンを通らないので、システム内でサーブレットの処理に依存している部分は破綻する恐れがあります。例えば私達はあるプロジェクトでサーバにファイルをアップロードするのにサーブレットを使いました。
- NIOを使う際には通常、独自の認証機構を使う必要があります。なぜならばソケット・サーバはサーブレット・コンテナとは別のプロセスで実行されるからです。
NIOサーバは80番ポートを監視するように設定することも出来ますが、通常は別のポートを使います。これによってネットワーク設定に問題が生じます。というのも新しいポートに対する入力を受け付けるようにネットワークを設定する必要があるからです。このことはサーバが置かれているネットワークと別のネットワークにあるクライアントの状態によっては問題となり得ます。この問題に対してはsticky sessionを使ったロード・バランサを利用することで対応できる可能性があります。
しかしJava NIOの優位性については議論の余地があります。Java NIOは一つのスレッドで複数の接続を処理するために開発されました。一つのスレッドがコネクション・プールを巡回し読み取りや書き込みをする必要のある新たなデータがないかどうかをチェックすることでこの目的を達成しています。NIOは2002年にJava 1.4で提供されたもので、JVMやLinuxにおけるスレッド処理はその時点から劇的に改善されました。JavaやLinuxで扱うことの出来るスレッドの量は劇的に増加したのです。
例えばLinuxカーネルは2.6で新たなスレッド処理ライブラリを提供しました。これはNative POSIX Linux Thread Library (NPTL)と呼ばれるものです。NPTLのテストによるとIA-32上で100,000コのスレッドを立ち上げるのに要する時間は2秒です1 。NPTLがない場合、Linuxカーネルで同じ数量のスレッドを生成するのに15分かかります。
最も興味深いのはPaul Tyma氏と他の人たちによるブログへの投稿で、実際にはJava NIOによって不利になるという議論に関するものです。一連のベンチマークを通してPaul氏はNIOに関する以下の点について示しました。:
- Java NIOは20％から30％スループットが落ちる
- スレッド・コンテキストの切り替えは高価な処理ではない
- 同期処理は高価な処理ではない
これらのテスト結果を基にPaul氏は1コネクションに1スレッドという方法は拡張性があることを示しました。JDK 1.6を使うとJVMは15Kから30Kのスレッドを処理することが出来ます。これはつまりサーブレット・エンドポイントの限界は数百程度の接続数ではないということを意味しています。もっと多くて、15Kを超える接続数なのです。実際の限界数は、メモリやCPUといったハードウェアの設定にも依存します。
異なる種類のチャンネルに関する概要
基本的なネットワーク接続ではクライアントとサーバ間の通信に多くの異なる種類のチャンネルを使うことができます。通常のリモート・プロシージャ・コールでは標準のAMFチャンネルが使われます。
別の通信方法としてメッセージングがあります。この方法を使うとサーバ側からメッセージをプッシュする疑似リアルタイム通信を実現することができます。例としてチャット(システムの)サーバ、オークション(システムの)クライアント、そしてコラボレーション・サービス＊などのアプリケーションが挙げられます。
データ・サービスがメッセージングをする主な方法はポーリングを使った方法です。HTTP上の標準的な通信では通信チャンネルを開放し続けておくことはないので、ポーリング用のチャンネルがサーバ側でデータの準備が整うまでクライアントの要求を保留しておきます。待ち時間は数ミリ秒から数分まで調整出来ます。この仕組みによってサーバ側からデータがプッシュされているように見せることが出来るのです。
二種類の基本的なポーリング用のチャンネルがあります。短期のポーリングと長期のポーリングです。両者の主な違いはサーバ側がクライアント・データの準備が整うまでどれだけの時間待つかという点になります。
さらに進歩的なチャンネルはストリーミングAMFです。これはサーバに対してHTTP接続を開放することでサーバが絶えずメッセージを送信することを可能にするものです。この方法にはクライアント側からポーリングするオーバーヘッドがなくなるということと標準的なネットワーク設定を使うという利点があります。疑似リアルタイム・ストリーミングとしてはこの方法が最も精密でしょう。ストリーミングAMFの問題はブラウザ間での実装が異なるHTTP 1.1のKeep Alive機能を使っているという点です。
最後の一種類のチャンネルはRMTP（real time messaging protocol）チャンネルで現在はLiveCycle DSでしか使えません。Adobeは最近RTMPの仕様を公開すると発表しました。恐らくは他の製品でも使えるようになって行くものと思われます。
RTMPは大きなサイズのマルチ・メディア・データやデータを二重のチャンネルを使ってストリーミング配信するために設計されました。RTMPの一つの利点はクライアントとの接続が開放されたままなのでサーバからデータをプッシュすることが出来るという点です。これによってRTMPはCometスタイルの通信やリアル・タイムでのデータ・プッシュに使うことが出来るのです。
RTMPには3種類あります。一つ目はTCP上で機能するもので1935番ポートを使います。この種類のRTMPのマイナス面はクライアントのブラウザ側から接続を開始しなければならないということです。さらに標準でないポートを使うので、しばしばクライアント側のファイアーウォールでブロックされてしまいます。
他の2種類のRTMPはRTMPのメッセージをHTTPリクエストでカプセル化したものです。このことでRTMPはファイヤーウォールを通過し、通常のポートを使うことが出来るようになります。2種類とは普通のHTTPを利用するRTMPTとセキュアなHTTPSを利用するRTMPSのことです。
Flexではサーバに対する全ての呼び出しは非同期に処理されるので、これらのどのチャンネルもクライアントの性能に影響することはありません。しかしサーバ側の性能に影響を与えることはあります。とりわけ大量のクライアント接続が同時に開始されたときには影響を与えます。例えばストリーミングAMFは大量にクライアントからの同時接続を発生させる可能性があり、これはつまり大量のスレッドが生成されるということです。ただ先に述べたように、大量のスレッドによる影響は最小化することが出来ます。
全てのクライアント接続はデフォルトのチャンネルとその接続が失敗した場合の代替となるチャンネルが設定されています。サーバの通信内容により、異なる種類のチャンネルの組み合わせを指定することが出来ます。例えばRTMPチャンネルを指定してその接続が失敗した場合には長期のポーリング用チャンネルに切り替えるということです。
結論
LiveCycle DSのBlaze DSに対する本当の優位性は主にサポートを受けられることとデータ・マネジメント＊が出来るということになります。追加的なエンドポイントとチャンネルの利点については議論の余地があります。Gorilla Logicで私達が体験したプロジェクトではNIOエンドポイントやRTMPの必要性は感じませんでした。ただ他の全ての技術同様、明確な答えなどありません。他の方の経験談に関するコメントが得られることを期待しています。
機能比較表
著者について
1 http://www.linuxjournal.com/article/6530 (リンク)
2 http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html (リンク)
3 http://www.theserverside.com/discussions/thread.tss?thread_id=26700 (リンク)
4 http://cometdaily.com/2008/11/21/are-raining-comets-and-threads/ (リンク)
Adobeへのリンク
LiveCycleのホームページ (リンク)
LiveCycle Data Services ESのFAQ (リンク)
LiveCycle Data Servicesの種類による比較 (リンク)
その他のリンク
LiveCycle ES vs LiveCycle DS vs BlazeDS - 混乱状態の清算 (リンク)
なぜあなたはLiveCycle DSを使わないのか (リンク)