Dev Portal Thumbnail Resources (9).jpg

New Relicモニタリングをレベルアップしよう

September 28, 2023 1 分で読めます
アクイアのサブスクリプションに無料で付与されるNew Relicの利活用をワンランクアップするヒントをお伝えします。
Dev Portal Thumbnail Resources (9).jpg

アクイアのサブスクリプションには、アプリケーションパフォーマンスモニタリング(APM)用のNew RelicのProアカウントが無料で付属しています。まだお試しになっていない方は、今すぐProアカウントを取得してください。

New Relicのインターフェースや、アプリケーション固有のパフォーマンス属性に慣れるには時間がかかるかもしれませんが、臆する必要はありません。本記事では、New Relicでできることを説明し、New Relicモニタリングをより活用するために、今日から実行できる4つの簡単なヒントをご紹介します。

APMの概要

New Relicの管理画面のメニューにあるAPM & Servicesページは、New Relicを使い始めるのに良い場所です。アプリケーションの健全性を全体的に把握できる4つのグラフが表示されます。

  • Web transactions time
  • Throughput
  • Errors
  • Apdex score


この中でも主要なグラフである Web transactions time から見ていきましょう。デフォルトでは、直近30分間のアプリケーションの活動が表示されますが、レポートウィンドウを調整することで、24時間、3日間、12か月など、長い期間を表示することもできます。

Image
newrelic1.png

ほとんどのアプリケーションでは、Webトランザクションの時間は平均1秒(1000ミリ秒)以下であるべきです。高パフォーマンスのアプリケーションでは、500ミリ秒以上のレスポンスタイムが達成可能ですが、Drupalサイトのアーキテクチャやアプリケーションのカスタム機能に依存するところがあります。

アプリケーションが健全かどうかを知るために

Web transactions timeグラフとThroughputグラフを比較してみましょう。通例として、スループットが大幅に増加しても平均レスポンスタイムは同程度であるべきです。言い換えると、アプリケーションが1時間あたり処理するPHPリクエストが5,000件であろうが10,000件であろうが、アプリケーションは停滞しないはずです。つまり、グラフのトレンドラインは比較的均一なはずです。

グラフに劇的な上下の変動が見られたら、APMデータを掘り下げて変動の根本的な原因を探ります。もしかしたら、アプリケーションに遅い関数呼び出しや重いCronプロセスがいくつかあり、それが平均値を引き下げているのかもしれません。一方、スループットが増加したときだけレスポンスタイムが増加する場合は、キャッシュが不十分であることを示している可能性があります。

少し練習すれば、これらのグラフをざっと見るだけで、現在の最適なパフォーマンスのベースラインを特定できるはずです。トレンドラインが比較的平坦でヘルシーに見える期間を特定するまで、レポートウィンドウを調整します。これはつまり、現在のベースラインを表します。

Apdexとは?

あなたのアプリケーションのビジネス目標は何ですか?見込み客を生み出すことですか?タスク完了までの時間を短縮することでしょうか?どのようなビジネス目標であれ、アプリケーションのパフォーマンスを長期的にモニタリングし、改善を目指すべきです。その目標を達成するために、Apdexスコアを活用できます。

Apdex(Application Performance Indexの略)は、数多くの技術的なデータポイントを抽出し、1つのユーザー満足度スコアとして表す業界標準の手法です。スコアの1.0は、アプリケーションのユーザーの100%が 満足(Satisfied) していることを意味します。Apdexの用語では、0.5以下のスコアは、ユーザーが 不満(Frustrated) を感じていることを意味します。0.7という中途半端なスコアは、ユーザーがアプリケーションのパフォーマンスを 許容(Tolerating) していることを示していますが、これはパフォーマンスに改善の余地があるとも見て取れます。

Apdexの課題の1つは、同じアプリケーションが2つと存在しないということです。New RelicのデフォルトのT値(=閾値)は、すべてのPHPアプリケーションが動的なリクエストを処理するのに平均0.5秒かかると想定しています。これはあなたのアプリケーションにとって現実的ではないかもしれませんので、実際の本番データを使ってT値を調整する方法を紹介したいと思います。

ヒント1:Apdexスコアを調整する

Apdexスコアが成功の指標として意味のある指標となるよう、T値を調整します。これを行うために、対象アプリケーションのApp IDを取得します。New Relic管理画面にアクセスして、左メニューから APM & Services をクリックして、リスト内にある対象アプリケーションの横の「…」をクリックして See metadata & tags をクリックします。これでApp IDを確認できます。

