Qiita Conference 2023「開発エンジニアのレベルを上げる、”フルスタック オブザーバビリティ”でのシステムパフォーマンス改善」レポート
顧客から「アプリが遅い」と言われたけれど、十分な情報がない。ほかのエンジニアが書いたコードの意図がわからない。開発の現場ではこうした「困った場面」がたびたび発生します。
そんなときにエンジニアを救うのが、オブザーバビリティ（可観測性）プラットフォーム「New Relic」です。
New Relicにはどのような機能があるのか。どのような場面で、どう使えば良いのか。
2023年5月に開催した「Qiita Conference 2023」にNew Relic株式会社の田中 孝佳氏をお招きし、エンジニアが直面しがちな5つのユースケースに沿ったNew Relicの活用法を解説いただきました。本記事では、そのエッセンスをお伝えします。
目次
登壇者プロフィール
テクニカルサポートマネージャー
①「アプリが遅い」と言われた
New Relicは、デジタルビジネスのあらゆる重要指標を観測可能にするオブザーバビリティプラットフォームです。オブザーバビリティとは「可観測性」のことで、デジタルビジネスを構成するアプリケーションやインフラストラクチャだけでなく、ユーザー側の顧客体験までも観測できるのが特徴です。私たちはNew Relicを通して全世界で15,000以上、日本で数百社以上の企業のデジタル変革を支援しています。
今日は開発エンジニアを対象に、New Relicを活用できるユースケースを5つ紹介します。
1つ目のユースケースは「Webアプリが遅延している」というものです。エンジニアの皆さんは「アプリが遅いから直して」と言われることがよくあるでしょう。しかしこれだけでは情報不足で、どこから手をつけていいかわからない状態です。
このようなときにNew Relicを使えば、どのように遅いのか、何が原因で遅いのかまで調べられます。一番大きいチャートはWebトランザクションタイム、つまり1リクエストあたりの平均所要時間の変化をあらわしています。今回の場合は、すでにレスポンスの遅延が発生していることがわかります。さらに95%ではそれほど変化がないものの、99%にすると変化が目立つことから、少数のリクエストが遅延したのではないかという仮説が立てられます。このようにNew Relicなら単に「遅い」というだけでなく「どのように遅いのか」がわかり、問題を正しく把握できるのです。
では、なぜ遅くなっているのかをもう少し詳しく見ていきましょう。チャートをよく見ると、いくつかの色に分かれていますね。水色がJava アプリケーションのコードそのものの処理にかかっている時間、緑色がこのアプリから呼び出した別のアプリの処理が完了するのを待っている時間をあらわしています。今回は水色は変わらず緑色だけが増えていることから、呼び出し先の待機に時間がかかっているようです。
そうなると、どの呼び出し先が遅いのかを知りたくなりますね。External servicesというものを開くと、呼び出し先ごとの時間変化がわかります。今回の場合は5つの呼び出し先の中で、緑色の「Plan service」というアプリを呼び出した時の待機時間が長いことがわかります。さらに「Plan service」をクリックして開くと、今度は緑色はほとんど変わらず、水色と橙色が大きく変わっています。遅延の原因はデータベース呼び出しにあるのではないかと考えられます。
どの場所のどのような種類の処理で遅くなったのかをさらに詳しく見ていきましょう。Transactionsというところを見てみましょう。
APIエンドポイントごとにWebのMVCで作られたアプリなら、コントローラーごとに処理の遅延状態を見ることができます。今回の場合は、緑色の「App＼Http＼Controllers＼GetPlansController@getPlans」で特に時間がかかっていますね。この部分をクリックして開くと、その1件の処理において、どこで時間を要したかがわかります。今回はデータベースのところで一番時間を要しているので、おそらくここが原因でしょう。
さらにデータベースページというところを見ると、呼び出したデータベースへのSQLがわかります。どのSQLでどのくらい遅かったのかがわかるということです。外部のウェブサービスを使っている場合には、どのウェブサービスを呼び出したときに遅かったのかというところまで調べることができます。
このようにNew Relicなら問題の発生確認、特定、そして原因の特定までをワンストップで行い、スピーディーな問題解決を実現します。
エラーを収集して種類ごとに確認できるのはもちろん、任意のエラーグループを登録しておけば、それに沿って自動でエラーをまとめることも可能です。さらにエラーグループごとに影響を受けたユーザー数を計測して表示することもでき、どのエラーから修正すべきかがすぐにわかるようになっています。
②コードを修正したい
このように原因がある程度わかってくると、対応するコードを見てもう少し詳しく調べたり、コードを修正したりしたくなります。こうしたケースに備えて、「New Relic CodeStream」という機能があります。
エラーの発生原因を総合開発環境（以下、IDE）で調べるには、エラーの詳細画面で表示されるスタックトレースを見ながら該当箇所を開きます。しかしこの方法ではバージョン情報を突き止めてそれに対応するコードをチェックアウトし、エラーのクラス名とスタックトレースで出てくるクラス名・メソッド名から該当するコードの場所を開くという手間がかかります。
その点、New Relic CodeStreamはボタンをクリックするだけで該当のメソッドを開くことができます。
New Relic CodeStreamを使えば、IDEをメインで使って開発している時にも、New Relicで観測したメトリクスを表示できます。IDEで作業しているとコードのパフォーマンスを確認する機会はなかなかないと思いますが、New Relic CodeStreamを入れているとアプリケーションのメソッドの上にNew Relicに集めているメトリクスを表示できます。
また、IDE上で関連しているサービスの一覧を見ることもできます。通常コードだけでは追いかけられない情報をIDE上で確認できる、非常に便利な機能です。
③コードの意図がわからない
New Relic CodeStreamはIDEのプラグインとして提供しており、単体としても便利な機能があります。例えばIssueやTaskの作成・管理機能です。
New Relic CodeStreamを使えば、GitHubやJIRAなどと連携してIDEからIssueやTaskの作成・管理が可能になり、修正branchの自動作成や仕掛かり中のTaskとbranchの連動もしてくれます。さらにプルリクエスト作成やレビュー、マージまでIDE内で完結するので、作業の大幅な効率化が見込めます。
また、ほかの人が書いたコードを見るとき、「なぜこのような書き方をしているのか」、「なぜここに書いたのか」と意図がわからないことはよくあります。かといってコメントに意図を書くのも、ファイルが肥大化したり表現に限界があったりと不便が多いものです。
こんなときNew Relic CodeStreamを使えば、コード上で直接ディスカッションを開始して会話が可能。IDEからクリックするだけで、過去のやり取りの経緯をそのまま確認できます。やり取りをSlackやMicrosoft Teamsなどのコミュニケーションツールに同期させたり、該当コードに関連する議論をまとめて管理したりすることも可能です。
コードを見ながら調べたものの十分にわからず、ログを確認してさらに詳しく調べたいという場合もあるでしょう。
そんなときに便利なのが、「Distributed tracing」（ディストリビューテッド（分散）トレーシング）と「Logs in Context」という機能です。Distributed tracingを使えば、リクエストが1つのサービスから別のサービスに移動するたびにデータを収集し、ジャーニーの各セグメントをスパンとして記録してくれます。さらに、Logs in Contextにより一連のトレースで発生したログを図化するのに加えて、発生したログの一覧も見ることができます。トレースとログ、あるいはエラーとログといった対応を、New Relicが自動で行ってくれるのです。
この「紐付ける」という作業自体は「Logs in Context」で以前から可能でしたが、紐付けに必要な情報を追加したり、所定のフォーマットに変換したりという作業が必要でした。さらにログを転送するときにも別のプラグインを入れる必要がありました。今はこうした作業の必要がなくなり、New RelicのAPMのエージェントが自動でやってくれるようになりました。
④脆弱性が見つかった
ミドルウェアに脆弱性が見つかったというニュースをよく目にします。たしかに脆弱性は事業に重大な被害を及ぼす可能性があり、緊急的に対応すべき事項です。しかしその脆弱性の影響を受けるプロジェクトの範囲やリスクの優先順位がわからなければ、対応は難しくなります。
このようなときに「New Relic Vulnerability Management」（脆弱性管理機能）を使えば、システムの脆弱性を自動的にスコア付け。対策の要否や優先度を判断しやすくなります。
今回なら濃い赤が一番危険性の高い脆弱性ですが、その影響を受けているプロジェクトはどれかについてもアプリケーション単位で確認できます。さらにクリックすると、そのアプリがどのような脆弱性の影響を受けていて、どのバージョンにアップデートしないといけないのかというところまでわかるようになっています。サードパーティーのソリューションと連携して、システム全体の脆弱性を管理することもできます。
⑤アクセス増の検証をしたい
本番環境で想定されるアクセス数について、アクセスを増やしても大丈夫かを事前に検証したくなりますね。こんなときNew Relicなら、検証環境でそのための情報を集めることができます。Scalabilityというメニューを開くと、リクエスト数が増えるごとにレスポンスがどう変わっていくのかがわかるようになっています。
パフォーマンス劣化などでときどきはみ出てはいますが、それを除くと大まかにゆるい右肩上がりになっていますね。この範囲では、アクセスが増えても問題ないということです。検証環境でどんどんリクエスト数を増やしていって、どこで右肩が急に上がるのかを調べることができます。レスポンスタイムだけではなくて、データベースの時間やCPUを見ることができるようになっています。
無料の学習コンテンツも充実
New Relicでは、当社のオブザーバビリティプラットフォームを活用した知識や技術の習得を支援するプログラム「New Relic University（NRU）」を提供しています。その一貫として、無料で使える学習コンテンツを多数用意しています。
具体的にはNew Relicへのサインアップやインストール手順がわかる資料の提供や、New Relicの使い方や機能を実際の画面を見ながら学べるセミナーの開催、リアルタイムで手を動かしながら学べるハンズオントレーニングの機会提供などを行っています。
さらに、New Relicについての基礎知識をはかる無料オンラインテスト「Full-Stack Observability」もリリースしました。合格者全員にデジタル認定証も提供していますので、ぜひNew Relicの機能を試して、テストを受けてみてください。そして試したことをQiitaに投稿し、発信していただきたいと思います。
- New Relic 無料サインアップ : https://newrelic.com/jp/sign-up-japan
- NRU – New Relic University : https://newrelic.com/jp/learn
- Full-Stack Observability テスト : https://learn.newrelic.com/full-stack-observability-exam-jp
2023年9月13日オフラインにて開催！ FutureStack Tokyo 事前登録はこちら
FutureStack Tokyo の詳細を見る
編集後記
今のシステムに必要なのは、監視ではなくオブザーバビリティ（可観測性）。そう語る田中さんのお言葉が、非常に印象的でした。システムで異常が起きたとき、その経緯や原因がわからなければ根本的な対応は望めません。しかし、エンジニア個人が膨大なデータを収集して万全に管理し、それを活用するのは難しいものです。こうしたオブザーバビリティの実現に必要な作業を自動化・効率化してくれるNew Relicは、まさにエンジニア必携のツール。これからもさまざまな企業のDX戦略を支える存在であり続けるでしょう。
取材／文：株式会社Tokyo Edit
イベントアーカイブ動画