Shoal(source)はJavaEE アプリケーションサーバー向けの動的クラスタリングJavaフレームワークで、フォールトトレランス（障害耐性）・信頼性・可用性のあるインフラの構築を可能にする。Shoalはクラスタリングや分散システムの機能が求められるどんなJavaアプリケーションにも適用ができ、GlassFish(サイト・英語)（v2以降）やJOnAS(サイト・英語)アプリケーションサーバーのクラスタリングエンジンとしても採用されている。
Shoal フレームワークはクラスタメンバの追加や削除などのイベントをリアルタイムに発信するためのクライアント用APIを提供する。クラスタメンバをグループへ追加する際、それをCoreメンバあるいはSpectator（観客）メンバのどちらかに指定できる。Coreメンバはそのエラーがクラスタ内の全てのメンバに通知され、Spectatorメンバではそれ自身のエラーは他のメンバに通知されないが他のCoreメンバのエラー通知は受けることができる。 Shoalのコアサービスはグループ管理サービス（GMS）で、これはクラスタ内の特定のメンバ（あるいはそのグループ）に対してメッセージを送るためのグループメッセージング機能をクライアント（JavaVM）に提供するものだ。Shoalはこの他にも復旧指向のシグナル群とサポート、復旧を行うメンバの自動選定（Shoal Automated Delegated Recovery Initiation(source)：自動委任された復旧手続き）、保護的なエラー囲い込み処理、といった非常に有用な機能を利用可能にする。
最近のjava.netのウェブサイトに掲載された記事(source)では、Shoalフレームワークのアーキテクチャと、どのようにJavaアプリケーションに導入するかについて取り上げられた。InfoQはShoalの製作者であるShreehar Ganapathy氏とMohamed Abdelaziz氏に、Shoalの現在の機能と将来のロードマップについて話を聞いた。まずShoalとTerracottaのような他のオープンソースのJVMクラスタリングフレームワークとの違いについてたずねた。Terracotta(サイト・英語)は機能強化をAPIを用いないバイトコードによるアプローチを採っていて、データレプリケーション分野の問題を解決するのには優れた効果があると二人は言う。Shoalのクラスタリングはフォールトトレランスなインフラの見方に立っている。Shoalではグループイベント通知のモデルを用意していて、これによりデータレプリケーションを含む分散システムにおける様々な問題を解消するための有効なアプリケーションを構築できる。二人は開発チームがShoalの機能を使ってどのように GlassFishサーバーのクラスタリング要件を解決しているかを説明してくれた。
私たちの場合を例にあげると、GlassFishではいくつものGFコンポーネントの要求を満たすクラスタリング技術が必要とされます。例えばIIOPロードバランサやセッションレプリケーションモジュール、トランザクションサービスモジュールなどです。
IIOP ロードバランサの場合、エラーが起きた時にORBがリモートクライアントを他のクラスターメンバーに仲介するすることが求められます。リモートで特定の ORBに接続しているクライアントは、Shoalのイベント通知メカニズムによるアウト・オブ・バンド・シグナリングで知らされたIIOPのエンドポイントアドレスによって動的にクラスタの形状が変化したという情報を得ることができます。
トランザクションサービスモジュールの使用例としては、自動トランザクション復旧操作をリモートのクラスタメンバからエラーのあったメンバのログに基づいて行うことがあります。それによってエラー時に完了しなかったトランザクションを完了させることができます。これを行うために、
エラー囲い込み機構によってリカバリサーバの選択肢(source)を通知する機能が提供されています。
Shoalにおけるグループ通信モジュールは、JGroups(source)のような他のグループ通信フレームワークのとどう違うのか。
グループ通信サービスプロバイダというのはサービスプロバイダAPIの集まりで、様々なグループ通信プロバイダの実装をサポートするものです。デフォルトではShoalはJXTA（サイト・英語）（Sunがオープンソース化したP2Pフレームワーク）を利用します。サービスプロバイダとしてのAPIが統一されていれば、他の通信プロバイダを利用することもできます。そのためJGroupやAppia（サイト・英語）ベース、あるいはJINI（サイト・英語）ベースのグループ通信プロバイダも使用可能です。
JXTA での通信ではTCPとUDPを分けて考える必要はなく、またIPに限定されることもありません（RFやBTなどもサポート）。クラスタ内でのマルチキャストがあった時、JXTAはそのクラスタメンバへメッセージを送信する最良の方法を動的に決定します。それはIPのマルチキャストや仮想マルチキャストを利用して行われます。
ShoalにおけるJXTAベースのサービスプロバイダにはピア（通信を行う実体）アドレスに対する位置透過性の利点がある。グループメンバは自身の名前によってアドレスが決められる。これはハッシュ値化され、128bitで表されたIDにマッピングされる。このIDは、アドバタイズメント（全ての物理アドレス・仮想アドレスをメンバに知らせるXML文書）とリンクされ、これによってフォールトトレランスや流動性、IP以外の転送が実現される。このことはクラスタ内の接続を簡素化し、クラスタやソケット、メッセージチャネルがグループやインスタンス名によってアドレスを決めることを可能にする。さらに通信チャネルもそのネーミングスキーマに含まれるため、インスタンス間のアドレス仮想化も可能だ（例として、特定のアプリケーションサービスについて、そのサービスが使用するポートでなく通信チャネル名を使用できる）。JXTA上のTCP通信ではNIO（サイト・英語）（Java New I/O）のAPIを全て利用でき、スケーラブルなメッセージハンドリングやスループットを扱うことができる。JXTAにはAuthentication （送信者を保証する）とAuthentication（送信者が送信を行うことについて承認されていることを保証する）の機能があるため、 EndToEndアプリケーションのセキュリティも提供する。また二人はJGroupsフレームワークの信頼性のあるマルチキャスト機能についてもコメントした。
JGroupsは代表的なグループ通信プロバイダです。私たちがJGroupsで気に入っている多くのことの一つは、信頼性のある優れたマルチキャストスタックを提供していることです。現在のJXTAはまだそれほどのマルチキャストを持っていませんし、私たちも効果的で軽量に信頼性を提供できるオープンソースメカニズムの評価をおこなっている段階です。JGroupsの別の差別化要因はRPCDispatcher(source)です。これはUDPを使ってブロッキングメッセージをシミュレートするのに非常に役立つ機能です。
仮想マルチキャストチャネルとそれがどのようにJEEクラスタリングアプリケーションで利用されるかについて。
仮想マルチキャスト用チャネルは通常のマルチキャストのアクセス領域を超えて通信を行うことを可能にします。複数のサブネットをまたぐクラスタが必要な時、あるいはそもそもマルチキャストが全く使えない時、普通はネットワーク管理者に特定ソケットについて特定のルーターへのマルチキャストを許可してもらうよう働きかけないといけません。しかしJXTAでもたらされる仮想マルチキャストを使えばネットワークやアプリケーションレベルでの変更なしにグループ通信をシームレスに行うことができます。Shoalではあるメンバを冗長性のあるルーティングホストとして簡単に指定できます。指定されたメンバはソフトウェアルータのように振る舞い、グループメンバ全てに対するトラフィックをルーティングします。これはIGMPに似た非常に有効な機能です。ネットワークスイッチをシミュレートするルータノードのおかげで、仮想マルチキャストグループをいずれかのルータノードに加えるだけでメッセージをクラスタへ広められるのです。さらに可能なネットワークであれば、IPマルチキャストを利用することもできます。そのためサブネット内でのみマルチキャストをするケースでは、一つあるいは複数のグループメンバをルーティングホストとして設定すれば、サブネット内ではIPマルチキャスト、サブネット外へはTCPオーバーのグループ通信を行うということも可能です。これは物理的に分散したクラスタを使用するWANデプロイの基盤になります。WANベースのデプロイに関しては、クロスファイアウォールなどの技術を将来取り入れようとしています。
クラスタ化されたアプリケーションにおけるセッションレプリケーションについて、クラスタ化されたEJBやJMSコンポーネントのように、Shoal APIはウェブでのHTTPセッションレプリケーション要求に対して利用可能か聞いた。
GlassFish アプリケーションサーバーのEJBコンテナやTransactionサービス、Timerサービス、ORB、セッションレプリケーションモジュール、その他のコンポーネントというのは、Shoalをクラスタメンバとの相互アクセスのために使用しています。JMS（MQクラスタ）やデータベース（たとえばPostgre(source)SQLやMySQL(source)のクラスタ）、CVS(source)やSubversion(source)など、Shoalはほぼどんな製品のクラスタリング化にも利用できます。
ShoalフレームワークはDistributed State Cache（DSC）と呼ばれる分散共有ストレージ機能も持つ。これは物理メモリ上でアプリケーションの状態を分散キャッシュすることを可能にする。デフォルトでは軽量なキャッシュレプリケート向けに、GMSによる実装がされている。Sreedhar氏はDSCと他のJavaオブジェクトキャッシングフレームワーク（JBossCache(サイト・英語)やOSCache(source)、EHCache(サイト・英語)など）との違いについてこう説明する。
Shoal のDistributed State Cacheはインターフェスで、複数の実装が可能です。デフォルトの実装はシンプルな共有キャッシュで、設定データやグループ全体についての状態マシンといった軽量な軽量なメッセージングでの利用向けになっています。高いスループットのキャッシュには向いていませんし、LRUベースのキャッシュ無効化や分散ロック対処の機能はありません。
グリッドあるいはクラウドコンピューティング(source)はスケーラブルなアプリケーションアーキテクチャをデザイン・実装する上で最近ますます関心を集めている。Shoalフレームワークは新たなグリッドコンピューティングのアーキテクチャの分野でどのような役割を担うのかを聞いてみた。二人はそのようなアプリケーション構築にShoalが適していることを説明してくれた。
Shoalはグループリーダという考えを持ちます。グループリーダは基礎となるグループ通信プロバイダに依存しています。グループリーダはエラーが起きた時にどのように継続を行うかを定めます（ここでもまたグループ通信サービスプロバイダに依存します）。インスタンス名のマッピングを利用することで、リーダーとその後の処理を行うメンバが動的かつ自立的に決められ、そのことでネットワークトラフィックを減らし構成を素早く行えますし、スプリット・ブレイン・シンドロームを事実上考慮しないですみます。この基本的な２つの要求が満たされれば、グループリーダをコンピュータグリッドのタスクマネージャとしてみなすことができるでしょう。JXTAの仮想マルチキャストとクロスサブネットの機能と組み合わせれば、リソースの島々という考え方を広げることができます。つまり、Shoalではそれぞれのリソースにタスクを実行させて、その経過をメインラインのグループリーダに知らせることが可能になるのです。サービスの位置透過性はこのようなリソースも含めた流動性を提供します。これはグリッドを利用状況に応じて拡大あるいは縮小したり、必要な時に移動させたりできることを意味します。グリッドを行うProject Blackbox(source)データセンターを考えてみるといいでしょう。
Shoalの別の利用方法は、グリッドアプリケーションの基本エンジンにすることです。Project FishFarm(source)では現在Shoalをこの用途に用いています。
最後にShoalプロジェクトの将来のロードマップについて、新機能や今後のリリースの観点から聞いた。
私たちは現在Project Sailfin(サイト・英語)の通信アプリケーションサーバに取り組んでいます。そこではShoalはロードバランサコンポーネントなどさまざまなことに利用されています。将来的には分散キャッシュをベースにしたデータグリッドソリューションを計画しています。
ShoalはGMSを使うことでサーバーリソースの動的なプロビジョニングにも利用できる。エラーが起きた時に負荷状況に応じて適切にリソースを供給されることになる。ShoalはCDDL version1.0とClasspath Exception付きGPL v2のデュアルライセンス(source)の下で提供されている。
原文はこちらです：http://www.infoq.com/news/2008/02/shoal-clustering-framework