App IDをコピーしたら、管理画面の左メニューから Query Your Data を選択します。以下のクエリを入力します。App IDを必要に応じて書き換えてください。

select percentile(duration, 70) from Transaction where appId=<AppId> since 12 hours ago


この計算式は、アプリケーションの70%のパーセンタイルデータを使用して、Apdexスコアである0.85をもたらす新しいパフォーマンス閾値を計算するものです。新しいT値が生成されたら、以下のスクリーンショットを参考に、APM & Services の各アプリケーションの画面にあるメニューのSettings項目の Application をクリックして、Apdex Tの値を更新して計測を完了します。

Image
newrelic2.png

数日後にNew Relicを開いて、Apdexスコアがグラフの0.85付近で推移しているかを確認してください。そうなっていない場合は、ヘルシーな時間枠がApdexスコアである0.85を反映するまで、パラメータを変えて計算をやり直してください。

Apdexを調整する際、改善の余地を残すことは問題ありません。ここでの目標は、改善を測定し、後退を防ぐことです。Apdexの平均点が数週間、あるいは数ヶ月かけて向上していくのを見るのは、非常に喜ばしいことです。アプリケーションの変化やビジネスの期待値を反映させるために、例えば年に1度の頻度でApdexの再調整を検討してください。

ヒント2:パフォーマンスモニタリングの設定

アプリケーションのオーナーとして、ユーザーがいつイライラしているかを知る必要があります。 Apdexスコアはパフォーマンスための優れたプロキシです。というわけで、アラートに使用してみましょう!

左メニューの Alerts & AI ページに移動して、サブメニューにある Alert Conditions & Policies を選択し、New alert policy をクリックします。モニターに Apdex と名前を付けて、他はデフォルトのままで Create policy without notifications をクリックます。次の画面で出てくる Create a condition をクリックして、下の図のように APM を選択します。

Image
newrelic3.png

さらにいくつかの画面に遷移した後、Define thresholds(しきい値の定義)にたどり着きます。下の図では、Apdexのスコアが0.5を下回る状態が5分以上続いた時にアラートが発動するように設定しています。

Image
newrelic4.png

New Relicにはすべてのインシデントが記録されているため、効果的なアラートを設定することで、過去のパフォーマンスを確認し将来の最適化に役立てることができます。

ヒント3:アップタイム監視の設定

これは非常に簡単です。New Relicのpingモニターは、世界中の複数の場所からあなたのサイトをチェックします。あなたのサイトは常に応答しているのが望ましい状態です。New Relicはアプリケーションのアップタイムを日次、週次、月次で計算します。CSV形式でレポートをダウンロードしてチームで共有することもできます。

左メニューから Synthetic Monitoring を選択します。Create monitor をクリックして、モニターの種類として Ping を選択します。最後に、アクイア上でホスティングしているアプリケーションのURLを入力します。

注:オリジンのホスト名を入力することをお勧めします。アクイアは、https://[docroot].prod.acquia-sites.com というアクイアのデフォルトドメインが利用できます。バニティドメインを入力することもできますが、CDNやサードパーティのプロキシを使用している場合、基本的なPingチェックではアップタイムが正しく表示されないことがあります。例えば、CDNがキャッシュされたホームページを提供しているにもかかわらず、Drupalサイトが実際に応答していない場合などが想定されます。

ヒント4:Deploymentの活用

New Relicのグラフでは、コードをデプロイしたタイミングに印をつけて、カスタムコードの変更とアプリケーションのパフォーマンスの変化を関連付けることができます。もちろん、このデータを利用して、パフォーマンスや最適化のチケットに費やした開発者の時間のビジネス価値を実証することも可能です。

下の例では、Apdexスコアのグラフにグレーの点線が見えますが、これがDeploymentです。コードを連続してデプロイする間に、Apdexのスコアが青(=Excellent)から緑(=Satisfied)、そして最終的には黄色(=Tolerating)まで下がっていることが分かります。優れたモニタリング戦略を持っていない場合、手遅れになるまでこのような後退に気づかない可能性があり、アプリケーションのパフォーマンス低下がビジネスに大きな問題を引き起こすことになります。

Image
newrelic5.png

マーカーをデプロイするにはいくつかの方法があります。New Relic CLIを使用する、PHPでカスタムスクリプトを実装する、または単純にNew RelicモジュールをDrupalのコードベースに追加して、サイトの構成が変更されるたびに自動的にDeploymentをセットすることもできます。

良いモニタリングライフを!

元記事:Level up your New Relic monitoring

関連記事

全て表示する