分散共有メモリを利用したAdobe ConnectNowとTerracottaの統合でスケーラビリティに対応

作者 Srini Penchikala , 翻訳者 ガーナー 淳子 投稿日 2009年5月26日 午後3時16分

コミュニティ

Java

トピック

パフォーマンス&スケーラビリティ

タグ

Terracotta

原文(投稿日：2009/4/30)へのリンク

Adobe ConnectNowは、ウェブ会議に使用できる無料の協調ソフトウェアである。ConnectNowはユーザに共有スクリーンやチャット、ノート、音声、映像といったオンライン・ミーティング運営のための会議機能を提供している。これは、マルチユーザでリアルタイムの協調アプリケーション向けのPAAS（platform-as-a-service）であるAFCS（Adobe Flash Collaboration Service）をベースに構築されている。

AFCSは3つのコンポーネント、つまりクライアントFlex SDK、サーバサイドFlash Media Server（FMS）、そしてサーバサイドJavaから構成されている。Flash Media Server（「コミュニケーション」サーバ）は、Flashクライアントあるいは映像配信システム（HTTPプログレッシブ・ダウンロードではなく映像ストリーミング）間での協調アプリケーションを構築するのに使われている。クライアントはRTMPプロトコル（あるいはその別バージョン）を用いて、永続的なソケット接続上でサーバと接続している。

Adobe社はConnectNowアプリケーションとTerracottaソフトウェアを統合し、ウェブ・アプリケーションのスケーラビリティに対応するためにTerracottaの共有アプリケーション・メモリの記憶容量を利用している。FMSアプリケーションをプロビジョニングおよび認証システムと統合するため、そしてFMSサーバ・プールを積極的に利用するために、AFCSはTerracottaのサポートのもとJavaアプリケーション・サーバのクラスタを使用している。これはユーザ・ログイン、承認管理、コンテンツ・リポジトリ、FMSサーバのモニタリングおよびクラスタ管理（これはどのミーティングがどのサーバで行われているか、そしてもとのサーバに障害が起きた場合はミーティングが別のサーバに再割り当てされているかということを監視するためである。FMS接続はステートフルかつパーシステントなので、通常のロード・バランサは使用できないのである）といったサービスを提供している。

InfoQはAdobe社のBusiness Productivity Unitのシニア・コンピュータ・サイエンティストであるRaffaele Sena氏に、Adobe ConnectNowおよびTerracottaの統合について、そしてウェブ・サイトのスケーラビリティ要件についてどのように取り組んだかについて話を聞いた。

ウェブ会議および協調アプリケーションであるAdobe ConnectNowは従来のウェブ・アプリケーションと比較してどうでしょうか。

この協調ウェブ会議アプリケーションと従来のウェブ・アプリケーションの主な違いは、私達が扱うデータの大部分はトランジェントであるという点です。アプリケーション・サーバはログインしたユーザ、開催中の会議、会議に参加しているユーザ、そしてミーティングの状態の記録をとります。しかし、会議が終わりユーザがログアウトすると、これらの情報は不要になります。ですから、よりデータベース・ドリブンである従来のウェブ・アプリケーションがTerracottaといったシステムを効率性改善のための分散キャッシュとして使用するであろうことに対し、私達のシステムは実のところ、Terracottaを「分散共有メモリ」として用いており、そこではコンピュータ間で共有されるデータの大半はメモリ上にのみ保持されます。

ウェブ会議および協調ドメイン・スペースでのアプリケーションにおけるスケーラビリティおよびパフォーマンスの標準的な要件とは何でしょうか。

ConnectNowは、私達が扱う何万と同時進行されるミーティングのホスト・システムとしてデプロイされますが、必要に応じてシステムをより小さなクラスタに分割できるようにシステム設計されました。とりわけユーザ・ログインとミーティングの開始（データベースから情報をフェッチしなくてはならないもの）についてパフォーマンスというものが重要な一方、アプリケーション・サーバのレベルで行われること（ユーザがシステムのこの部分とは交信することのないところ）の大半は、実行中の会議室の監視や会議終了時の会議室の状態の保存などといったバックグラウンドに存在します。ここで最重要の要件とは、信頼性と、会議室の運営をクラスタ内の別のサーバに「移動させる」ことによってサーバの障害から復旧できることです。

