EhCache Serverを使って1テラバイトのキャッシュをデプロイする

作者 Gavin Terrill, 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年9月4日 午後6時35分

コミュニティ

Java,

Architecture

トピック

REST,

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

タグ

Caching,

JSR 311

EhCache(リンク)チームのGreg Luck氏が、キャッシングにSOAPとRESTful API(リンク)を使用できることを8月の初めに発表した(リンク)。説明は以下のように記述されている(リンク)。

Ehcacheは、Cache Serverを提供します。ほとんどのウェブコンテナのWARファイルとして、または、スタンドアロンサーバとして利用できます。Cache Serverには2つのAPIがあります。: RESTfulリソース指向とSOAPです。両方とも、どのプログラミング言語でもクライアントをサポートします。

これに続く投稿で、Greg氏は、理論上1テラバイトのキャッシュをデプロイするオプションに関する彼の考えの概要をまとめている。

ehcache単独の最大のインスタンスは、メモリで約20GBで実行されます。最大のディスク記憶装置は、各々100GBで動きます。分割したキャッシュデータを持つノードを一つにまとめ、さらに大きなサイズにします。20GBのノードが50個で、1テラバイトを利用できるようになります。

最初のもっとも簡単なアプローチは、ehcacheサーバで実行する複数のノードの設定を含む。そして、オブジェクトのハッシュコードに基づいて使用するサーバをクライアントに決定させる。

String[] cacheservers = new String[]{"cacheserver0.company.com", "cacheserver1.company.com", "cacheserver2.company.com", "cacheserver3.company.com", "cacheserver4.company.com", "cacheserver5.company.com"};
Object key = "123231"; 
int hash = Math.abs(key.hashCode()); 
int cacheserverIndex = hash % cacheservers.length;
String cacheserver =cacheservers[cacheserverIndex]; 

冗長化をサポートするため、ロードバランサが導入され、各ノードは2つのehcacheサーバのインスタンスを実行する。既存の分散キャッシュオプション (RMIやJGroups)を使って可能になったインスタンスの複製を利用するのだ。このアプローチでは、クライアントは、まだハッシュコードを使ってサーバを決定している。しかし、今、エラーは、ロードパランサによって割り当てられた仮想IPの後ろでユーザに気付かれずに扱われる。

Gregが説明した3番目のオプションは、ロードバランサへルーティングの要求の責任を移すことに関係する。

EhCache ServerのRESTful版は、Jersey - JSR 311 リファレンスの実装 - に基づく。Jerseyの開発者の一人、Paul Sandoz氏が、サンプルのXMLドキュメントを作成して取り出すため、jerseyのクライアントAPIがキャッシュにアクセスするのにどのように使われたかを議論した(リンク)。

// retrieving a node
Node n = r.accept("application/xml").get(DOMSource.class).getNode();
// creating a node 
String xmlDocument = "...";
Client c = Client.create(); 
WebResource r = c.resource(http://localhost:8080/ehcache/rest/sampleCache2/2); 
r.type("application/xml").put(xmlDocument);

それでは、RESTfulのキャッシュはどんなシナリオで役に立つのか?James Webster氏が、大企業でこのアーキテクチャスタイルの導入の増加が見られることを報告している(リンク)。

HTTP.私が見た2、3の投資銀行が実装するアーキテクチャパターンは、分散メモリキャッシュです。それは、市場データ (例えば、株価、金利カーブ、乱高下が現れたり関係したりするような派生価値) や静的データ (例えば、取引先企業の詳細や決済の不履行) にアクセスを提供するために、HTTP越しにRESTfulなフロントエンドを経由してアクセスされます。分散キャッシュは、膨大なデータセットを保持するために「簡単に」調整することができる。そして、クライアントがHTTPを介してさえいれば、フロントエンドで技術にこだわらないやり方でデータにアクセスできる。

James氏が指摘する通り、商業ベンダ (OracleやGigaspaces) が製品の中でRESTfulなインターフェースをサポートするのにどれくらい時間がかかるのか見るのは興味深いだろう。

原文はこちらです：http://www.infoq.com/news/2008/08/restful-ehcache

• 次へ >