jClarityがCensum 3.0をリリース

jClarifyが開発するJavaガベージコレクション解析ツールCensumがバージョン3.0に到達した。新バージョンにはSafepointログの解析機能，G1ガベージコレクタの動作を表す新グラフ，アプリケーションによるOSアクティビティの過剰使用を分析するための情報などの新機能が含まれている。

新たにG1コレクタを重視したのは，G1がJava 9のサーバ構成でデフォルトのガベージコレクタになることを考慮したものと理解できる。またSafepointのログ解析機能によって，ガベージコレクション以外のチューニングも支援する。Safepointとは，メンテナンスタスクを確実に実行できるように，JVMがアプリケーションを完全に停止させるメカニズムである。Safepointが必要とされる大きな理由のひとつはフルガベージコレクション(いわゆるSTW/Stop The Worldガベージコレクション)であり，ガベージコレクションのチューニングが注目される理由もそこにある。ただし，GCによって起こされる停止の回避方法の検討が進めば，その次には，他のSafepoint要因の検討を始める必要がある。

パフォーマンス分析やチューニングは多くのユーザにとって，奥が深く，非常に難解なテーマだ。そこでInfoQでは，jClarityでCTOとCEOを務めるKirk Pepperdine，Martijn Verburg両氏に連絡を取り，彼らからパフォーマンスに関する秘訣と誤解について学ぶと同時に，Censumがその２つを区別する上でどのように役立つのを聞くことにした。

InfoQ: パフォーマンスチューニングで問題となるのは，そのために利用可能なリソースが限られていることですが，Censumはそのようなリソースの提供を目的として開発されたのでしょうか？

Kirk Pepperdine: 実を言うと，CensumはjClarity設立以前から開発を行なっていました。アプリケーションパフォーマンスにおけるメモリ管理の重要性に対して，ツーリングの状況があまりに粗末であったため，それに対する個人的な不満が開発の動機です。ログを解析してグラフ化するフレームワークの開発についてはSunでも何度か議論しましたが，結局は(x,y)座標で表されるデータポイントになるだけだ，という結論に達していました。これでは不十分なので，必要なものを手に入れるためには，自分でそれを作る以外に方法はない，という結論に達したのです。ですから当初のCensumは，私が自分自身のために作ったツールに過ぎませんでした。BenとMartjinに出会うまで，それ以上のことはまったく考えていなかったのです。

InfoQ: “Friends of jClarity”という配布リストを作ったのも同じ理由ですか？

Martijn Verburg: もちろんです。“Friends of jClarity”は，パフォーマンスチューニングの問題を抱える開発者を支援するために，世界中のパフォーマンスチューニングの専門家が，中立的な立場でコラボレートできるコミュニティを作ることを目的で始められました。“質問大歓迎(No question is stupid)”の姿勢と，実証的証拠に裏付けられた専門家のアドバイスを提供するという理念の下，意図的にフレンドリかつオープンなリストになっています。

パフォーマンスチューニングは多くの人にとって闇の魔術です。ブログ記事やStack Overflowのようなサイトには，民間伝承や不適切で不正確な情報があふれています。jClarityの友人には，パフォーマンスチューニングの専門家や，実際にJavaあるいはJVMテクノロジに携わっているエンジニアがたくさんいます。リストで提供される回答やアドバイスは，他のどこよりもはるかに正確で適切な，最新のものです。

InfoQ: “Friend of jClarity”にはどのような人が参加できる，あるいはすべきでしょう？

Martijn Verburg: リストを参照して“Apply to join group”ボタンをクリックすれば，誰でも参加できます。何か問題があるようでしたら，サポートチーム“support AT jclarity DOT com”までEメールをください。

InfoQ: パフォーマンスチューニングに詳しくない人は，アプリを高速化するのはCPUサイクルの問題だと考えがちですが，Censumで監視対象の中心となっているのはメモリ管理に関する部分です。この例のような，パフォーマンスチューニングの初心者に共通する誤解は，他にもありますか？

Kirk Pepperdine: パフォーマンスチューニングで大切なのは，どのようなリソースがあって，利用度の低い，あるいは過剰に利用されているものが何であるかを把握することです。コアリソース(CPU，メモリ，ディスク，ネットワーク，JVMスレッドなど)を可視化し，それらの入力と出力に関するタイミングが測定できれば，ボトルネックがどこにあるのか，それに対する依存性を低減するにはどうすればよいのか，といったことはすぐに分かります。