御社のシステム・アーキテクチャにTerracottaソリューションがどのように役立ったか、いくつか例を挙げていただけますか。

私達のアプリケーションの特徴の1つは、多くのデータが局在的であるということです。アプリケーションは2種類のサーバから構成されています。それは、会議の通信を管理する「コミュニケーション・サーバ」（私達はこのサーバに、よく最適化されているC/C++サーバであるAdobe Flash Media Serverを使用しています）と、サーブレット・コンテナで実行されるJavaアプリケーションの「アプリケーション・サーバ」です。それぞれの会議に対しコミュニケーション・サーバとメディア・サーバ間に専用の通信チャネルがあり、各会議についてアプリケーション・サーバは会議状態の記録をつけ、ある1つの会議のデータについてはアプリケーション・サーバのクラスタ内の1つのマシンのみが管理するようにしています。しかしここで再び注意していただきたいことは、そのマシンに障害が起こった場合、別のマシンがそれを引き継ぐという点です。

Terracottaがなければ、データをデータベースあるいは共有ディスクのファイルに保存して極めて遅いパフォーマンスをもたらすことになるか、ローカル・コピーでなされた変更はそのクラスタ内の各マシンに伝えられなければいけないことを知りつつも分散キャッシュに保持して、不要かつ大量のネットワーク・トラフィックおよびメモリ利用をすることになるかのどちらかです。Terracottaがあればこれは問題となりません。データは会議室のURLでインデックスを付けたハッシュマップの分散メモリに保存されますが、1つのマシン上のみで使用されているので、そのマシンとTerracotta上のみにデータが存在するということが明らかです。そのマシンに障害が起これば、別のマシンが引き継ぎ、データはアプリケーション内で特定のコードを持たずに「魔法のように」移動することになります。

Terracottaとの統合前、Adobe's ConnectNowシステムのアプリケーション・アーキテクチャはどのようなものでしたか。

Terracottaとの統合前、データベースをアプリケーションの同期メカニズムとして使用しましたが、そのアプリケーションとは主としてオンラインのプレゼンテーション・ビューアーでした。その時点では、私達はデータベースのクエリや小さなクラスタを回避できた静的コンテンツを多く扱っており、規模を変更する必要があった際はそのデータベース・システムを活用できました。ウェブ会議機能を追加したとき、静的なデータように設計された当初のバックエンドをまだ持っており、それを適合させてよりトランジェントなシステムを提供しました。2007年、新しいクライアント（Flash 9、Flex、 ActionScript 3）の能力を利用するためにシステム全体を書き換えることにしました。アプリケーション・サーバ側では、新しいウェブ会議と協調アプリケーションの要件向けに調整されたシステムを構築しました。

それでAFCSをConnectNowウェブ会議アプリケーションのバックボーンとして作ったとき、主にトランジェント・データを管理するシステムが念頭にありました。私達はデータベースが必要とされないデータベース・ボトルネックを避けたく思い、それを遂げるのに役立つ適切なツールを見つければよいだけでした。私達が必要としていたのは、「分散キャッシュ」ではなく「分散共有メモリ」をもたらしてくれるものであり、それはまさにTerracottaが私達に提供できるものだと判明しました。

その状況からデータベースを取り除くのにどのようにTerracottaを利用できたのかについて、アーキテクチャの詳細を説明していただけますか。

繰り返しになりますが、ここでの要点は、私達のアプリケーションの性質によってデータの大半がトランジェントであるということです。確かにデータベースはあります、それは会議開始時にミーティングの初期状態を読み込み、終了時に新しいステータスを保存するコンテンツ・リポジトリです。しかし会議時間中、データベースなしで実行できるのです。

• 次へ >