New Relic はアプリケーションの性能向上やユーザー体験の向上を目的とした、Application Performance Monitoring（APM）に強みを持った製品です。
APM では、メトリック・ログ・トレース・イベント情報をアプリケーションやインフラからデータとして取り込み、スループットや応答時間、エラーログなど多岐に渡るテレメトリデータを分析して、アプリケーションのパフォーマンス性能の変化を未然に把握することができます。
さて、New Relic をこれからはじめようと思っている時に、APM を使ってどうやって分析することができるのか気になるところです。
今回は、New Relic が用意しているトレーニング動画で紹介されているトラブルシューティングの一例が非常にイメージが湧きやすかったので本ブログで紹介したいと思います。
本ブログ内容は本編の動画を見てもらえれば分かりますが、ポイントを添えてご紹介していきます。
本編動画
本編についてはこちらからご覧いただくことができます。
36_複数アプリケーションをまたいでボトルネックを分析する
動画解説
パフォーマンスのボトルネックがどこにあるのかを New Relic の APM を使って、どうやって特定するのかシミュレーションしていきます。
まず最初に Services - APM の画面を開くと、テレメトリデータを収集しているアプリケーションの一覧が表示されます。
ユーザーからの問い合わせがあった場合は、フロントエンド側で何か起きていないかを確認することが多いかと思います。
ここでは、WebPortal を確認していきます。
WebPortal のサマリ画面が表示され、アプリケーション全体のトランザクションタイム、スループット、エラーレート、Apdexスコア（顧客満足度を可視化する指標）などを確認することができます。
Distributed tracing に遷移すると、トレースの時系列グラフやグループ化されたトレースの統計情報を見ることができます。
スパンの平均数が多いもの順にソートし、一番上の処理時間がかかっているトレースに注目してみてみます。このグループ化されたトレースをクリックしてドリルダウンします。
グループ化された各トレースの一つ一つが時系列で表示され、またそれらのトレースの統計情報がリスト表示されます。
時系列で表示されたトレースの中で特に処理時間がかかっているものを調査していきます。
サービス間のつながりがサービスマップで確認することができ、下の画面ではサービス内のスパン情報を確認することができます。
また、フロントエンドの WebPortal で処理時間がかかっていることに合わせて Inventory Service でも処理時間が長くなっていることが読み取れます。
さらに確認していくと、データベースアクセスが非常に遅いことが分かります。
さらにデータベースアクセスに関するスパンの詳細を見ていくと、実際のクエリの内容を確認することができ、時系列でこの処理に関する遅延が一過性のものなのか、継続して発生しているのかを確認することができます。
この結果から、時間がかかっていた処理に対して、データベースのクエリ内容を見直したり、インデックスを見直したりすることによってパフォーマンス改善につなげていくことが可能になります。
このように APM を使って、アプリケーションの全体像からサービス間のつながりを確認して、どこにボトルネックの原因となっているのかを分析することができました。
補足
今回ご紹介させていただいた動画の内容はWebで公開されている New Relic University の中で学ぶことができます。
他にも多数、具体的な内容で分析の方法が紹介されていますので、ぜひご覧ください。
まとめ
New Relic の APM を活用すると全体を俯瞰した状態変化から、効率的で素早く根本原因にたどり着くことができることが分かりました。
APM 以外にも Observability を高めるたくさんの機能がありますので、今後も紹介していきたいと思います。
21
