はじめに

今回書く内容としては、New Relicの監視データをプライベート経由で送る(概要編)です。
以前、下記記事でも同じような内容を書いたのですが、その概要編ということで、今回も書いていこうと思います。

本記事は、「New Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2024」の20日目の記事となります。(すいません、投稿遅れました)

前提条件

2024年2月に構築した内容を元に記載しているので、一部情報が古いことがありますが、その点ご了承ください

概要

(1)プライベート経由で監視データを送る手法に関して

New Relicとは、基本的にはAgent導入型のプッシュ型の監視サービスであり、各監視対象のサーバは、特定のドメイン(newrelic.com、nr-data.net)に対して、自身の監視メトリクス/ログデータをインターネット経由で送らせるアーキテクチャです。インターネット経由で監視データを送るということが、社内で定めるセキュリティ的に許容できないということになり、今回プライベート経由で監視データを転送するアーキテクチャを構築しました。
New Relic社では、各監視対象サーバが、プライベート経由で監視データを送る手法として、AWS PrivateLink経由でのデータ転送手段を公開してます。公開されているAWS PrivateLinkのエンドポイントは、下記4つのリージョンしかなく、それ以外の環境からアクセスさせる際には、別途対応が必要となります。

us-east-1(米国東部 (バージニア北部))
us-east-2(米国東部 (オハイオ))　←この記事では、これを使う前提で書いていきます。
us-west-2(米国西部 (オレゴン))
eu-central-1(欧州 (フランクフルト))

主な対応事項としては、「別環境から通信できるようにさせる」と「AWS PrivateLinkの名前解決をさせる」です。
そこで使用したアーキテクチャとしては、「Transit Gatewayのリージョン間ピアリング」と「Route53での名前解決の設定」です。
イメージ図としては下記となるのですが、実際に構築した内容としては、下記となります。

(1)バージニア北部のVPC内で、この記事にあるPrivateLinkを必要に応じて作成する
(2)Route53のプライベートホストゾーン(newrelic.com/nr-data.net)を作成し、各ドメインごとにprivateLinkのホスト名を関連付ける。
(3)Transit Gatewayのリージョン間ピアリング/ルーティン設定
(4)Route53のプライベートホストゾーンをVPCに関連付ける

上記の設定をすることで、以下表に記載されているドメインに対して、プライベート経由で監視データを送れるようになります。※Route53の名前解決の優先順位により、Route53のプライベートホストゾーンに設定されるドメインの名前解決が優先され、結果として、監視データはPrivateLink経由で送られるようになる。

ドメイン	説明
collector.newrelic.com	APM
insights-collector.newrelic.com	イベントのAPI
metric-api.newrelic.com	メトリック API (Prometheus およびその他の統合を含む)
log-api.newrelic.com	ロギング
trace-api.newrelic.com	ディストリビューティッド（分散）トレーシング
cloud-collector.newrelic.com	AWS Lambda と Cloudwatch Logs のモニタリング
infra-api.newrelic.com	インフラストラクチャの監視とオンホスト統合
otlp.nr-data.net	OpenTelemetry

(2)Route53のルール設定に関して

手順(1)を実施したことで、特定のドメインに対しては、プライベート経由でデータを送れるようになりました。しかし、newrelic.com、nr-data.net内で未定義のサブドメイン(identity-api.newrelic.com/infrastructure-command-api.newrelic.com/api.newrelic.comなど)へ通信が必要になった際は、名前解決ができないことが原因で通信に失敗してしまいます。
なので、「このドメインの名前解決はRoute53のプライベートホストゾーン」「それ以外の名前解決は外部のDNSサーバに問い合わせをしてね」といったルール設定が必要になります。
そのルール設定は、Amazon Route 53 Resolverのルール設定で定義する必要があり、各ルール設定で定義できる項目は下記の通りとなります。

ルール名称	説明	今回の設定対象
再帰的	AWS側で自動的に作成されるルールで、Route53に登録がないドメインに対して、再帰リゾルバーとして機能させる設定	-
Forward(転送)	指定したドメイン名のDNSクエリをネットワーク上のリゾルバーに転送する設定	〇
System(システム)	指定したドメインに対して、Route53で名前解決をさせる設定。	〇

上記内容を踏まえ、実際に設定した際の画面は下記画像となります。これで、定義済みのサブドメインはプライベート経由で名前解決がされ、それ以外のサブドメインは外部のDNSサーバで名前解決がされるようになります。

(3)Proxyの利用に関して

手順(1)、(2)を実施したことで、プライベート経由で監視データを送る手法が確立できました。しかし、横展開を考えた場合、VPCの数がある分だけ、下記の対応が必要になることが課題として挙がりました。

Route53のプライベートホストゾーンの関連付けを監視対象があるVPC毎に実施しなければならない
Route53 Resolverの各ルール単位で、監視対象があるVPCを関連付けなくてならない

上記の対応は、今後の運用を考えた場合、作業漏れのリスクが大きくある為、汎用性のある環境を別途考える必要がありました。そこで、Proxy経由で監視データを送るという手法にたどり着きました。
実際に実施した内容は下記となります。

ProxyサーバをRoute53のプライベートホストゾーンが関連付けられたVPCに配置する
各監視対象のサーバは、Proxy経由で監視データを送る設定をする

上記の手法をすることで、newrelic.com/nr-data.netといった名前解決はProxyが行うようになるので、名前解決を絞っているオンプレミス環境に対してもNewRelicの導入ができるようになりました。実際に構築した後のイメージ図としては、下記のようになります。

また、NewRelicでは、Infrastructure agentやAPM Agent毎に専用のProxy環境変数を用意しているので、OS標準で用意されているHTTP_PROXY/HTTPS_PROXYを使うことなく、監視データを送れるのが、ほんとにありがたいです。※既存の通信に影響を与えることなく、PROXY経由で監視データを送れる。

最後に

今回の環境は、かなり苦戦して構築しました。AWSサポートやNewRelicのサポートに確認しながら進めたので、自身にとってとても勉強になりました。
この記事が、どなたかのお役に立てば幸いです。