アプリケーションパフォーマンスがCPUバウンドであるというのは，よくある誤解です。アプリケーションがJavaあるいはC#の場合，CPUによる制限を受けることはほとんどありません。私たちがこれまで見た中にも，CPUの強化や改善に多くの投資をしたにも関わらずパフォーマンスの改善が見られなかった，というユーザは少なからずありました。

InfoQ: パフォーマンスに関する議論は常に数多くありますが，パフォーマンスのよい方法にコードを書き直す人があれば，GCフラグをいろいろ試す人もいるというように，対処の方法はさまざまです。最初のステップとして推奨できるのは，どのような方法ですか？また，どの時点でCensumを使い始めればいいのでしょう？

Kirk Pepperdine: 根本的な原因が特定できていなければ，チューニング対象を知ることは難しいでしょう。Centumは根本的な原因を特定するためのツールのひとつです。原因が特定できれば，チューニングの方法はおのずと明らかになるはずです。いくつかノブを回せば解決できる問題もあるかも知れませんが，私たちの経験からは，問題となったコンポーネントのリファクタリングによって解決される場合がほとんどです。それが終わればCensumを使って，GCが問題にならないようなチューニング判断を行なうことができるようになります。

InfoQ: パフォーマンスの話をする場合，ソフトウェアが話題の中心になることが多いのですが，ハードウェアも重要な役割を果たしているのは明白です。Censumは，交換が必要と思われるハードウェア(高速なCPU，メモリ増設など)のヒントを提供してくれるのでしょうか？

Kirk Pepperdine: はい，Censumはメモリ管理の観点から，JVMベースのアプリケーションをスムーズに動作させるために必要なハードウェアの判断を支援します。例えばライブセットのサイズ，すなわちJavaヒープに常駐するデータの見積量を提供します。これによってヒープの最大サイズが決定されるので，そこから実際に必要なRAM容量を決めることができるのです。

もうひとつの典型的な問題は，メモリの割り当て率(allocation rate/一定時間内にアロケートされるメモリ容量)です。今日のCPUとメモリのサブシステムは非常に高速ですから，一般論として，ギガバイト単位のデータを毎秒アロケートしてもパフォーマンスにほとんど影響しないのですが，数バイト単位でアロケートしようとすると問題が起きるかも知れません。 ほとんどのJavaアプリケーションは，まさにこれ(数バイト単位のアロケート)を行なうので，メモリ割り当て率が極端に高くなくても，メモリアロケーションがパフォーマンス低下の大きな要因になるのです。この問題は実行時プロファイラでは見逃されるかも知れませんし，もし捕捉できたとしても，曖昧に表現される傾向のある問題です。Censumでは割り当て率が表示されるので，アロケーションプロファイラの選択や，あるいは少なくとも，実行時プロファイラの出力する情報の理解を深めるための役には立ちます。つまりはシステムが送信するかも知れない他のシグナルに，コンテキストを与えるための支援をするのです。結果としてスケーラビリティが改善され，より少ないハードウェアで多くのロードを処理することが可能になるでしょう。例えば当社のあるユーザは，特定のケースにおけるハードウェアのニーズを，それまでの80サーバから4へと減らすことに成功しています。

InfoQ: Censumはたくさんのグラフやメトリックを提供していますが，これらを定義した開発プロセスについて教えて頂けますか？利用価値のあるグラフをどのようにして決めたのでしょう？

Martijn Verburg: KirkはJavaに初期から関わって，ガベージコレクションのアルゴリズムのチューニングをしていたので，そちらの直感的知識をたくさん持っています。チームの他のメンバももちろん提案していますが，インスピレーションの大きなソースになっているのは，ユーザが抱えている疑問への回答です - そのアイデアが生み出した新しいグラフが，そのまま彼らへの回答になっているのです。

例えばあるユーザは最近，自分たちのアプリケーションに奇妙なフルGCが発生することを不思議に思っていました。調査の結果，私たちは，PermGenあるいはMetaspaceのオーバーフローがフルGCを実行させるという，稀なケースを見落としていることに気付いたのです。そこでKirkが，このようなイベントが起きた時刻を示す新しいグラフや，例えば”PermGenのサイズをXにする”というように，エンドユーザに分かりやすく，即時に実行できるような分析レポートを考案しました。

InfoQ: G1の領域メモリ管理のCensumへの実装は，従来の世代メモリ管理と比較して，どの程度難しかったでしょうか？

