こんにちは。New Relic技術担当の井上です。
この記事では、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データタイプ：メトリクス、イベント、ログ、トレース（MELT） | New Relic Documentation
集めたデータはどこに集約される？
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に問い合わせする必要があります。データの保管期間は以下(左下ユーザアイコン>Administration>Data Retention)から確認できます。
データを扱う上での制約事項
大量にデータを検索したり、アラートが飛んだりした場合、他の顧客のアカウントに影響を与える可能性があります。膨大な量のデータを処理し続けるには限界があるため、ある一定以上の制限を設けています。制限に達していないかどうかは、以下の画面(左下ユーザアイコン>Administration>Limits)で確認できます。1分間あたりでAPIのリクエストが数万レベルで実施されることは、ほとんどのシステムでは該当しないかと思います。1アカウントに対する制限なので、全世界のアカウントがアクセスしているとなると、NRDBはどれだけ大きいのでしょうか。。
データのプライバシー
利用者のデータを収集することになるため、セキュリティについてどうなっているのか、気になりますね。New RelicはGDPR、CCPAなどの国際的なプライバシー法に準拠しています。業界標準のセキュリティ監査を毎年実施し、プライバーシー・バイ・デザインの原則に従い、データは暗号化されて、アクセス管理は厳重となっているため、ユーザが安心して使えるような設計を提供しています。ただし、データの送信はあくまでもユーザの責任となりますので、ユーザ側で個人情報や機密情報を含めないようにログに出力しないまたは転送するログを決めるなど、設定とシステム構成が正しく行われていることを確認する必要があります。New Relicのエージェントは導入した環境からアウトバウンド通信のみを行います。エージェントの通信に使用するIPアドレスやポートはNew Relicの公式サイトに公開されていますので、必要なアウトバウンドに制限することもできます。
参考：New Relic によるデータプライバシー |New Relic のドキュメント
セキュリティとプライバシー |New Relic ドキュメント
さいごに
システム全体を可視化するためにすべてのデータを取得することは理想ですが、現実的にシステム負荷増加やデータ量が増えると重要な情報が埋もれてしまい、コストが膨大にもつながります。目的の設定や必要なデータを選んで取ることで、真のオブザーバビリティが発揮する、ということをObservability Conference Tokyo 2025のLizさんの講演を聞いて共感しました。そのためには、エラーのみ収集、遅延が発生したのものだけを記録など、導入して終わりではなく、日々のモニタリングから、”本当に必要な情報は何か”、継続的に収集対象を見直していかなければならないと日々感じています。
SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。
