NewRelicのRPM 2はJavaのパフォーマンス監視をサポート

作者 Werner Schuster , 翻訳者 徳武 聡 投稿日 2009年10月21日

セクション

運用/インフラ,

設計/アーキテクチャ,

デベロップメント,

エンタープライズ・アーキテクチャ

トピック

Ruby on Rails ,

SaaS ,

マネジメント ,

Ruby ,

Java ,

パフォーマンス&スケーラビリティ ,

JRuby

タグ

Ruby on Rails ,

JRuby ,

Ruby1.9 ,

Spring ,

Java EE

原文(投稿日：2009/10/19)へのリンク

NewRelic RPMはとても人気のあるRuby on Rails向けのパフォーマンス監視ソリューションだ。最新のリリースであるRPM 2は、Javaアプリケーションの監視もできるようになった。

InfoQは同社のLew Cirne氏にこの新しいリリースについて話を聞いた。

InfoQ: NewRelic RPMのJavaのサポート機能はどのように動作しているのでしょうか。

新しいRelic RPMは異なるソースから情報を収集できます。RPMはアプリケーションの稼働監視と同様、詳細な分析を目的として設計されています。なので、収集した情報が適切であること、そして情報を収集して監視することによって、監視対象のアプリケーションに余計な負荷がかからないこと。このふたつが鍵になります。
例えばJMXが提供してくれるメトリクスは決して悪くはありませんが、パフォーマンスの根本的な要因を適切に診断するには非力すぎます。我々のRPMは正式なAPIを使って得られたデータをバイトコードを実行して集めたデータで補完することで、素早い問題修正に役立つ診断結果を提供します。例えば、RPMはデータベースへの遅いクエリに対処するため、自動的にSQLの実行計画を収集します。これはチームの監視と診断作業にとって、大変価値のある機能です。パフォーマンス問題の多くはデータベースに問題があるのですから。

InfoQ: 実際にbytecode instrumentationを利用してみた感想をお聞かせください。バイトコードの設定を行う他のライブラリとの間で何か問題はありませんでしたか。

RPMでは正式なAPIを使って情報の収集をし、さらにアプリケーションサーバの特定のメソッドに対してバイトコードを設定しています。RPMはロード時にクラスを設定していますが、AOPライブラリのようなバイトコードを変更するライブラリと共存しても何の問題も発生しませんでした。

InfoQ: RPMはどのようなプラットフォームをサポートしていますか。

様々なフレームワークをサポートします。Spring、Grails、そしてJEEもサポート対象です。また、RPMは標準的なJEEのコンポーネントもサポートしています。すなわちServlet、EJB、JDBC、Hibernate、Web Service invocations、POJO、JSPなどです。さらにSpringのスタック上に配置されたアプリケーションの監視もできます。
加えて、RPMはWebSphere、WebLogic、JBoss、Tomcat、Jetty そして Glassfish上に配置されたWebアプリケーションも監視できます。

InfoQ: サードパーティがRPMを拡張して、他のフレームワークにRPMを適用できるようにする方法はあるのでしょうか。

RPMはサードパーティ製のツールやメトリクスと簡単に統合できるように設計されています。RPMのAPIを使えば、他のソースからのデータを統合することもできるでしょう。また、RESTのAPIもあるので、顧客やサードパーティベンダは自分たちのソリューションにRPMの計測結果を統合できます。 Rightscale社のような会社がこのAPIを利用しています。

InfoQ: NewRelicはMRIに加えて、JRubyで作られたアプリケーションの監視もサポートし始めました。JRubyをサポートするにはどんなことが必要でしたか。

JRubyのサポートはそれほど複雑ではありませんでした。RubyとJRubyのメソッドには微妙な差異がありますが、これらのメソッドを使ってRPMは情報収集をしています。一度この差異を特定してうまく扱えるようにしてしまえば、特別なことはしなくともRPMが使えるようになりました。おかげでRPMのアーキテクチャも柔軟性を保てました。

InfoQ: JRubyのサポートとJavaのサポートは関連がありますか。

RPMが他のパフォーマンス管理ツールと比べてユニークなのは、ひとつのUIだけでRuby/JRuby、そしてJavaの監視ができるということです。Ruby/JRubyをひとつのエージェントが管理し、Javaはもうひとつのエージェントが管理しています。RubyのエージェントもJavaのエージェントもほとんど同じように動作し、同じコンソール上に診断結果を表示します。
JRubyでRailsアプリケーションを実行している顧客に対しては、Rubyのエージェントを使うように勧めています。完全な互換性がありますし、より適切な診断結果を得ることができるからです。

InfoQ: NewRelicはRuby 1.9もサポートしています。あなたの顧客の間に、Ruby 1.9は浸透していますか。

SaaS形態でサービスを提供するメリットのひとつは、文字通り何千もの稼働中のアプリケーションを見れることです。なので、我々の顧客がどのようなプラットフォームでどんなバージョンのランタイムを適用しているか、という重要な情報を手に入れることができます。我々はこのような情報に含まれる重要な点について、定期的にRailsLabというサイトの“スタックの状態”という記事で共有しています(http://railslab.newrelic.com/2009/06/11/the-state-of-the-stack-a-ruby-on-rails-benchmarking-report-10-june-2009)。

この情報から考察すると、我々の顧客でRuby 1.9を利用しているのは相対的に少ない、と思います。しかし、我々は先手を打っていきます。顧客がプラットフォームやランタイムの大規模な更新を行うとき(Rubyや、JRuby、Java、Rails、Spring、Grailsなどが新しくリリースされたとき)、市場ではその新しい環境がまだ一般的でなくても、我々は可能な限りその新しい環境をサポートしていくつもりです。

NewRelic RPMにはいくつかの価格分類がある。RPM Liteなら無料で始められる。また、EngineYardとRightScaleの顧客には特典がある。

詳細はNewRelic RPMの特徴を参照されたい。Javaのパフォーマンス監視のために、今あなたは何を使っているだろうか。

• 次へ >