Martijn Verburg: CensumはJVMが作るログファイルからGCデータを読み込むため，JVMに接触することはありません。新しいデータに簡単にアクセスできるというメリットもありますが，その新しいデータを解析しようとすると問題が発生します。ここで問題になるのは，ログの形式が定義ないし標準化されていない上に，Hotspot開発者によってほとんど予告なく変更されることです。

何ヶ月か作業した結果，ログの解析が完成して，Censum内のG1の内部データモデル構築に集中できるようになりました。この時点では，メモリプールやGCの振る舞いのモデリングに関する構造体やインターフェースを十分に定義することができたので，作業は比較的簡単でした。G1のグラフの開発についても，他のコレクタのために開発済みのインフラストラクチャが数多く流用できたので，それほど難しくはありませんでした。

最も大変だったのは，意味のある分析を行なうことです。G1への移行が始まって，実運用システムからの情報が集まってきていますが，調査はまだ不十分ですし，他のガベージコレクタに比べるとログの収集も多くはありません。価値のある情報とそうでない情報を区別するには，まだデータが足りないのです。

G1の分析に関してはまだ開発途上ですが，少なくともアプリケーションのパフォーマンス不足や，このガベージコレクタに不向きな動作パターンを警告することは可能になっています。

InfoQ: CensumはSagfepointログをサポートしたことによって，GC以外のSTW停止を分析できるようになりました。JVMの動作停止を解析する場合，GCをメインターゲットにするのが一般的だと思いますが，GC以外の停止のどのような部分に注目するべきなのでしょうか？

Kirk Pepperdine: ガベージコレクションは実際のところ，JVMでアプリケーションスレッドのSafepointが発生する理由のひとつに過ぎません。アプリケーションの動作を急停止させるようなメンテナンス処理は，他にもたくさんあります。最も一般的なのは“Biased Locking Revocation”と思われますが，残念ながら現時点では十分なデータがないため，確信を持つには至っていません。さらに問題なのは，ほとんどの人がこのデータを取得可能であることを知らないため，情報の収集が行われていないことです。Censumがデータを可視化することによってこの状況が変わり，Safepointの率を低減することが可能であるという知識が広まることを願っています。

InfoQ: 今後の予定について教えてください。

Martijn Verburg: 現在はストリームバージョンを開発中です。複数のJVMをリアルタイムに監視して，現在のCensumと同じように詳細なメトリックと解析を提供できるものになる予定です。さらに，危険な事象の発生をリアルタイムで警告したり，さらには”アプリケーションが95%の確率で，２分以内にOut Of Memory Error (OOME)でダウンする”というように，発生しそうなイベントの予測もできるようになります。

Censumは当社のIlluminateに統合することも可能です。簡単に言えば，Illuminateがアプリケーションを分析して，メモリ/GC関連なのか，それ以外(ディスクI/O，スレッドのデッドロック，スレッドの不足，外部システムの応答待ちなど)なのか，パフォーマンス上のどのような問題が最も影響を与えているのかを提示します。問題がGCに関するものであれば，Centumの機能セットを利用して問題を深く解析するとともに，解決方法に関するヒントを得ることもできます。

Martijn Verburg氏はjClarityの共同創設者で最高経営責任者(CEO)である。同社はマシンラーニングを駆使して業界をリードする分析ツールを提供する，Java/JVMパフォーマンスチューニング企業である。氏はソフトウェア方法論と技術チームの最適化に関する第一人者であり，大規模な分散型組織の運営に長年の経験を持っている。主要な会議で行われるプレゼンテーションでは，氏のもうひとつの顔である“非道の開発者”として，業界の現状に果敢に挑む姿を見ることができる。氏はLondon Java Communityのリーダのひとりでもあり，“Adopt a JSR”や“Adopt OpenJDK”のプログラマを通じて，Javaの標準化活動を世界規模でリードしている。これらの貢献によって氏は，2012年のJava Championに選ばれている。

Kirk Pepperdines氏はjClarityの共同創設者で最高技術責任者(CTO)である。氏は20年近くハイパフォーマンスな分散コンピューティングに携わり，かつてはCrayなどハイパフォーマンスコンピューティングプラットフォーム上で動作するアプリケーションのアーキテクチャ設計，開発，チューニングを担当していた。現在はJavaを専門として，プロジェクトライフサイクルの各フェーズにおけるパフォーマンスとチューニングに，あらゆる面から関与している。そのJavaコミュニティに対する貢献を認められて，2006年にはJava Championに選ばれている。