無駄なデータを見つけて削減：New Relicのコスト最適化ガイド

はじめに

「New Relicの請求額が予想より高い」「データ取り込み量が毎月増え続けている」。こうした悩みは、多くの組織で共通しています。

New Relicの課金は、主に「データ取り込み量（GB Ingested）」で決まります。つまり、どれだけのデータをNew Relicに送信したかが、コストに直結するのです。無料枠の100GBを超えると、追加のデータ量に応じて課金されます。

コスト削減の基本は、「価値のないデータを見つけて、送信を止める」ことです。しかし、やみくもにデータを削減すると、必要な可視性まで失ってしまいます。重要なのは、データの価値を見極めながら、戦略的に最適化することです。

この記事では、New Relicのデータ取り込み量を可視化し、無駄なデータを特定して削減する実践的な方法を紹介します。

1. データ取り込み量を可視化する

コスト最適化の第一歩は、現状を正確に把握することです。New Relicには、データ取り込み量を可視化する専用のUIが用意されています。

1.1 Data Management UIにアクセスする

New Relicにログインしたら、ユーザーメニューから「Administration」→「Usage Summary」を選択します。この画面で、組織全体のデータ取り込み状況を確認できます。

「Data ingestion」タブを開くと、データソース別の取り込み量がグラフで表示されます。どのデータタイプ（メトリクス、ログ、APMイベント、トレースなど）が多いのか、一目で分かる仕組みです。

1.2 データタイプ別の内訳を理解する

New Relicでは、取り込むデータを以下のように分類しています。

Metrics（メトリクス）は、APMのメトリックタイムスライスデータやディメンショナルメトリクスです。Logging（ログ）は、アプリケーションやインフラストラクチャから送られるログデータです。APM Events（APMイベント）は、TransactionやTransactionErrorなどのイベントです。Tracing（トレース）は、分散トレーシングのスパンデータです。

グラフ上でデータの帯をクリックすると、さらに詳細な内訳が表示されます。例えば、ログデータをクリックすれば、どのアカウントやサービスから送られているかを確認できます。

1.3 NrConsumptionイベントでより詳細に分析

UIで大まかな傾向を掴んだら、NRQLクエリを使ってより詳細に分析できます。

NrConsumptionは、データ取り込み量を時間単位で記録するイベントです。このイベントには、usageMetricという属性があり、データタイプを識別できます。例えば、MetricsBytesはメトリクスデータ、LoggingBytesはログデータを表します。

Query Builderを開いて、過去30日間のデータタイプ別取り込み量を確認するには、以下のようなクエリを使います。

FROM NrConsumption 
SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform' 
FACET usageMetric 
SINCE 30 days ago

これにより、どのデータタイプが課金を圧迫しているかが明確になります。

2. コスト増大の原因を特定する

データタイプ別の内訳が分かったら、次は「なぜそのデータが多いのか」を深掘りします。

2.1 ログデータの分析

ログは、コスト増大の最も一般的な原因の一つです。特に、デバッグログやヘルスチェックログが大量に送られているケースがよくあります。

どのサービスから多くのログが送られているかを確認するには、Data Management UIのログセクションを確認するか、以下のクエリを使います。

FROM Log 
SELECT bytecountestimate() / 1024 / 1024 / 1024 AS 'GB Estimate' 
FACET entity.name 
SINCE 7 days ago

特定のサービスが突出して多い場合、そのサービスのログ設定を見直す必要があります。

2.2 価値の低いデータパターンを見つける

次に、そのサービスのログの中身を確認します。以下のようなパターンが、削減候補になります。

成功したヘルスチェックログは、通常、障害調査では使いません。デバッグレベルのログで、本番環境には不要なものがあります。同じメッセージが数千回繰り返されているログは、アプリケーションのバグの可能性があります。

どのログメッセージが多いかを確認するには、messageフィールドで集計します。

FROM Log 
SELECT count(*) 
FACET message 
SINCE 1 day ago 
LIMIT 20

このクエリで、頻出するログメッセージが特定できます。

2.3 メトリクスとトレースの確認

ログほど目立たないものの、メトリクスやトレースも積み重なると大きなコストになります。

カスタムメトリクスを大量に送信している場合や、分散トレーシングのサンプリングレートが100%になっている場合は、見直しの余地があります。

AWSやAzureなどのクラウドインテグレーションを有効にしている場合、使っていないサービスのメトリクスまで取り込んでいる可能性があります。

3. 不要なデータを削減する戦略

原因が特定できたら、実際に削減を実行します。ここでは、いくつかの削減手法を紹介します。

3.1 Pipeline Controlでデータを削減する

前回の記事「New Relicで実現する実践的オブザーバビリティ」で紹介したPipeline Controlは、コスト削減の強力な武器です。

