【New Relic】Pipeline ControlのCloud Rulesでデータ転送量を削減してみた

1. はじめに

New Relicを運用していると、ある日ふとData Ingestの画面を見て「こんなにデータ送ってたっけ？」と思うことがあるかもしれません。
特にInfrastructure Agentはデフォルト設定のまま導入すると、意外と多くのデータを転送しています。

本記事では、データ転送量の削減方法として「Infrastructure Agentの設定ファイルで絞る方法」と「Pipeline Control Cloud Rulesで絞る方法」の2つのアプローチを検証しました。
データ転送量、つまりNew Relicにおけるコストを意識しだす前に、
先に設定しておけばよかったと後悔しないように、削減できるところは予め削減しておこうという話です。

2. 現状確認

削減の前に、まず現状を知るために、自分の環境でどのくらいデータを転送しているか把握しておきましょう。

New Relicの Administration > Data management > Data ingestion から確認できます。

Data Ingest画面

この画面では、データソースごとの転送量が可視化されています。
今回の検証環境では、Infrastructure processes が54.17%、Infrastructure hosts が18.24% と、Infrastructureエージェント関連だけで全体の約72%を占めていました。

※ この割合は環境によって異なります。あくまで一例としてご参考ください。

ここで「Infrastructure processes」「Infrastructure hosts」がそれぞれ何のデータなのか、補足しておきます。

ソース	格納先イベント	内容
Infrastructure hosts	SystemSample, NetworkSample, StorageSample	サーバーやVMのシステム・ネットワーク・ストレージ情報
Infrastructure processes	ProcessSample	Infrastructureエージェントが稼働するホスト上の各プロセス情報

参考：Manage data coming in to New Relic - Sources list

特に注目すべきは Infrastructure processes（ProcessSample） です。
公式ドキュメントによると、enable_process_metrics の設定について以下のように記載されています。

デフォルトではInfrastructure agentはOSのプロセスデータを送信しません。ただし、2020年7月20日以前に作成されたアカウント、またはguided installでインストールした場合は enable_process_metrics がデフォルトで有効になります。

参考：Infrastructure agent configuration settings - enable_process_metrics

guided installでセットアップした環境では、意識していなくても全プロセスのデータを送信している可能性があります。
今回の環境でも、転送量の半分以上がプロセスデータという結果でした。

今回は、このアカウントで転送量の半分以上を占めている Infrastructure processes（ProcessSample） に絞って、データ転送量の削減方法を検証していきます。

3. 課題

前章で確認したとおり、Infrastructure processesの転送量は無視できないボリュームになり得ます。

enable_process_metrics が有効になっている背景として、guided installでInfrastructure Agentを導入した場合はデフォルトで有効になっていることが挙げられます。
また、プロセスごとのCPUやメモリを可視化できるのはNew Relicの魅力の一つでもあるため、「とりあえず有効にしておこう」と意図的に設定するケースも少なくないと思います。

いずれの場合も、この設定が有効だとホスト上で稼働している全プロセスのメトリクスを取得します。

問題は、これに気づくタイミングです。
導入時は「とりあえず入れておこう」で進むことが多く、データ転送量やコストを意識しだす頃には、すでに大量のデータを送り続けている状態になっています。

そして「じゃあ絞ろう」と思っても、Infrastructure Agentの設定ファイルの変更にはOS上での作業とInfrastructure Agentの再起動が必要です。
本番環境で気軽に触れるものでもなく、対応が後回しになりがちです。

本記事では、この課題に対する2つの削減アプローチを検証していきます。

4. 事前調査

実際の検証には入る前に、どのホスト・プロセスが転送量を占めているかを確認し、どこを絞るべきか把握しておきましょう。

Data Ingestion画面で、ソース一覧の Infrastructure processes をクリックすると、詳細ウィンドウが表示されます。

ここでは、データソースやFacetの切り口を選択でき、ホスト別の転送量（GB）が可視化されます。
画面下部には、この内訳を取得するためのNRQLが表示されており、「Open in query builder」からそのままクエリビルダーで深掘りすることもできます。

さらにFacetに processDisplayName を追加して、ホスト×プロセス別の転送量を確認してみます。

SELECT bytecountestimate()/10e8 FROM `ProcessSample` FACET hostname, processDisplayName LIMIT 5 SINCE 1 month ago

Pieチャートで確認すると、対象ホストごとにどのプロセスが転送量を占めているかが一目で分かります。
今回の環境では、systemd-userwor が 19.87% の割合を占めていました。

つまり、このプロセスのデータをdropできれば、Infrastructure processes全体（30日間で15.68GB）の約20%、約3GBの削減が期待できそうです。

※ bytecountestimate() は期間が長くなるほど精度が低くなるため、あくまで参考値としてご確認ください。

5. 削減アプローチ

ProcessSampleの転送量を削減する方法として、以下の2つのアプローチがあります。

	① Infrastructure Agent設定ファイル	② Pipeline Control Cloud Rules
対処する場所	OS上（設定ファイル編集）	New Relic UI上
反映方法	Infrastructure Agent再起動が必要	ルール作成後、即時反映
できること	プロセスの絞り込み、転送間隔の変更	NRQLベースでデータをdrop
影響範囲	ホスト単位	アカウント単位で横断的にUIから一括管理

