11: 応用編 2: アプリ固有のパフォーマンス計測をしよう - New Relic を使ったアプリケーションのパフォーマンス監視入門

「New Relic を使ったアプリケーションのパフォーマンス監視入門」第11回。応用編その２です。

今回で最後。これまでは、コード自体には何もしないで New Relic エージェントが収集したパフォーマンスデータで分析を行う方法を紹介していきました。

今回は、コードに計測ポイントなどを追加することで、より、サービス自体のパフォーマンス分析や調査が効率良く行える方法を紹介します。それが、カスタム属性とカスタム計測です。

似たような名前だが、機能は全く異なる機能です。

カスタム属性は、New Relic がデフォルトで収集データ(処理時間とか）に加え、任意のデータ(キー/値)を New Relic に送信できる機能。例えば、マルチテナントの EC ストアであれば、ストアIDをカスタム属性に追加することで、ストアごとのレスポンスの比較やスループットの比較なども行える。

カスタム計測は、トレースディテールで表示される計測ポイントを追加できます。トレースディテールはメソッド単位までの粒度ではないので、そこにあるメソッドをカスタム計測として追加すると、そのメソッド単位で計測できるようになる。（これは文字で説明しづらいので、後でスクリーンショットを見てもらえればイメージがすぐにわかると思う）

カスタム属性

上の説明で、既存のデータに加えて任意のデータを付加できると書きましたが、それをどのように使うかというと、APM ではあまり、利用シーンはありません。(なぜなら、APM は決められた形式のデータしか表示できない UI のため）では、どうやってカスタム属性を活用するかというと、それが、New Relic Insihts です。

カスタム属性を追加することで、例えば、ストアごとのパフォーマンス比較や特定にユーザーのトランザクション一覧とそのパフォーマンス情報の取得。遅い検索条件の特定など、デフォルトで収集したデータだけではできない様々な角度からのパフォーマンス分析が行えるようになります。

追加方法

カスタム属性を追加するには、New Relic が用意している API を各アプリ内で呼出します。API は言語によって異なるので、ここでは Ruby の例を示します。

::NewRelic::Agent.add_custom_attributes({ store_name: current_store.name })

Ruby 以外の言語の API はこのページをから確認してください。

New Relic Insights を使ったパフォーマンス分析

６回目の「基礎編 2: アプリ監視でやっておくべき３つの設定」にて、Apdex の閾値を求める際に、NRQL は多少説明していますので、それを前提に説明していきます。NRQL が分からない方は、先にそちらの記事をご覧ください。(または、SQL みたいなものだと思ってもらえればそれでも大丈夫です）

上記で store_name をカスタム属性として追加した場合は、以下のような NRQL が作れます。

ストアごとの平均処理時間

select average(duration) from Transaction facet store_name

ストアごとのトランザクション数の割合

select count(*) from Transaction facet store_name

特定のストアごとのパフォーマンス情報

select max(duration), max(databaseDuration), average(duration), average(databaseDuration) from Transaction where store_name = 'ストア名'

**ストアごとの平均処理時間の時系列チャート

select average(duration) from Transaction TIMESERIES  facet store_name 

このように１つ属性を追加しただけでも、非常に様々な情報が取得でき、分析できることが分かってもらえたと思います。

NRQL アラートにも使える

今回の連載では紹介していませんが、アラートの一つの機能として、NRQL を使ってアラート条件を作成できる機能があります。それが「NRQLアラート」です。

その名の通り、NRQL の結果を値として、他の静的な閾値のアラートと同じように指定した閾値を NRQL の結果が越えた場合にアラートを出すというものです。

この場合、NRQL を作成する注意点として、NRQL が単一の数値を返すものでなければならない。ということです。上記の例みたいに、複数の数値や時系列データを返す NRQL は使えません。

例えば以下のようなものとなります。

ストアAの平均レスポンスタイムを返す NRQL

select average(duration) from Transaction where store_name = 'ストアA' 

NRQL アラートは、他のアラートと同じく、New Relic Alerts から設定します。詳しい設定手順や例は「NRQL アラート: どんな項目もアラート条件として扱える最強のアラート設定」をご覧ください。

APM カスタム属性を確認できる場所

とはいっても、APM でもカスタム属性を確認できる場所が2つあります。

トレースディテールのトランザクション属性欄

１つ目は、トレースディテールのリクエスト情報欄です。トレースディテールは個々のリクエスト情報です。そのリクエスト内容(ユーザーエージェントなど）を見ることができます。カスタム属性として追加した情報はここに表示されます。

カスタム属性を追加しておくことで、トランザクションのボトルネックの調査に役立つかもしれません。

エラープロファイル

エラー分析機能の１つであるエラープロファイルは、未キャッチ例外が発生したトランザクションと正常なトランザクションの差を利用して、エラーの根本原因を効率良く行えるようにサポートする機能です。

カスタム属性を追加しておくと、その属性も差の比較対象になります。そのため、ストアIDをカスタム属性として追加していた場合に、特定のストアだけ例外が発生し易い傾向にあるといった情報が表示されるかもしれません。

エラー分析機能についてはここでは詳しく説明していないので、知りたい方はここをご覧ください。また、エラープロファイルについてはここをご覧ください。

カスタム計測(Custom instrumentation)

トレースディテールを見ていて、このDB処理は具体的にどのメソッドで呼ばれているのかわかりづらいことがあります。特に処理が深い場合や何度も呼び出されるような処理になるとなおさらです。そのような場合にカススタム計測を使うと、トレースディテールの計測ポイントを追加できます。これによって、そういったわかりづらさを解消できます。

見てもらった方が分かりやすいので、まずはカスタム計測を追加する前と追加した後のスクリーンショットをご覧ください。

カスタム計測を追加すると、トランザクションの処理の内訳に追加したカスタム計測が、カテゴリ Custom として追加されます。これによって、追加した箇所のパフォーマンスが一目で分かります。

次に、トレースディテールを見てみます。

追加前には、コントローラーが呼ばれた後にひたすらDB処理がフラットに大量に並んでいます。これだと、どの処理がどのメソッドで呼ばれたのか調べづらいですね。そこで、カスタム計測を３つメソッド定義に仕込みました。すると、そのメソッドごとにネスト構造になって表示されました。追加前と比べると、かなり分かり易くなっていることがわかると思います。

このように、フラットな呼出しを階層化することでデバッグしやすくするのがカスタム計測です。

カスタム計測の追加方法

上記で実際に追加したカスタム計測は以下のようになります。上は Ruby アプリなので、Ruby の例となります。Spree::Order モデルの next、update_totals、update! メソッドに対してカスタム計測を追加しています。ただこれだけです。非常に簡単ですよね。

Spree::Order.class_eval do 
  add_method_tracer :next
  add_method_tracer :update_totals
  add_method_tracer :update!
end

言語ごとにカスタム計測の追加方法は異なりますので、具体的な方法は「カスタム計測の実装」に載っていますので、そちらをご覧ください。

注意点として、カスタム計測を追加すればするほど分かりやすくはなりますが、同時に負荷も上がりますので、そのバランスはとるようにしてください。

トランザクション名の変更

APM の計測単位はトランザクションです。言い換えると、Controller 単位と言ってもいいでしょう。そのため、例えば、URL 単位では分かれていても、ルーティングの設定では１つのコントローラーで扱っていたり、入り口は１つのコントローラーだけど、実際は内部でパラメーターによって全く違う処理に分岐するみたいなこともあるでしょう。その場合は、同じ１つのコントローラーでも分岐によってパフォーマンスは全く異なるといったことがあります。そういう場合でも、１つのトランザクションタイプなので、平均すると実体がよくわからないパフォーマンスを表していることになります。

そういった場合に備えて、トランザクション名を変更する機能が New Relic にはあります。

これを使うことで、例えば、パラメーターの値でトランザクションを変更することで、別々のトランザクションとしてトランザクション一覧等で扱うことができるようになります。

トランザクション名の変更方法

また Ruby の例ですが、Ruby で書くと以下のようになります。以下は、注文状態ごとにトランザクションを分けています。(この場合、#{new_relic_name} はオリジナルのトランザクション名を指します)

NewRelic::Agent.set_transaction_name("#{new_relic_name} - #{order.state}")

こうすると、New Relic APM のトランザクション一覧では以下のように表示されます。

xxxController#update だったものが、xxxController#update - payment と xxxController#update - address に分かれて表示されるようになりました。

こういう風に複数の責務を担うトランザクションのパフォーマンスを分離して把握したい場合に、この方法は役に立ちます。

言語別トランザクション名の変更方法

• Ruby
• .Net
• Java
• PHP
• Python

まとめ

以上で、「New Relic を使ったアプリケーションのパフォーマンス監視入門」と題した一連の掲載は終わりとなります。全体は「目次: New Relic を使ったアプリケーションのパフォーマンス監視入門」をご覧ください。