10: 応用編 1: デプロイ時や重要なトランザクションのパフォーマンス監視をしよう - New Relic を使ったアプリケーションのパフォーマンス監視入門

New Relic Advent Calendar 2017 24日目。とうとう残り２日。今日から応用編。だけど、最終日は、目次とまとめを書くので、残りの応用編はアドベントカレンダー外となるまさかの展開。

「基礎編 4: 外部サービスやVMを軸にしたパフォーマンス調査方法 」までの基礎編では、UI 上だけで完結できるパフォーマンス分析を紹介してきました。前回はサーバー監視の話でしたが、今回は APM の話に戻ります。

今までは、New Relic がデフォルトで収集したデータを元にパフォーマンス分析を行ってきましたが。より効率的にパフォーマンス分析するためには、サービス固有の状況に合わせてカスタマイズを行うべきです。今回は、APM のカスタマイズポイントを紹介していきます。サービスにあった部分をうまく取り込んで貰えればと思う。

デプロイ追跡を利用してデプロイ前後のパフォーマンスを比較しよう

パフォーマンスが低下するタイミングで一番多いと言われているのが、デプロイ時です。バグが入り込んだりとコードの変化による影響を一番受けるタイミングです。そのため、リリース後のパフォーマンスを監視し、リリース前より著しくパフォーマンスが落ちた場合は迅速に知ることができる必要があります。速く気づければ前のバージョンにロールバックし、ユーザーへの影響も最小限に抑えられるでしょう。New Relic では、デプロイ時点をマーキングし、その前後のパフォーマンスを一目で知ることができる機能があります。

この画面では、デプロイ時が各チャートの中央に来ます。(グレーのライン)よって、一目で前後でパフォーマンスが低下したか、よくなったかをは比較できます。

上のスクリーンショット上から4つ目の「/vets(GET)」を見てみると、前回は、1,390ms だった平均レスポンスタイムが、3,23ms と劇的に早くなっていることが簡単に分かります。

この画面を使うことで、パフォーマンス改善した際にそれが効果があったのか簡単に知ることができます。

Overview 画面でも簡単に確認できる

デプロイタイミングが良い点は、専用の Deployments だけでなく、メインの Overview でも確認できる点です。デプロイマーカーはメインチャートでは、青い垂直線として表現されます。

そのため、Overview を見ていれば、いつデプロイが行われたのか知ることができます。もし、青い線の後にパフォーマンスが低下しているのが分かったら、その原因が直前のデプロイでしこまれた何かである可能性が高いとすぐに気付けるでしょう。

デプロイタイミングのマーカーの付け方

デプロイタイミング自体は、New Relic はどの時点かは判断できません。よって、デプロイ時にアプリごとにマーキング(デプロイの記録)してもらう必要があります。

マーキング方法はいくつかありますが、汎用的な方法は、curl で以下の New Relic のデプロイマーカー用の API を叩くだけです。

curl -X POST 'https://api.newrelic.com/v2/applications/${APP_ID}/deployments.json' \
     -H 'X-Api-Key:${API_KEY}' -i \
     -H 'Content-Type: application/json' \
     -d \
'{
  "deployment": {
    "revision": "REVISION",
    "changelog": "Added: /v2/deployments.rb, Removed: None",
    "description": "Added a deployments resource to the v2 API",
    "user": "[email protected]"
  }
}' 

他にも記録方法はあります。気になる方はこちらのドキュメントをご覧ください。

サービスに重要なトランザクションは専用の監視、Apdex 設定、アラート設定をしよう

Transaction ページでトランザクションに関するパフォーマンスは知ることができます。しかし、ここで表示されているトランザクション全てのパフォーマンスに気を使うというよりも、サービスの中で売上やビジネスの競争上重要なトランザクションの方が、常に監視、パフォーマンスを気にしておきたいものだと思います。あまり使われないトランザクションが非常に遅くなったことよりも、検索やログイン処理が少し遅くなったことの方が問題だというケースはよくあります。

このように、特定のトランザクションを重要視してい監視する機能が、キートランザクション です。あるトランザクションをキートランザクションとして登録すると、以下の利点があります。

• そのトランザクション専用の Overview 画面ができる。
• そのトランザクション専用の Apdex の閾値の設定ができる
• そのトランザクション専用のアラート設定ができる
• そのトランザクション専用の SLA レポートがある
• (言語によって) X-Ray セッションという、トランザクションのメソッド呼出し単位のパフォーマンス計測処理が行える

キートランザクションとして登録すると、以下ように専用の画面用意されます。ここで、そのトランザクションだけのレスポンスタイムやスループット、Apdex、エラー率などを知ることができます。

キートランザクションへの追加方法

トランザクションをキートランザクションに追加するには、上のキートランザクション一覧の Add more ボタンを押す方法があります。ただ、これはその後に対象のトランザクションを選択するのが結構めんどいので、別の方法をオススメします。それが、Transactions から追加する方法です。

Transactions の一覧からキートランザクションに追加したいトランザクションを選択します。 すると、トランザクション名の横に、Track as key transaction というリンクが表示されます。(既にキートランザクションに追加済みの場合は、キートランザクションへのリンクとなります）

リンクをクリックすると、ポップアップが表示されるので、Track Key Transaction ボタンを押します。すると専用のキートランザクション画面が作成されます。

キートランザクションの Apdex の閾値の設定方法

キートランザクションごとに Apdex を設定することで、トランザクション単位でユーザー満足度を計測、監視できます。特にビジネスに重要なトランザクションはアプリ全体の閾値より厳密に設定、管理する方が良いでしょう。サイト全体では、0.5秒でいいが、検索処理は0.3秒であるべきとかの場合、検索処理をキートランザクションに登録し、閾値を 0.3秒に設定することでそういった柔軟な管理ができます。

キートランザクションごとに Apdex の閾値を設定するには、キートランザクション一覧画面で、対象のキートランザクションの一番右のギアアイコンをクリックします。すると、以下のポップアップが表示されます。

この Apdex T にの App にこのキートランザクション用の Apdex の閾値を設定します。

キートランザクションのアラートの設定方法

Apdex と同じく、キートランザクションごとにアラートの設定が行えます。アラートの設定は、以前も説明したように、画面トップの Alerts から行っていきます。

アラート条件の画面で、製品を APM (デフォルト)、条件のタイプを Key tansacation metric を選択します。

２番めの Select entities では対象のキートランザクションを選択します。

３番目のアラート条件の設定では、以下の項目から対象を選択し、閾値を設定します。

これにより、アプリ自体は正常であっても、重要なトランザクションに異常が発生した場合に、素早く知ることができます。

X-Ray セッション - スレッドプロファイル

注: この機能は現時点で、Java/Ruby/Python のみで利用可能

X-Ray セッションは対象のトランザクションに対して、スレッドプロファイルを実行できます。スレッドプロファイルは、メソッド呼出し単位レベルで、パフォーマンスを計測、確認できるものです。

X-Ray セッションは、設定したトレース数か実行時間のどちらかを満たしたら終了する。

まとめ

デプロイマーカーは少しデプロイスクリプトなどにコマンドの追加が必要だが、そこまで難しわけではないので、是非、取り入れていただきたい機能です。また、キートランザクションもビジネス上重要なトランザクションを重点的に監視する必要があるというは皆が同意する点だと思うので、これも是非、活用してもらえればと思う。