Terracottaは、Javaアプリケーションにおける、ガーベジコレクションがもたらすストップ問題に取り組んでいる最新のベンダだ。GCのストップ問題は、キャッシュをよく使うアプリケーションにおいて、特に問題となる。多くのコレクタは古いオブジェクトと新しいオブジェクトとの世代管理を行い、新しい世代に対しては並行処理を行う一方で、古い世代を扱う時にはストップ・ザ・ワールドが再来していた。キャッシュが寿命の長いオブジェクトをさらに多くメモリに溜め込むことで、そうしたオブジェクトを直接操作しなければならなくなった時に発生する問題が拡大される可能性がある。これに対するTerracottaの解決策が、BigMemory・for Enterprise Ehcacheである。これは、この製品のために特別に設計されたメモリ管理システムを使用する。
「今日の開発者は巨大なデータセットを扱うのに時間がかかる技術を用いています。これは例えば、ヒープの小さいVMを大量に使う場合に言えます」とは、TerracottaのCTOであるAri Zilka氏の言である。
BigMemory for Enterprise Ehcacheによって、GCチューニングという黒魔術が過去の遺物になります。企業は今のサーバが持つ能力を活用し、データセンター内で数々のサーバを統合しつつ、インメモリのデータによってもたらされる性能上のメリットを享受することができるようになるのです。
BigMemoryは、AzulのZingに対する競合と見られている。この製品も、IntelおよびAMDを搭載したサーバに対してストップのないガーベジコレクションをもたらすものだ。しかし、これら２つの製品は全く異なるアプローチを取っている。Azulのソリューションは、アプリケーションと並行して実行することが可能なガーベジコレクションアルゴリズムを提供するもので、したがってAzulのJVMを必要とする。それに対してBigMemoryはキャッシュされるデータをヒープの外部で管理することで、ガーベジコレクタの負荷を下げようとする。これはC言語で記述されたプログラムでやるようなものだ。したがって、現在キャッシュを使っていないアプリケーションはコードの変更が必要になるが、逆に現在Hibernate Cacheのようなキャッシュを使っているアプリケーションでは、JVMを変更する必要がない。
InfoQはこの製品についてより詳しく知るため、TerracottaのCEOであるAmit Pandey氏に話を聞いた。Pandey氏の説明によれば、TerracottaのEhchacheはシングルノードとマルチノードの両方をサポートしているのに対して、Terracottaを使用しているユーザの80-85%はシングルノードのキャッシュを使っているという。こういった顧客は完全な分散アーキテクチャへと飛び込む準備ができたとは感じていない一方で、スケールとパフォーマンスに関する問題は抱えている。このようなユーザに対して、BigMemoryが別の選択肢を提供することになる。
「彼らが直面しているのは、メモリやヒープに置いているデータセットのサイズを拡張しようとすると、ガーベジコレクションとパフォーマンスの問題に行き当たるということです。それが原因で、非常に小さいメモリしか使えないように制限されているのです。」
Pandey氏によれば、当初Terracottaは自分たちのJavaベースのサーバにあったGC問題を解決する必要があり、今年のはじめに独自のメモリ管理機能を開発することを決定した。これもJavaで書かれたもので、ガーベジコレクタを脇に寄せることができるものだった。その上で、これをスタンダード版Ehcacheと統合し、市場に売り出すことに決めた。Pandey氏によれば、ほとんどの顧客はヒープサイズをなんとか4GB程度にしようしていたのに対し、
Javaの世界に対しては、多くのデータをEhcacheに格納できるような機能を提供しています。100GB以上でも問題なく動作することを確認していますし、レスポンスタイム、SLA、最大GCストップ時間から見ても、上昇は見られません。これは基本的にGCによるストップをもう行っていないからです。もし、あなたのアプリケーションが1GBのヒープに対して1秒のGCを行っているとして、Ehcacheを導入してヒープにあったものをEhcacheに移せば、メモリ上であることは変わらず、100GB以上になっても問題なく動作し、GCにかかる時間もまったく変わらないのです。
以下のグラフはTerracottaから提供されたものだ。きわめて概念的なものではあるが、実際のアプリケーションを元に描かれたもので、要点は表している。
メモリ管理機能がどのように動作するかについて、私たちはもう少し議論した。これについてPandey氏はこう語った。
（前略）ガーベジコレクションは行っていません。行っているのは、他の言語で行われているのとほとんど同じ方法のメモリ管理です。管理対象をフラットな構造をしている私たちのデータ構造に入れます。したがって、世代に関する問題やその他は扱わず、こうした問題についてはアプリケーションで処理します。なんらかヒープにのせなければならないものもあり、これは通常と同じように扱われますが、ヒープサイズはきわめて小さく抑えることができます。それ以外のものを全て私たちのデータ構造に入れれば、その管理は私たちが行います。私たちが行っているのは、あるきわめて賢い演算処理で、フラグメンテーションなどの問題をどう扱うかを処理してくれます。また、これは基本的にオフラインで行われるため、アプリケーションの速度が落ちることはありません。
BigMemoryが対象とするのは、主に完全な分散アーキテクチャを構築する準備ができていない人々だが、この製品はシングルノードと同様分散キャッシュにおいても機能する。
この製品は現在β版であり、GAリリースが10月に予定されている。金額に関する情報は、リリース日の近くに発表されるだろう。