TerracottaによるPOJOメッセージングアーキテクチャ

作者 Steven Robbins, 翻訳者 編集部 投稿日 2008年3月13日 午後6時0分

コミュニティ

Architecture

トピック

メッセージング,

設計,

グリッドコンピューティング,

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

タグ

Enterprisey,

Terracotta,

POJO

Mark Turansky氏は、彼独自のTerracottaとJava 5を使用した、POJOメッセージバスアーキテクチャの実装の詳細(source)を明らかにした。Mark氏は、POJOメッセージバスを作成するのに、MQまたはJMSベースの配置を使用するのではなく、Terracottaアーキテクチャ(参考記事一覧)を利用している。これにより、彼のメッセージが必要とする、簡潔であり、単純であり、さらに安価であるインフラストラクチャソリューションが可能となった。この経緯の一部が、以下のように述べられている。

私達の2番目の実装は、JMSを使用していました。（なぜなら）ActiveMQも、オープンソースであり、成熟しています。Camelは、キュー間でルールをルーティングするための小さなドメイン固有言語を提供するという点においてとても優れているように思えました。

 ActiveMQを正常に機能させるには、いくつかの問題があった。このため、Terracottaを使用できないかを再調査することになった。設計が優れていたため、チームは、比較的簡単に古いメッセージング構造を新しい構造に切り替えることができた。

JMS関連のすべてのコードは、ハンドラおよびリスナのインターフェイスによって隠されていました。私達のコンシューマ側のロジックは、メッセージ (私達独自のドメインオブジェクト) が何に基づいているかを認識していません。ハンドラおよびリスナの実装は、Springによって注入されています。このため、わずか90分で、Terracottaを使用する効率的なキューイングおよびルーティングシステムにほぼ切り替えることができました。その後、整理をして、堅牢性を向上させ、ビジネス可視性を得るための機能を追加し、さらに徹底的な負荷テストを実施しました。こうして、すべてがすばらしく機能するようになりました。

このメッセージングシステムは、主に、以下のような要素から成る。

•  キューイングのためのJava 5の並行性API (特に、境界付きのjava.util.concurrent.LinkedBlockingQueue)
• Javaスレッド化の認識
• 長時間実行Javaプロセスの考慮 (Tomcatの処理を参考)
• クラスローダに対する平均以上の理解、およびそれらを指定する手段
• 要求を「スプール」する手段

残りの部分は、クラスローダ、クラスタ化メモリ内のオブジェクト、および並行性をTerracottaがどのように処理するかの調査および理解に基づいている。Terracotta自体は、メッセージングの骨格、および接着剤のようなものとして機能する。

最後に重要なことになりますが、複数のキューやマルチJVMコンシューマは、必須のものです。また、重大な障害が発生しても消えることのない永続的データ (メッセージストア) も必要になります。すべてのキューおよびコンシューマの状態や進行状況を把握できるビジネス可視性も必要です。さらに、それらのすべてをまとめることも必要です。Terracottaサーバは、これらの要件に十分に対応することができます。

最終的に、Terracottaは、Java 5並行性APIを使用して、プロデューサの送信先、および競合するコンシューマの取得元となる「インメモリ」POJOメッセージキューを提供することを可能にした。コンシューマを、ブートストラップローダーカ(source)を使用する長時間実行デーモンプロセスとして実装することにより、このアーキテクチャは、POJOの単純性を保ちながらグリッドコンピューティング機能を提供できるようになった。

 Mark氏は、このアーキテクチャが開発者にとってどれほど扱いやすいものであるかを次のように述べている。

「Terracotta」は、すばらしい機能を持つPOJOシステム全体をIntelliJで作成することを可能にします。1つの「コンテナ」型のメインプログラムは、単純に、各種すべてのSpring configをロードすることによって、すべてのコンポーネントを単一のJVMで実行できます。開発者は、メッセージングシステム全体を各自のデスクトップ上、つまり各自のIDEで稼動させ、そこでコードを実行することができます。このメッセージングシステムの中で、127.0.0.1でリッスンするエンドポイントにメッセージを送り、メッセージ用のコードをデバッグすることができるのです。

この実装によって、ほとんど犠牲を払うことなく、単純性、スケーラビリティ、および信頼性を得ることが可能となった。Mark氏は、彼独自の最小限のフレームワークを利用することによって、チームが、実装において大きな自由度と柔軟性を得ることができたとも述べている。重いアプリケーションサーバAPIへの依存に縛られることがなくなり、容量を少なく抑えることもできるようになった (全体の実装は、100KBのjarファイルである)。

 　Terracotta FAQでは、JMSをTerracottaに置き換えることは推奨しない(source)と述べられている。しかし、Terracotta社のCTOであるAri Zilka氏は、Mark氏の意見(source)を支持している。

関連のニュースとして、フォーク/ジョインまたはマスタ/ワーカーの処理を行うためにScalaアクタをクラスタ化するのにTerracottaを使用する(source)というJonas Boner氏による記述もある。

原文はこちらです：http://www.infoq.com/news/2008/03/terracotta-as-message-bus

• 次へ >