① 参考：Infrastructure agent configuration settings - exclude_matching_metrics
② 参考：Understanding your ingest pipeline

①はデータの送信元で制御する方法、②はNew Relicに届いたデータをNRDB格納前にdropする方法です。

ドロップされたデータはデータ取り込み（GB Ingested）にカウントされないため、課金対象にはなりません。

参考：Data ingest billing

それぞれにメリットがあるので、次章で実際に検証していきます。

6. 検証

6-1. 設定ファイルで絞る（OS側で対処）

まず現状のデータ量を確認しておきます。

対象ホストで systemd-userwor の ProcessSample を TIMESERIESで確認すると、デフォルトの20秒間隔で一定にデータが送信され続けているのが分かります。

FROM ProcessSample SELECT count(*) WHERE hostname = 'your-host-name' AND processDisplayName = 'systemd-userwor' LIMIT MAX SINCE 5 minutes ago TIMESERIES

転送間隔の変更

Infrastructure Agent設定ファイル（newrelic-infra.yml）で metrics_process_sample_rate を変更することで、プロセスデータの転送間隔を調整できます。

デフォルトは20秒ですが、今回は60秒に変更してみます。

metrics_process_sample_rate: 60

設定変更後、Infrastructure Agentの再起動が必要です。

sudo systemctl restart newrelic-infra

同じTIMESERIESで確認すると、波形の間隔が明らかに広がっていることが分かります。

転送間隔を3倍にしたので、単純計算でデータ量は約1/3に削減されます。
これはCloud Rulesではできない、Infrastructure Agent設定ファイルならではのメリットです。

プロセスの絞り込み

さらに exclude_matching_metrics を使うと、特定のプロセスをデータ送信対象から除外できます。

exclude_matching_metrics:
  process.name:
    - regex "^systemd"

設定変更後、Infrastructure Agentを再起動して同じクエリで確認すると、systemd-userwor のデータが完全に送信されなくなりました。

---

6-2. Cloud Rulesでdropする（UI上で対処）

6-1ではOS側で対処しましたが、Cloud RulesならOS上の作業なしにNew RelicのUI上からデータを削減できます。

※ 6-1で変更した設定はデフォルトに戻した状態で検証しています。

ルールの作成手順

New Relic Control > Pipelines を開き、画面下部の Cloud セクションにある + ボタンからルールを作成します。

ルール作成方法として Guided と Write a NRQL query の2つがあります。今回はGuidedで進めます。
ProcessSampleはイベントデータなので、Events を選択して Next をクリックします。

次の画面でルールの詳細を設定します。

• Name：drop-processsample-systemd-userwor
• Select what you want to drop：Drop data
• Event：ProcessSample
• Filter events based on NRQL：hostname = 'your-host-name' AND processDisplayName = 'systemd-userwor'

画面下部のPreviewに、実際に適用されるDELETE文が表示されます。内容を確認して Save をクリックします。

Save後、Pipelines画面に戻ると、Cloudセクションの Drop rules に作成したルールが表示されます。
左側の Account から対象のアカウントを選択すると、そのアカウントに紐づくルールが確認できます。

対象データのdrop確認

ルール作成後、同じTIMESERIESクエリで確認すると、Cloud Ruleが適用されたタイミングからデータがNRDBに格納されなくなったことが分かります。

OS側の作業なしに、UIからルールを作成するだけでデータのdropが即時反映されました。

7. まとめ

今回はInfrastructure Agentのプロセスデータ（ProcessSample）に絞って、データ転送量の削減方法を2つ検証しました。

	① Infrastructure Agent設定ファイル	② Cloud Rules
プロセスの絞り込み	✅	✅
転送間隔の変更	✅	❌
OS作業不要	❌	✅
即時反映	❌（再起動が必要）	✅
複数ホスト一括管理	❌（ホストごとに設定）	✅（UIから一括）

コスト削減の数値感

今回の検証環境をもとに試算してみます。

• Infrastructure processesの30日間の転送量：15.68 GB
• systemd-userwor の占有率：約20%
• 削減見込み：約3 GB/月

New Relicのデータ転送料金はOriginal Dataプランで $0.40/GB、Data Plusプランで $0.60/GB です。

プラン	削減量	月あたりの削減額	年間の削減額
Original Data ($0.40/GB)	約3 GB	約 $1.2	約 $14.4
Data Plus ($0.60/GB)	約3 GB	約 $1.8	約 $21.6

今回は検証環境のため金額としては小さいですが、本番環境でホスト数が多くなるほどこの効果は大きくなります。
例えば同じ条件のホストが50台あれば、年間で \$720〜$1,080 の削減になります。

※ 契約内容やボリュームディスカウントにより実際の単価は異なります。あくまで参考としてご確認ください。

どちらを選ぶか

どちらが良いかは状況次第かと思いますが、個人的にはUIで操作できるCloud Ruleは非常に便利に感じました。
転送間隔の調整も含めてきめ細かく制御したい場合は①、本番環境にできるだけ触りたくない・複数ホストをまとめて対処したい場合は②が向いています。もちろん併用も可能ですので、場面に応じて使い分けてみてください。

データ転送量は意識しないうちに膨らんでいきがちです。
まずは Data Ingestion画面 で自分の環境の現状を確認するところから始めてみてはいかがでしょうか。