Pipeline Cloud Rulesを使えば、New Relicにデータが保存される前に、不要なデータを削除できます。例えば、成功したヘルスチェックログや特定のデバッグログを削除する設定が可能です。

重要なのは、削除する前に必ずクエリをテストすることです。間違った条件で削除すると、必要なデータまで失ってしまいます。小さく始めて、徐々に拡大していくアプローチが安全です。

3.2 エージェント設定で送信を制御する

データを送信する前の段階、つまりエージェント側で制御する方法もあります。

APMエージェントでは、ログレベルの設定やカスタムインストゥルメンテーションの調整ができます。Infrastructure エージェントでは、サンプリング間隔を調整したり、特定のプロセスメトリクスを無効化したりできます。

例えば、Infrastructureエージェントのサンプリング間隔を15秒から30秒に変更するだけで、データ量を約半分に削減できます。ただし、これは粒度とのトレードオフなので、監視要件と照らし合わせて判断しましょう。

3.3 ログフォワーダーでのフィルタリング

FluentdやLogstashなどのログフォワーダーを使っている場合、New Relicに送る前にフィルタリングできます。

この方法の利点は、ネットワーク帯域も節約できることです。ログフォワーダーの設定ファイルで、不要なログをフィルタリングする条件を追加します。

3.4 サンプリングの活用

すべてのデータを100%保存する必要はありません。特に、正常系のデータはサンプリングで十分なケースが多いです。

例えば、成功したトランザクションは10%だけサンプリングし、エラーが発生したトランザクションは100%保存するという戦略が効果的です。

分散トレーシングも同様です。すべてのトレースを保存するのではなく、代表的なパターンをサンプリングすることで、可視性を保ちながらコストを削減できます。

4. 継続的な監視とアラート設定

データ削減は一度やって終わりではありません。新しいサービスの追加や設定変更により、データ量は常に変動します。

4.1 月次目標を設定する

組織として、月あたりのデータ取り込み量の目標を設定しましょう。例えば、「月間10TB以内に抑える」といった具体的な数値目標です。

Data Management UIのダッシュボードに、目標値を示す線を追加できます。これにより、現在のペースで月末までにどの程度になるかが視覚的に分かります。

4.2 異常検知アラートを作成する

データ取り込み量が急増した場合に、すぐに気づける仕組みが必要です。

New Relicでは、時間あたりのデータ取り込み量が通常より大幅に増加した場合に通知するアラートを設定できます。例えば、「1時間あたりのデータ取り込み量が過去7日間の平均の2倍を超えた場合」といった条件です。

このアラートがあれば、設定ミスや予期しないトラフィック増加に素早く対応できます。

4.3 定期的なレビューを習慣化する

月に一度、データ取り込み量のレビュー会議を開くことをお勧めします。

そこで、以下の点を確認します。今月のデータ取り込み量は目標内か。先月と比べて増減があるか、その原因は何か。新しく追加されたサービスの影響はどの程度か。削減施策の効果は出ているか。

このレビューを習慣化することで、コスト管理が組織の文化として定着します。

4.4 価値とコストのバランスを常に意識する

最後に、最も重要な点です。コスト削減は目的ではなく、手段です。

削減によって重要な可視性を失っては本末転倒です。「このデータは本当に価値があるか」「削減することで、どんなリスクがあるか」を常に問いかけましょう。

New Relicで得られる価値（障害の早期検知、パフォーマンス改善、ビジネスインサイト）とコストのバランスを取ることが、真のコスト最適化です。

まとめ

この記事では、New Relicのデータ取り込み量を可視化し、無駄なデータを特定して削減する方法を紹介しました。

コスト最適化の第一歩は、Data Management UIとNrConsumptionイベントを使って、現状を正確に把握することです。どのデータタイプが多いのか、どのサービスから送られているのかを明確にします。

次に、ログメッセージの頻度やカスタムメトリクスの使用状況を分析し、価値の低いデータパターンを見つけます。成功したヘルスチェックログや、使っていないメトリクスが削減候補になります。

削減手法としては、Pipeline Controlによるサーバーサイドのフィルタリング、エージェント設定の調整、ログフォワーダーでのフィルタリング、そしてサンプリングの活用があります。小さく始めて、徐々に拡大していくアプローチが安全です。

そして、月次目標の設定、異常検知アラートの作成、定期的なレビューを通じて、継続的にコストを管理します。

重要なのは、コスト削減と可視性のバランスです。削減によって重要な情報を失わないよう、常に「価値があるか」を問いかけながら最適化を進めましょう。適切なデータ管理により、コストを抑えつつ、New Relicの価値を最大限に引き出せます。

この記事がどなたかのお役に立てれば幸いです。