BT

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

| 作者: Gavin Terrill フォローする 1 人のフォロワー , 翻訳者 大田 緑 - (株)チェンジビジョン フォローする 1 人のフォロワー 投稿日 2008年9月4日. 推定読書時間: 4 分 |

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

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT