【New Relic】New Relicによるデータ収集の仕組み

こんにちは。SCSKの井上です。

この記事では、New Relicを導入する前に、New Relicで収集されるデータの内容と、その構造について解説します。あわせてセキュリティ面にも触れています。New Relicのデータ収集の仕組みを理解する際の参考になれば幸いです。

はじめに

New Relicを導入前に「どんなデータが収集されるのか」、「そのデータはどのように扱われるのか」、「セキュリティは安全なのか」といった疑問をもつ方もいると思います。私もその一人です。New Relicがどのようにデータを収集・管理し、安全性を確保しているのかを解説します。

 

New Relicで扱うデータ

システムの状態を表すデータは、オブザーバビリティの分野では「テレメトリデータ」と呼ばれます。New Relicで収集されるテレメトリデータは、次の4種類に分類され、頭文字をとって「MELT」と略されています。

メトリクス(Metrics)

アプリケーションやシステムがどんな状態かを定量的に数字で表したものになります。New Relicでは、このメトリクス情報を使ってシステムがどんな状態かを時系列で調査・分析することができます。

メトリクスには2つのタイプがあります。

集計メトリクス:一定の時間帯で起きたことをまとめた数字 (例:1分間のエラー回数)

ステータスメトリクス:ある瞬間の状態を表す数字(例:現在のCPU使用率)

メトリクスを収集することで、システムのパフォーマンスやリソースの異常を発見することができるため、重要なデータの一つと言えますね。

イベント(Events)

アプリケーションやシステムで何が起きたのかを記録したものになります。例えば、APIの呼び出しやユーザがログインをしたなど、事象や行為を指します。New Relicではエラーに関わらず発生した出来事をイベントとしてJSON形式で表現したKey-Valueで記録するため、リアルタイムで何が起きたのかを調査・分析することができます。エラーが発生した、デプロイが実行した、ユーザがファイルをダウンロードしたなど、”いつ”、”何が起きたか”を指すイベントになります。

エラーだけが記録されている場合でも、「いつ」、「どんなシステム変更があったか」も一緒に記録されていることで、原因の分析がずっとしやすくなりますね。

ログ(Logs)

アプリケーションやシステムが出力するメッセージになります。New Relicでは、ログ単体で調査というよりも、他のデータと組み合わせることで、原因特定を迅速化することに使われます。例えば以下のような使い方があります。

イベントデータ:あたらしいバージョンがデプロイした

ログ     :デプロイ直後からログにエラーが急増している

メトリクス  :レスポンスタイムが悪化している

上記のデータを組み合わせることで、デプロイした内容に不具合があったことが明確にできますね。

トレース(Traces)

アプリケーション内でリクエストがどのように流れたかを記録したものになります。複数のサービスやツールが連携して1つのサービスを提供する場合、その処理は複数のシステムやアプリケーションを経由します。この一連の流れを「トレース」と呼びます。一つのトレースは全体の処理時間や経路を把握するために、一意のトレースIDが付与されます。また、トレースは複数のスパンで構成されます。スパンとは「DB参照」、「API呼び出し」など、トレースを構成する個々の処理単位を指します。これらのスパンにも一意のスパンIDが付与され、それらが組み合わさって、1つのトレースを形成します。

 

上記の図を例に例えると、ユーザがログイン情報を入力し送信後、認証サーバからレスポンスを返答する一連の流れを指します。スパンは、ログイン情報入力後、 サーバーが処理 → DBで認証 → セッション生成 など、レスポンスを返答するまでの間の個々の処理を指します。 この一連の流れを追跡・記録することで、どこで遅延や問題が発生したかを把握できますね。New Relic では分散トレーシングのデータ量を抑えるためにサンプリングを行い、全スパンではなく実際にはヘッドベースサンプリングと適応サンプリングを用いてスパンを収集します。

 

集めたデータはどこに集約される?

New Relic へデータを送信するには、エージェントと呼ばれるプログラムをオンプレミスサーバやクラウド環境にインストールする必要があります(一部、エージェントなしで収集できるデータもあります)。収集されたデータは Telemetry Data Platform の NRDB に集約されますが、どのデータを送信するかはエージェント側の設定で制御できるため、すべてが自動的に収集されるわけではありません。NRDB は New Relic 社が管理するバックエンドシステムで、テレメトリデータ(メトリクス、イベント、ログ、トレースなど)を保存・検索・分析するためのデータベースです。数十万アカウントから送られる膨大なデータを処理するため、非常に大規模なインフラが稼働しています。

 

 

データの容量の見方

