Ehcache BigMemoryは、アプリケーションにより近い場所で大規模なデータを格納するプロセス内、オフ・ヒープのキャッシュである。Terracottaは、Enterprise Ehcache製品でBigMemoryモジュールが一般提供可能となったと先週に発表した。BigMemoryは、標準Ehcache APIの一部であり、overflowToOffHeapとmaxMemoryOffHeapいうキャッシュの２つの新しい属性を以下のように指定することで有効になる。
<cache name="sample-offheap-cache"
maxElementsInMemory="10000"
eternal="true"
memoryStoreEvictionPolicy="LRU"
overflowToOffHeap="true"
maxMemoryOffHeap="1G"/>
BigMemoryは、伝統的なキャッシングソリューションとは、メモリ格納戦略の点で異なる。Javaヒープにデータを格納しないことで、Java Virtual Machine(JVM)のガベージコレクション(GC)の問題を避けているのだ。このBigMemoryストアは、オフ・ヒープ・ストアと呼ばれる。伝統的には、キャッシュ・ソリューションは、キャッシング・ノードのクラスタにデータを分散配置することで、この種の問題を回避するように考えられていた。BigMemoryは、新たなアーキテクチャ上の選択肢を提供し、ギガバイト以下のヒープサイズをもつJava Virtual Machine (JVM)で実行することが可能であり、データへの高速アクセスのためにオフ・ヒープ・メモリを利用する。
InfoQは、TerracottaのCTOであるAri Zilka氏に会い、Ehcacheフレームワークの新しいBigMemory機能および、どのような利用用途でアプリケーションのパフォーマンスや制限を改善できるのか話を聞いた。
InfoQ:Ehcacheフレームワークに新たにBigMemory機能を追加した主要な動機はどういったものだったのですか？
一番の動機は、Terracottaサーバで問題になっていたGCの問題を解決しようというものだった。サーバでのGCによってレスポンス時間にばらつきが生じ、大規模なGCが発生するとキャッシュクライアント(L1)が、バックアップのTerracottaサーバにフェイルオーバーを引き起こすこともあり得た。このソリューションが、どんなにすばらしいものか気がついたので、私たちはEchacheスタンドアロンの追加のメモリストアまで、その利用範囲を広げ、それがEnterprise EhcacheのアドオンであるBigMemoryとなった。
InfoQ:オフ・ヒープ・ストア(BigMemory)がどのようにJavaのガベージコレクションの旧来の複雑さを回避しているかについて、技術的な詳細を教えてもらえませんか？
BigMemoryは、キャッシュ・オブジェクトをJavaヒープの外部、かつJavaのオペレーティングシステムのプロセス内に格納している。従って、プロセス内のキャッシュであることには変わりがなく、それに関連するパフォーマンス上の恩恵を享受しつつ、ヒープを利用しないので、アプリケーションはとても小さなヒープを設定することが可能で、それによってGCの問題を回避することができる。BigMemoryはJDK 1.4でJavaに導入されたDirectByteBuffersを利用している。すべてのJava実装でBigMemoryを利用することが可能であり、JDKを変更することなくBigMemoryを利用できるのだ。
私たちは、オペレーティングシステムのメモリマネージャの機能とほぼ同じことを行っている。配置時にメモリを割り当て、削除の際にはメモリを解放する。汎用的なJavaプログラムではなくキャッシュを実装しているから実現できているのだ。DirectByteBuffersは割り当てには時間がかかるが、利用時にはとても速い。したがって、必要なメモリをすべて起動時にオペレーティングシステムから確保しているのだ。
BigMemoryの肝となる部分であり、多くの人が最初理解しづらいと感じるところは、どのようにしてオブジェクトが既に利用されていないと判断して、関連するメモリを解放するのかという点だ。キャッシュに関して言えば、これはいたって単純だ。Mapに対する操作は、putとget、removeだ。putのタイミングでメモリを割り当て(malloc)、removeのタイミングでメモリを解放(free)するのだ。私たちは、これを実現するために、よく知られたコンピュータ・サイエンスのアルゴリズムと独自のプロプラエタリの拡張を組み合わせてメモリ・マネージャを実装している。
どのような利用方法(読み取り専用、大部分が読み取り、読み取りと書き込みが併存)でBigMemoryがアプリケーションのパフォーマンス改善に役立つのかという問いに対して、Ari氏は次のように答えた。90％が読み取りで10％が書き込みという一般的なシナリオでも、読み込みと書き込みが50％ずつという書き込みが激しいシナリオでも、良好なパフォーマンス結果が得られた。その理由はキャッシュがプロセス内にあるからだ。分散キャッシュでは、読み取り専用であることが重要だ。頻繁に利用される部分を、ネットワーク越しに取得しなければならないその他の部分より格段に早く読み取ることができる。
InfoQ:BigMemoryソリューションの制限はなんですか？
純粋なJavaでできているという事実から、すべての一般的なJVMやコンテナで利用可能である。従って明確な制限はない。見つけ出すことができた最大のメモリの筐体(384GBメモリ)でテストを行っており、350GB以上でもパフォーマンスはリニアに伸びており、目立った遅延は発生していなかった。
ユーザに強調したい唯一の制約は、BigMemoryに格納するためには、オブジェクトはシリアライズされなければならなという点だ。キャッシュに格納されるたぐいのデータにとって、これは大きな問題とはならない。
オブジェクトがシリアライズされると、Javaのヒープに戻して利用可能にするまでに、デシリアライズされなければならない。これはパフォーマンス上のオーバーヘッドになる。従って、ガベージコレクションがない場合には、BigMemoryはヒープ上のストレージよりも遅い。しかしながら、次の層で利用可能なストレージ(ローカルディスクやネットワークストレージ、RDBMSのようなレコードのもともとのシステム)よりはずっと速い。
シリアライズ、デシリアライズのパフォーマンス・オーバーヘッドは多くのユーザが考えているよりはずっと小さいということは述べておくべきだろう。BigMemoryはバイト・バッファに最適化されており、標準的なJavaシリアライゼーションを使ったオブジェクトのシリアライズに組込の最適化機構を備えている。例えば、アルファリリースとGAリリースの間では、複雑なJavaオブジェクトで倍のパフォーマンス、バイト配列(これはTerracotta Server Arrayがデータを格納する方式でもある)で4倍のパフォーマンスの差がある。カスタムのシリアライゼーションをもちいれば、さらにオーバーヘッドを軽減させることが可能だ。
アプリケーションでBigMemoryを利用するアーキテクトや開発者が気にしなければならないベストプラクティスや落とし穴が何かあるかとInfoQは尋ねた。Ari氏は、成功しているビジネスアプリケーションはどれでも拡張性の制約に直面していると語った。キャッシュを利用することは、もっとも混乱を引き起こさず、もっとも容易に実装可能なソリューションだ。さらに、いまはキャッシュ用のクラスタを用意する必要すらない。
ベストプラクティスとしては、パフォーマンス・アーキテクチャを新たな視点で見直して、巨大なインメモリ・キャッシュの利点を享受できないかを確認してみることがあげられる。BigMemoryを利用すれば、アーキテクトはサーバとプロセス集約度をJavaの制約に縛られることなく要件に最適化することができる。
もっとも大きな落とし穴は、大半の人が既にJavaの制限に最適化してしまっていることだ。例えば、大部分のEhcacheユーザは、まだ32ビットJVM上で実行している。32ビットJavaは、OSによって異なるが、2から4GBのアドレス空間を持つ。従って、これらのユーザはJavaを使って大量のメモリを利用することをあきらめているのだ。おそらく、これらのユーザはRAMが少ししかのっていないハードウェアで実行しているのだろうから、BigMemoryを使って100GBのインプロセス・キャッシュを利用しようとすれば、(現在では安いものではあるが)新しいハーウェアを購入しなければならない。
InfoQ:Ehcacheフレームワーク一般とBigMemoryに特化したそれぞれの将来のロードマップを教えてもらえませんか。
コードネームがFreo(オーストラリアのフリマントルのニックネーム)であるEhcacheとTerracottaの次のリリースに取り組んでいる。順調に進んでおり、今月にはベータリリースを予定している。一連の機能拡張およびパフォーマンスの改善を含める予定だ。ひとつの例としては、Ehcacheユーザがデータベースを検索するように検索を行えるEhcache Searchがある。Ehcache Searchのアルファリリースおよび、ひとそろいのドキュメントは既に利用可能だ。
BigMemoryに関しては、利用方法にそった最適な設定をよりよく理解できるようなツールといった実践的な機能拡張とともに、パフォーマンスの改善に継続的に取り組んでいる。