Apache Tribesを使った不均質なクラスタでの通信をFillip Hanik氏が語る

作者 Srini Penchikala , 翻訳者 金森 諭 投稿日 2009年2月11日

セクション

デベロップメント,

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

メッセージング ,

クラスタリング&キャッシング ,

Java

タグ

Tomcat

Apache Trbes(リンク)はTomcatのサーバクラスタでグループ通信をおこなうためのTomcatモジュールだ。Filip Hanik氏(リンク)はさまざな種類のサーバから成るクラスタの課題と、Tomcatクラスタに必要なグループ通信をTribesがどのようにサポートするかについて発言をしている。その彼がSpringOne Americasカンファレンス(リンク)でTrbesのメッセージングフレームワークについてプレゼンテーション(リンク)をおこなった。

彼のプレゼンテーションはいくつものグループ通信用のオープンソースがあるというところから始まった。そのようなプロジェクトにはAppia(リンク)、Spread(リンク)、Erlang(リンク)、JGroups(リンク)などがある。彼が言うには、同質なサーバから成るグループモデルではクラスタ内の全てのノードが特定可能で、それぞれが同じようにメッセージ処理、送信、受信をおこなう。多くのグループ通信モジュールはこのようなモデルに対してのものだ。しかし多様なノードから成るクラスタの場合は、クラスタに必要なパフォーマンスとスケーラビリティを維持するのにこの方法が最善でないことはしばしばある。

さまざまなハードウェア環境をもつノードがそれぞれ動的に処理をおこなう場合、統一的でないグループ通信モデルの方がより良いものとなる。そのモデルでは、優先度や品質保証レベルがメッセージごとに異なることになる。

TribesはTomcat 5(リンク)コンテナのクラスタ/セッション複製コードを元に作られたグループ通信機能を持つメッセージングフレームワークだ。つまりTomcatのクラスタ(リンク)についての通信フレームワークとなる。Tribesの目標のひとつは分散型のアプリケーションでP2PやP2G(Peer-to-Group)通信を簡単に実現することだ。Tribesのメッセージ配信方法は2つあり、ひとつが2つのノード間でも利用できる並列メッセージ配信、もうひとつが複数のノードへメッセージ送信するのに利用する並行メッセージ配信だ。

Tribesフレームワークには他にも次のような機能がある。

• 品質を保証するメッセージ配信: デフォルトではTCPをベースにし、java.io(リンク)やjava.nio (リンク)パッケージを用いる。
• 3つの品質保証レベル: Trbiesではメッセージ配信での品質保証においてNO_ACK、ACK、SYNC_ACKの3つのレベル（ACKは通信が正常にできたことを示す信号）を使える。
• メッセージ配信ごとに処理を変える: これにより異なる方法でそれぞれのメッセージを配信したり品質保証レベルを変えることができる。
• 動的なインターセプタ: これにより決められたメソッドやメッセージ属性（フラグ）に応じて、どのようなイベントでもインターセプトすることができる。インターセプトをおこなわないメソッドを対応させるためにChannelInterceptorBaseクラス(リンク) を使うと手間を最小限にできる。
• 配信結果のフィードバック: Tribesでは各メッセージや各配信タイプ（NO_ACK、ACK、SYNC_ACK）について配信結果のフィードバックすることを目指している。メッセージ配信は同期的あるいは非同期的のどちらでもおこなえる。
• 並行配信と並列配信: 並行配信（concurrent delivery）は任意のタイミングで1つ以上のメッセージを送信したり受信したりできることを指す。「メッセージブロッキング」はなく、 SYNC_ACK（同期まで取れたことを確認する）品質保証レベルの10MBのメッセージであってもNO_ACKレベルの10KBのメッセージを妨害しない。並行配信（parallel delivery）はひとつのスレッド（NIO）だけで複数の送信先へ並行してメッセージを送ることができる。
• 固定ノード階層: この機能によってクラスタの司令塔や自動的にマージをおこなうグループを決めたりマルチキャストが届かなさそうなノードを見つけたりすることができる。
• エラー検知: これには単純なインターセプタであるTcpFailureDetectior(リンク)も含まれる。これはクラスタのメンバが消滅したときにフィードバックを提供する。エラー検知のためにはタイムアウトを待つことがなく、ノードへのpingによってネットワークを停めてしまう心配もない。

TribesにはRPCメッセージングやチャネルをJNDIツリーにバインドするJNDI Channelといった機能もある。このフレームワークのアーキテクチャには次のような要素がある。

• チャネル: チェインの最初のインタセプタで、一つあるいは複数のChannelListener(リンク)およびMembershipListener(リンク)を保持する。チャネルによってメッセージはシリアライズ/デシリアライズされる。またbyte[]データをやり取りするためのByteMessage(リンク)の機能もある。
• インタセプタ: チェインの中間のインタセプタには、エラー検知や静的メンバシップ、全体への命令あるいはメンバごとの命令、司令塔の選出、メッセージデータの暗号化、非同期型のメッセージ送信、各種レベルの配信品質保証などがある。
• コーディネイタ: チェインの最後のインタセプタで、SenderやReceiverやMembershipといった入出力コンポーネントを仲介する。

このプレゼンテーションで彼は、Tomcatのクラスタリングを有効にしたりウェブアプリでセッションやコンテキスト属性のレプリケーションをおこなう設定の仕方などをサンプルアプリケーションを使って説明した。server.xmlファイルはCluster、Session、 Manager（DeltaManagerあるいはBackupManager）、Channel（Tribesの）、Membership（実行時に他のノードを見つけるのにマルチキャストを使う動的なメンバシップと、server.xmlにノードを記載する静的なメンバシップの両方が可能）、 Messaging（TCPオーバで動作し、各ノードにはレシーバとセンダがある）、Interceptors（機能的にはValvesと似ている）、 Valves（各リクエストの最後にセッションレプリケーションを開始する）、ClusterListener(特定のタイプのメッセージについてのカスタムメッセージリスナを作れる）などのクラスタ要素が記述される。

原文はこちらです：http://www.infoq.com/news/2009/01/filip-hanik-tribes

• 次へ >