New Relicが共同作業と統合を向上させたRPM 1.2のリリースを発表(リンク)したが、このバージョンは開発者の仕事に大いに役立つだろう。
RPM 1.2は、今日多くのRuby on Rails開発者にとって悩みの種となっている点に対処する機能を導入している。InfoQは最近行われたコンファレンスでNew RelicのCEOであるLewis Cirne氏と意見交換し、RPM 1.2の機能を直接見ることができた。Cirne氏は、こうした機能について議論する機会を与えてくれ、開発チームがどのように機能を使用するようになるのかを説明してくれた。
新機能のDeployments Analysis and Tracking（デプロイメントの分析とトラッキング）がどういうもので、この機能が開発者にとって重要なアップデートである理由を尋ねられると、Cirne氏は以下のように答えた。
開発者が新しいコードを使ってアプリケーションをアップデートする際、テスト中は通常、そのアプリケーションをステージング環境に保留しておき、その後コードにプライムタイムの準備が整ったら、運用環境にデプロイしますが、その際には普通Capistranoなどのデプロイメントツールを利用します。パフォーマンスと安定性という点からみれば、アプリケーションのライフサイクルにおいてここが最も危機的な段階です。新機能と変更がパフォーマンスに予期せぬ問題をもたらしたかもしれません。RPMは、この危機的なデプロイメントプロセスを次のような方法でサポートします。まず、開発者へのリマインダーとして「アプリケーションの新バージョンが特定の時刻に出来上がった」と各デプロイメントを「記録」するので、あらゆるグラフから、そのバージョンのデプロイ前後のパフォーマンスを即座に比較することができます。次に、各アプリケーションの重要なパフォーマンス指標をすべてアーカイブに保存しておくので、開発チームはバージョンからバージョンへの改良の進歩具合を見ることができます。
この種のツールから開発者がひらめきを得ることのできる項目のレベルは言うまでもなく重要であり、そのツールが役立つかどうかを決定することになるが、私たちが何を期待できるかについてCirne氏が説明している。
アプリケーションの新バージョンがデプロイされるたびに、RPMがそのデプロイメントのタイトル、時刻、責任者、デプロイメント以降の毎分の平均CPU使用率、メモリ使用率、アプリケーション応答時間、スループット、データベース応答変化とエラーを捕捉します。このデータを過去何回かのデプロイメントで計測した同種の統計値と直ちに比較することができます。これによりチームは、進行状況の追跡ができるようになります。また、アプリケーションのバージョンをリリースした際に、そのバージョンに重大な問題があったら、チームは直ちに確認できるようになります。RPMの掘り下げ機能を使えば、ユーザーはアプリケーションの非常に細かいレベル -- 特定のSQLクエリやコントローラーの動きなど -- まで問題を追跡することができます。
他の開発・コミュニケーションツールとの新しい統合機能を説明するにあたって、我々みなが利用する人気の高いコミュニケーションユーティリティーについて語っている。
開発者チームは通常、コーディングやテスト、デプロイメント、仕事の優先順位付け、コミュニケーションなどの作業に多数のツールを使います。チームの動きが速く、かつ締切りのプレッシャーがあるとき、ツールからツールへの移行にイライラすることがあります。通常は、1つのツールから別のツールへ何度もカット＆ペーストすることにイラつきます。RPMでは、広く使用されているツールをRPMユーザーが統合できるようにすることにより、頭痛の種を多少なりとも取り除きました。チーム内のコミュニケーション手段としてTwitterが使われることが多々ありますが、新しいRPMは、アプリケーションにインシデントが検知されたり、新規のデプロイメントが完了したりすると、メッセージ（tweet＝つぶやき）をチームのアカウントに送ることができます。「つぶやき」には、RPMの関係ページへ直接戻るリンクが含まれています。開発チームの迅速なメッセージ交換を目的として設計されたツールとして、この他にCampfireがあります。RPMは、インシデントの警告とデプロイメント通知をCampfireのアカウントにも送ります。Lighthouseはトラブルチケット発行アプリケーションです。RPMのエラーページの中に、「チケットをLighthouseにファイルする」というリンクを作成しました。このリンクをクリックすれば、すべてのエラーデータがLighthouseに送信され、新しいproblem ticket（問題チケット）が自動的に開きます。最後にCapistranoですが、このデプロイメントツールはRuby on Railsコミュニティで人気があります。RPMはアプリケーションの新しいデプロイメントを自動検知し、そしてそのデプロイメントに関する情報をCapistranoから入手します。たとえば、そのデプロイメントの責任者、デプロイされたバージョンに入れられた変更、そのバージョンで問題が起こった場合にチームに役立つであろうその他のデータなどです。
この新しいパフォーマンスデータAPIの将来と、サードパーティ開発者に機会を創出することについて。
実際すでに、このAPIの興味深い使い方を目にしました。現在APIには2つの主な機能があります -- 別のアプリケーション内からNew Relic RPMのアカウントを自動的に作成することと、トップレベルのパフォーマンスデータを別のアプリケーションもしくは環境の中に引っ張りこめるようにすることです。このAPIを最初にパブリック使用したのは、クラウド管理ツールの主要プロバイダであるRightScaleでした。RightScaleは自らのクラウド管理コンソールの中にAPIの両機能を組み入れました。そのため現在、Amazon EC2といったクラウドインフラ上にデプロイされているRailsアプリケーションを、チームが使っているクラウド管理ソリューションの中から監視できるようになったのです。この他にも、統合を開発中の顧客やパートナーがいます。アプリケーションデータをブラウザのステータスバーに表示可能にしているところもあります。クラウドホスティングの例が他にも2つ、できあがりつつあります。現在開催中のAPIコンテストで、顧客のクリエイティブな統合アイデアを奨励しています。
RPM 1.2の新機能の1つに、チームメンバーのコミュニケーションを改善するNotesというアイデアがある。Cirne氏はNotesを次のように説明している。
Notesはチーム内のより良い、より豊かなコミュニケーションを可能にすることを目的とした、実に面白い機能です。RPMアカウントにアクセスできる誰もが、そのアプリケーションのメモ（notes）を見ることができます。Notesを使えば、RPMユーザーはパフォーマンスグラフを取り込み、そのグラフが何を示すかを自分で観察して、そのグラフと自分のメモ（notes）を、共有している共同作業スペースに送信することができます。調査の進行に応じて、さらに別のグラフを取り込み、前のメモにつけ加えるといったように、データ収集と観察を続けることができます。自分のチームメートに観察をチェックしてもらい、チームメートの分析も提供してもらうようにうながすことができます。グラフ、基礎となるデータ、観察はすべて、後々利用できるように保存されます。素晴らしいトレーニングツールとなります。時間が許せば、立ち戻って再検討できる記録が存在することにより、チームがアプリケーションの振る舞いを理解するのに役立ちます。
Ruby on Railsの開発者なら、効率的なコントローラーを持ち、データベースへアクセスできることがどれほど重要か理解している。プラグインを利用している開発者に役立つ最新機能の1つにController and Database Summary（コントローラーおよびデータベースのまとめ）があり、次のように説明されている・
2つのレポートは類似しており、パフォーマンスを改善する方法を絶えず模索しているチームにとって、両方とも非常に有用です。開発者は自分自身に「パフォーマンスを改善する上で次に取り組むことができる最善策は何か」と頻繁に問いかけます。2種類のレポートがこの質問への答えを手助けします。Controller Summary（コントローラーのまとめ）は、1つのレポートの中にアプリケーションのすべてのコントローラーアクションを一覧にして提供します。RPMユーザーは、たとえば過去24時間など、タイムウインドウを1つ選択します。各コントローラーアクションに対し、次のカテゴリーで当該タイムウインドウのパフォーマンスを集めます -- コントローラーが呼び出された回数、平均応答時間、平均からの標準偏差（コントローラーに時折非常に悪い応答時間があっても、平均することによってそれが見えなくなってしまうことが時々あります -- なぜでしょうか？）、最短および最長応答時間（孤立値を提供するため）、このタイムウインドウで当該コントローラーアクションが消費した合計時間、各アクションが全体の時間に対して消費した割合。開発者はこのレポート一つから、どのコントローラーが最も頻繁に呼び出されていて、そのパフォーマンスがどうなっているかを把握することができます。Database Report（データベースレポート）は似ていますが、ActiveRecordモデルのオペレーション（データベース呼び出し）のパフォーマンスを解析することに焦点をあてています。選択されたタイムウインドウ内のすべてのActiveRecordオペレーションを表示し、合計消費時間や平均時間、スループット時間といった複数の測定基準を使ってオペレーションを分類できるようにします。すべてのオペレーションについて、昨日や1週間前の同じタイムウインドウと比較できるので、アプリケーションの変更にともなった振る舞いを追跡できます。
開発者にとって最も重要な機能は何かを尋ねると、Cirne氏は次のように語った。
経済学者のようだとは思われたくないのですが、事情によりけりです。頻繁にアプリケーションを更新するチームなら、Deployments（デプロイメント）機能をとてもありがたがると思います。私たちの顧客に、毎日再デプロイする人たちがいますが、想像してみてください。国内や世界中のあちこちに分散しているチームなら、多様な統合ツールや共同作業ツールが非常に役立つでしょう。最後になりますが、もしあなたのアプリケーションがデータベース活動を活発に行い、データベース間の巧みな相互作用に依存しているのなら、新しいDatabase Report（データベースレポート）があなたのお気に入りになるでしょう。
RPMの新リリースについてのさらに詳しい情報は、New RelicのWebサイト(リンク)で入手できる。ユーザーはRPM Liteという無料バージョンから使い始めることができるが、利用可能なバージョン(リンク)の表を参考にして、ニーズに合った最良のバージョンを見極めて欲しい。RPMはわずか2分ほどで実装できる。