Paremus(サイト・英語) は最近Infiniflow(サイト・英語)のバージョン1.2(source)をリリースした。これはOSGiとSCAをベースにした次世代分散アプリケーションサーバだ。InfoQはParemusのマーケティングマネージャ Andrew Rowney氏にこのリリースについてとInfiniflowの新しいアプリケーションサーバモデルについて話を聞いた。
Andrew Rowney氏はまずInfiniflowがOSGi（動的なコンポーネント管理ができるコンポーネント指向/サービス指向なモデル）(source)とSCA（SOAにおいてサービス間の連携を実装非依存に行うためのモデル）(source) をベースにしていることを説明した後、Infiniflowはあるアプリケーションサーバの枠組みを持っていると言った。それは一連のOSGiモジュールとして書かれたコンポーネント、SCAバインディングによる外部サービスとのリンク、そしてInfiniflow上にデプロイされたアプリケーションに対するライフサイクル管理、モニタリング、スケーリングおよび障害復旧である。Andrew Rowney氏はInfiniflowによるアプリケーション開発のいくつかのベストプラクティスについて語った。
Infiniflowの性能をフルに利用するには、アプリケーションを単体のランタイムではなく、様々な処理要求を扱う別々のコンポーネント（OSGiバンドル）の複合体として考える必要があります。良い例とは、一箇所に並列計算可能な演算機能が集約化されていて、そのことで全体での処理時間を減らしている複合アプリケーションです。このようなタイプのアプリケーションを作るためには、Infiniflowが演算を行うバンドルを複製するように開発者が指定すればいいのです。つまり最終結果を可能なかぎり速く計算するためになるべく多くのインスタンスを作るのです。これはグリッドコンピューティングとみることもできますが、このアプリケーションは高価な専用グリッド施設を必要としませんし、ハードウェアをInfiniflow管理下にある他のアプリケーションと共有することもできます。その場合リソースの割り当てやリソース競合の管理は自動的に行われます。
Infiniflowの主な機能をあげよう。
- 主要なOSGiコンテナのサポート - アプリケーションデプロイを行うのにEquinox, Felix, KnopflerfishのOSGiランタイムコンテナが全てサポートされている。
- SCA準拠 - InfiniflowはSCA仕様のバージョン0.96を実装しており、1.0への準拠も今年の中ごろに予定されている。
- オープンソースベース - InfiniflowはオープンソースのNewton(サイト・英語)（GNU General Public License）(source)フレームワークをベースにしている。
- Spring Dynamic Modules(source)のサポート - Spring Dynamic ModulesアプリケーションはOSGi準拠のため、Infiniflowでも透過的にサポートされる
- 自動スケーリング - SCA System記述にしたがってアプリケーションを自動的にスケールする。
- 自己相似アーキテクチャ - Infiniflow自体がOSGiで構築されていて、SCA System記述によって接続されている。
- Eclipseベースのツール - Eclipseベースのプラグイン(サイト・英語) によってInfiniflow内でデプロイやテストを行うことができる。
- 自動障害復旧 - リソースにエラーがあった時、エラーの起きたコンポーネントが自動的に他のサーバーへ再供給される。
- モデルドリブンアーキテクチャ - 運用の複雑さを軽減するため、アプリケーションのランタイムはSCA System記述によってのみ変更可能で、その記述子に対する全てのアクセスは暗号化され、かつ監視されている。
Andrew Rowney氏にアプリケーションのスケーリングをどうのように行っているかについて詳細を聞いた。
Infiniflow Service FabricはOSGi対応したJVM実装による複数のInfiniflowコンテナから構成され、SCA Systemドキュメントから参照されているOSGiバンドル内にあるコードを動的にインストール/スタート/ストップ/アンインストールすることができます。
基本的なスケールアウト処理は以下のようになります。InfiniflowのService Fabricアーキテクチャにおけるアプリケーションレイヤのレベルでは、複合したSystemのスケールアウト処理は以下の働きのことになります。
- Service Fabricが、サービスコンポーネントからそのコンポーネントについてのSystem記述子（組み上げルールを示す）を受け取る。これにより "System"を構築しその”Target State”が定義される。それぞれのサービスコンポーネントは必要なランタイムとスケーリング時の処理内容についての情報を持つ。
- 要求されるスケーリング時の処理内容に基づいて、Infiniflow Provisioner（供給者）が利用可能なサーバー/仮想マシンに動的に問い合わせをして、システムのコンポーネントを割り当てられそうな候補を特定する。
- サービスコンポーネントの割り当てを承認したサーバはProvisionerから関連するSCA module fragment（SCAにおけるモジュールの構成要素）を受け取る。サーバはサービスコンポーネントを取り決めされた時間（契約と呼ばれる）の間ホストする。
- それぞれのサーバで、fragmentで指定されたOSGiバンドルをService Fablicレポジトリからダウンロード（pullと呼ばれる）し、ローカルでサービスをインスタンス化する。
- Service FabricはSCAドキュメントと照らし合わせながら実行状況の管理を続ける。必要になればTarget Stateの条件を満たすようにサービスコンポーネントのスケーリングと再配置を行う。
これは SEDA, Federated Space, Hadoop（分散システムのストレージ基盤）ベースで分散しているサービスコンポーネント間のメッセージングを行うためのスケールアウト処理を容易に設定できるということです。このメッセージングは同期または非同期通信で、RMIやSOAP、TCP/Streamingなどのプロトコルが使われます。
- システム内に分散しているサービスコンポーネント間で利用されるSCAバインド
- それぞれの複合システムに適用される処理内容の複製
- 関連するミドルウェア（関連付けがされた時）
Andrew Rowney氏は続けてInfiniflowの将来の計画を説明してくれた。
- Infiniflow Service Fabricをもっと賢くして、Infiniflowを一層自立させる
- 他のミドルウェア(source)との統合をプロバイダと協力して引き続き努める
- モニタリングフレームワークの完成度を高める
- 大規模なスケールアウトやエラーテストへの耐性を高める
- オープンソースツールを利用して開発者の支援を進める
- 標準化団体と連携してInfiniflowのアーキテクチャのオープンさと柔軟さを担保する