はじめに

サイロ化されたデータや組織は、業務の効率性を低下させ、結果的にトータルコストの増加につながります。本記事では、インフラとアプリのサイロによって一般的にどのような課題が挙げられているのか、そしてNew Relicを活用することでどんなメリットが得られるのか、実際の画面を見ながら紹介します！

最新のアップデートの詳細はこちら。New Relic アップデート(2023年9月)

インフラとアプリのサイロによる課題

インフラとアプリのサイロによって挙げられる一般的な課題は以下の通りです。

可視性の欠如
インフラとアプリのデータが異なるツールやDBに分散しているため、システム全体の健全性を迅速に把握するのが困難
トラブルシューティングの長期化
問題の原因を特定するために、複数のツールやログを横断的に調査する必要があり、解決までの時間に多くの工数が裂かれる
コラボレーションの障壁
インフラチームとアプリチームがことなるツールや情報を持っていると、効率的なコミュニケーションや協調が難しくなる
リソースの非効率な利用
サイロ化により、リソースやツールの重複利用や過剰利用、運用工数の増加などにより、トータルコストの増加につながる

New Relicを活用するメリット

統一的な可視性
New Relicはアプリからインフラまでの全体的な監視を提供できるため、分断された情報を1箇所で一元的に確認可能
効率的なトラブルシューティング
アプリのエラーや遅延が発生した際、その原因がインフラの問題かどうかを迅速に特定可能
コラボレーションの強化
インフラチームとアプリチーム間での情報共有やコミュニケーションを助けるUIやシームレスなオペレーションなど優れたエクスペリエンスを提供
リソースの効率的な利用
従来のリソースやツールをNew Relicで統合することにより、重複利用を排除し、運用工数が削減され、結果トータルコストを抑えることにもつながる

New Relicの活用イメージ

ここからは、実際にNew Relicの活用イメージをご紹介していきます。

インフラからアプリを見てみよう！

それでは、ホスト情報を見てみましょう。
[Summary]タブでは、このアカウントで管理している全てのホスト台数や、ホスト上で動いているアプリケーション数、現在発生しているイベントやアラートの数がタイル形式で表示されています。

画面下部にはホストごとのメトリクスがチャート形式で表示されています。

例えばホスト数が多い場合、ある程度ホストを絞って表示させたいケースがあると思います。そんな時には画面上部のフィルタ機能を活用すると便利です。フィルターバーから直接条件を入力して検索することもできますが、フィルターバーの下の[Suggested filters]でフィルターの候補を自動的に表示してくれるので、ワンクリックで条件を設定でき、フィルターバーに入力する手間を省くことができます。

それでは、OSをLinuxホストに絞ってフィルターしてみましょう。

フィルターした内容に応じて、[Suggested filters]も動的に変わっていることが分かります。更に[Suggested filters]から、アプリが[WebPortal]に関連するエンティティを抽出してみましょう。

タイルに表示されているカウントが絞り込まれたのが分かります。このようにNew Relicではインフラとアプリが関連づいているため、ホストを検索するとそのホストに関連するアプリも絞り込まれ、アプリを検索するとそのアプリに関連するホストを簡単に絞り込むことができます。良く利用するフィルターは、ビューとして保存しておくこともできるので便利ですね。

次に、メトリクスのチャートを見ていきます。ここではホストのメトリクスが並んでいますが、アプリのメトリクスを選択することも可能です。

例えば、一番右側のチャートで[Disk utilization (%)]が選択されていますが、プルダウンメニューからアプリに関するメトリクスが選択できるようになっています。ここでは、[Application response time]を選択してみましょう。

このようにインフラのメトリクスと並べてアプリのメトリクスを表示し、相関関係を確認できるようになります。

例えばCPU使用率が高いときにアプリのレスポンスが低下している、あるいはスループットやエラーレートが上昇している、といったようにインフラリソースが原因でアプリに影響を及ぼしている可能性を想定することができます。

また、インフラリソースが健全であるにも関わらず、アプリ側のレスポンスが遅くなっている場合は、アプリ側に原因がある可能性を想定できるので、原因の当たりがつけやすくなり、初動対応を早めることができますね。

アプリ側が原因である一例として、デプロイメントによる問題が挙げられます。多くの障害は人手による変更によって引き起こされます。New Relicではデプロイメントの記録をチャート上に表示することができます。これによって、アプリ側で行われたデプロイメントが、ホストリソースやアプリのパフォーマンスに影響を及ぼしているかどうかを確認しやすくなります。

デプロイメントされたポイントにカーソルを合わせると、どのエンティティに対し、誰がどんなデプロイメントを行ったのか確認できます。

また、クリックすると該当サービスの分析画面が表示され、デプロイメントの影響を即座に把握することができます。アプリ側で、エラーやログが多発していないか、関連アラートが発生していないか、トランザクションの処理時間がどれくらいかかっているかなどをサマリー画面で確認できます。更にアプリ視点で詳細を深掘りしていくには、Entity名、ここでは[Plan Service]をクリックします。

APMの画面に遷移するので、ここからどのトランザクションやトレースが遅くなっているのか、どんなエラーやログが出力されているのか、DBの処理で遅くなっているリクエストがないかなど、アプリの詳細なトラブルシューティングに繋げていくことができます。

アプリからインフラを見てみよう！

アプリ側から関連するインフラのリソース情報を確認することも可能です。
アプリ側でもインフラメトリクスのチャート上にデプロイメントの記録が表示され、いつデプロイメントが行われたのかを確認できます。

インフラメトリクスのチャートをアプリのメトリクスに変更して相関性を確認することも可能です。

上記の画面で[Infrastructure]を選択すると、ホスト画面に再び遷移することが可能です。

いかがでしたでしょうか。
New Relicでは、いろんな画面を複数立ち上げて行ったり来たりすることなく、シームレスなオペレーションを実現できます。インフラとアプリの関連性を見ながら、必要最低限の操作で必要な情報をすぐに手に入れることができる動線が用意されているので、実際に触って試してみてください！

まとめ

インフラ担当やアプリ担当は、データや組織のサイロ化によって全体像を見失いがちです。メトリクス単体で見ても何が起こっているのか分からないことも多いですね。サービスに問題が起こると、アプリ側に原因があっても、まずはインフラチームがインフラの調査を開始するというケースも多いのではないでしょうか。その場合、初動の遅れにつながったり、解決までのプロセスが長期化してしまうことになります。

本記事でご紹介したように、New Relicではインフラもアプリも同じ場所にデータが保存され、関連づけられているため、ボトルネックのあたりをつけて初動を早めることができます。また、アプリ担当もインフラ担当も共通のリソースを利用し、共通のオペレーションで、シームレスなコミュニケーションにつなげることができます。New Relicの優れたエクスペリエンスを活用し、複合的にデータを見て効率的に事象を観測していきましょう！

最新のアップデートの詳細はこちら。New Relic アップデート(2023年9月)

New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。