クラウド環境はコストの変動が激しいため、気づかない間にNew Relicへのデータ転送量が増えていた、ということもあります。New Relicではダッシュボードでデータ量の確認やコストの上限が近づいたらアラートを出すことができます。この記事では、コンソール上でのデータ容量の見方を紹介します。

以下(左下ユーザアイコン>Manage Your Data)の図で以下のことが確認できます。データ転送量の予測を算出してくれるので、コスト管理や上限監視に役立ちますね。データ容量の減らし方については、別の記事にてご説明したいと思います。

1.過去30日間のデータ転送量、1日の平均データ転送量

2.Month-to-date:今月これまでに取り込んだデータ量

3.Projected end-of-month:月末時点の予測値

4.アカウントごとのデータ転送量

5.どの機能やリソースでどれくらいの転送量を占めているか (CSVにてダウンロード可能) 等

 

 

 

データの保管期間

保持期間を過ぎたデータは New Relic 上で参照できなくなり、その後数日以内にバックエンドから削除されます。保持期間内のデータをユーザー自身で削除することはできません。特定のデータを削除したい場合は、New Relic サポートに依頼する必要があります。現在の保持期間は、左下ユーザアイコンの Manage your data → Data Retention から確認できます。

 

 

データを扱う上での制約事項

大量のデータ検索やクエリ実行が集中すると、他の顧客の利用に影響を与える可能性があります。そのため New Relic では、データ送信量やクエリ実行数などに一定のレート制限が設けられています。一般的なシステムで API リクエストが 1 分間に数千〜数万レベルに達することは稀で、多くの環境では制限に触れることはありません。これらの制限はアカウント単位で適用されるため、全世界のユーザーが利用する NRDB の規模を考えると、非常に大規模な基盤で制御されていることがわかります。

制限にどれくらい近づいているかは、左下ユーザアイコンの Manage your data → Limits から確認できます。

 

 

データのプライバシー

利用者のデータを収集することになるため、セキュリティがどのように確保されているかは気になる点です。New Relic は GDPR や CCPA を含む国際的なプライバシー法に準拠しており、プライバシー・バイ・デザインの原則に基づいて設計されています。また、業界標準のセキュリティ監査や認証を取得し、データは通信時・保存時ともに強力な暗号化で保護されています。アクセス管理も厳重に行われているため、安全に利用できる環境が提供されています。ただし、どのデータを送信するかはユーザ側の責任となります。ログやトレースに個人情報や機密情報を含めないよう、適切な設定を行うことが必要です。New Relic のエージェントは導入環境からアウトバウンド通信のみを行い、通信に使用する ドメインやポート情報は公式ドキュメントで公開されています。そのため、これらのドメインに対して必要なアウトバウンド通信のみを許可するファイアウォール設定が可能です。

 

New Relic は、AWS PrivateLink を利用して VPC からインターネットを経由せずに New Relic へテレメトリデータを送信できます。これによりセキュリティ向上と AWS 送信コスト削減が可能になります。契約条件としてNew Relic Data Plusの契約がないと PrivateLink 経由の通信は拒否され、402 エラーとなります。現時点で4つのリージョンのみ対応しています。東京リージョンには New Relic の PrivateLink エンドポイントはありませんが、クロスリージョン接続を使うことで東京リージョンからでも利用可能になります。

 

さいごに

システム全体を可視化するためにすべてのデータを取得することは理想ですが、現実的にシステム負荷増加やデータ量が増えると重要な情報が埋もれてしまい、コストが膨大にもつながります。目的の設定や必要なデータを選んで取ることで、真のオブザーバビリティが発揮する、ということをObservability Conference Tokyo 2025のLizさんの講演を聞いて共感しました。そのためには、エラーのみ収集、遅延が発生したのものだけを記録など、導入して終わりではなく、日々のモニタリングから、”本当に必要な情報は何か”、継続的に収集対象を見直していかなければならないと日々感じています。

SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

著者について

New Relicのセールスエンジニアとして2025年1月から参画。現場で得た知見や日々の学びを活かし、New Relicの価値をより多くの方に届けることを目指しています。後発ながら、わかりやすい記事を皆様に提供できるよう頑張っています。

Masao Inoueをフォローする

クラウドに強いによるエンジニアブログです。

SCSKでは、自社クラウドと3大メガクラウドの強みを活かし、ハイブリッドクラウド/マルチクラウドのソリューションを展開しています。業界の深い理解をもとに、お客様の業務要件に最適なアーキテクチャをご提案いたします。サービスサイトでは、お客様のDX推進をワンストップで支援するサービスの詳細や導入事例を紹介しています。

New Relicソリューション運用・監視
シェアする
タイトルとURLをコピーしました