テスト時に活用するObservability Platform

開発者やテスターはどうやってユニットテストや自動テストを組み合わせて本番環境にDeploymentされる製品やサービスの品質を向上させるかというのに頭を悩ませてきました。特に何かあったときに開発者がテスト環境で調査するコストが馬鹿にならないことが問題です。バグを作り込む数もすくないですし、原因特定の時間が短いというのであれば大きな問題も感じにくいですが、多くの開発者にとっては生産性が非常に重大な課題を抱えています。以前は障害調査においてProfilerというツールをいれてプログラムの動作をフルスキャンしたりしていましたが、それでは本番環境にいれることは大変かつ負荷が高いですし、原因特定はできても大きな時間を費やしていました。

そこで、テスト環境にNew Relic APMを入れることで本番環境に出す前に問題を特定フィードバックできるようになり、かつこの作業が熟練の開発者である必要がないため、機能開発に優先的に時間を割くことができるようになることです。生産性とアジリティが向上し、バグに対するエラー修正の時間だけでなく、開発者単体テストでは気づけないようなマルチスレッド問題や、負荷問題を負荷テストツールと組み合わせることによって事前に特定・修正ができるようになります。具体的には、JenkinsやCircleCI などのCI ToolとApache JMeterを代表とする負荷テストツールとObservability Platformを組み合わせることによって特定のレスポンスタイムを超えた場合はDeploymetを止め、原因を特定し修正ことで未然に本番に非機能要件（負荷）の観点で品質の低いものがDeploymentされてトラブル対応を余儀なくされるという”見えずらいコスト”の削減も可能になります。

New Relic 製品

New Relic APM, New Relic Browser, New Relic Logs, New Relic One

実装方法

• New Relic APM
  • Deployments Marker
• New Relic Browser
  • JS Errors
• New Relic Logs
  • Logs in Context
• New Relic One
  • Dashboards

• New Relic APM
  • Deployments Marker

負荷テストなどの実施に発生するエラーや遅延を特定するにはAPMが有効ですが、Deploymentした各Revisionの違いを特定できると気づいたのが今だけれども３つ前のRevisionから遅延が発生しているなどがわかるようになります。

• New Relic Browser
  • JS Errors

開発中に気づきにくいバグの一つとしてJS Errorがあります。開発者ツールなどでスクリプトデバッグしていることはあるかもしれませんが、いろいろなテスト観点でどのようなエラーが出ているのかを一括で可視化できることは大変強い味方になります。

• New Relic Logs
  • Logs in Context

New Relic Logsではログを収集できるだけでなく、APMのエラーから右上に表示されるSee LogsからNew Relic Logsの周辺ログに飛ぶこともできるようになります。テスト対象サーバーに入らないと実際の調査ができないということから開放されます。

あわせてKubernetes cluster explorerによってテスト環境のポッドとはいってもログを調べるのは悩ましいところでしたがこちらのエクスプローラーからSee LogsからNew Relic Logsに飛んで周辺ログを簡単に見ることができます。

• New Relic One
  • Dashboads

New Relic One Dashboardsにて”ほしい形”でダッシュボードを作成してエラーやDeployment起因の障害や遅延を個別に可視化することができるようになります。

たとえばError Messagesのグラフを生成するには

SELECT count(*) FROM TransactionError FACET `error.message` SINCE 1 day ago

というNRQL生成してダッシュボードに登録していただければ簡単に生成出来ます。

その他のダッシュボードの作り方やNRQLの使い方、テストするときのつかい方についてもっと知りたい場合は

下記よりNew Relic 担当者にご連絡を！