はじめに
今回書く内容としては、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のサポートに確認しながら進めたので、自身にとってとても勉強になりました。
この記事が、どなたかのお役に立てば幸いです。