本記事では、New Relic テクニカルサポートにお寄せ頂くことが多いお問い合わせ内容をもとに、AWS Integration（AWS 連携）に関連するいくつかのトピックについて解説します。
製品ドキュメントの補足として、疑問や懸念を払拭するための参考情報、またはトラブルシューティングのヒントとして頂ければ幸いです。
2 種類の AWS 連携方式の概要
Metric streams
AWS 上のメトリクスデータを New Relic に取り込む方法は二種類あり、一つは CloudWatch のメトリクスストリーム機能を利用した Metric streams 方式です。
こちらの方式では、AWS CloudWatch がデータ送信の主体となります。CloudWatch 上で記録されたメトリクスは、Amazon Data Firehose (旧名称: Kinesis Data Firehose) を通じて、1 分間隔のほぼリアルタイムで New Relic に送信されます。
セットアップの特徴としては、複数の AWS サービスにわたる個別の連携設定や、IAM ロールの権限追加を行うことなく運用可能な点が挙げられます。
また、CloudWatch に記録されるメトリクスはカスタムメトリクスを含めてすべて送信対象となるため、新サービスや新たなメトリクス追加にも自動的に追従できます。送信対象データのフィルタリングは CloudWatch 側で行います。
API Polling
もう一つが、各 AWS サービス毎の API を定期的にポーリングする、API Polling 方式です。New Relic ドキュメント上では従来の AWS 連携方式と呼ばれることもあります。
こちらの方式では、Metric streams 方式とは異なり、New Relic がデータ取得の主体となります。一定時間おきに、EC2 や Lambda など、AWS の各サービスの API に対してリソース一覧を読み取り、それらのリソースに関するメトリクスを CloudWatch API にリクエストします。
そのため、使用する IAM ロールには、データ取得対象サービスのリソースに関する読み取りアクセス権限が必要になります。
また、取得対象メトリクスは New Relic 側のプログラムで事前定義されたものに限定され、任意のカスタマイズをサポートしていない点にご留意ください。
本記事の執筆時点では通常、Metric streams 方式のご利用を推奨していますが、サービスによって一部 API Polling との併用が有効なケースもあります。
CloudWatch メトリクスストリームでは、メトリクスのタイムスタンプと、実際にそのメトリクスが CloudWatch 上に記録されるまでのタイムラグが 2 時間を超えるデータの送信はサポートされていません。これに該当する課金情報や S3 バケットの日次メトリクス、CloudTrail メトリクスなどの一部のデータは Metric streams 方式では収集できないため、API Polling で取得する必要があります。詳細はこちらのドキュメントをご参照ください。
連携方式ごとのAWS側コストの考え方
Metric streams と API Polling、どちらの方式であってもメトリクス取得にあたっては AWS の利用料金が発生します。いずれもリソース数やデータ発生量により大きく変動し、また最終的には AWS 側で算出されるものであるため、New Relic テクニカルサポートから具体的な根拠や正確な試算に基づいたご案内ができかねる点は、あらかじめお含みおきください。
Metric streams 方式の場合は、メトリクスの更新件数に応じて CloudWatch の利用料金が発生します。また、Amazon Data Firehose のデータ処理量に応じた課金のほか、インターネット経由でのデータ転送に掛かる料金も発生します。
API Polling 方式では、メトリクス発生の有無に関わらず、一定間隔で対象リソースを一覧し、リストアップしたリソースそれぞれに対して、CloudWatch API に GetMetricData リクエストを発行します。
例えば EC2 インスタンスが 100 台ある環境で EC2 Integration のポーリング間隔を 5 分に設定していれば、単純計算で 5 分毎に 100 インスタンス分の GetMetricData リクエストが行われることとなります。Lambda 関数や SNS トピック等も同様に、アカウント内のリソース数に比例して API リクエスト料金が増加する点にご留意ください。
料金とは直接関係ありませんが、リソース数が多い場合には、GetMetricData リクエストが短期間に大量に発行され、結果的に CloudWatch API 側でスロットリングが発生する可能性があります。
データ精度とのトレードオフになりますが、New Relic の AWS Integration 設定にて、サービスごとのポーリング間隔を調整することができます。また、データ取得の対象を AWS リージョン単位や、リソースタグによって絞り込むこともできますので、API リクエスト数やコストに関する懸念がある場合には、こちらを適宜調整してください。
最低限必要となる IAM パーミッション
New Relic の AWS 連携をセットアップするには、AWS アカウント側で IAM ロールの設定が必要になります。New Relic は、指定された IAM ロールを用いて、お客様の代理として AWS アカウント内のデータへの読み取りアクセスを行います。
Metric streams 方式の場合、メトリクスデータは CloudWatch 側から New Relic の HTTPS エンドポイント宛にストリーミングされるため、メトリクスの取得自体には IAM ロールの権限は不要ですが、受信したメトリクスデータやエンティティに対して、 AWS リソースタグを関連付ける処理を定期的に行っており、その際 AWS 側のメタデータにアクセスするために IAM ロールを使用します。
API Polling 方式の場合は、AWS アカウント内のリソースを一覧し、それらのメトリクスを CloudWatch にリクエストしてデータを取得するため、基本的には連携対象サービスのリソース読み取りに関する権限が必要になります。
New Relic UI のセットアップウィザードやドキュメント上では、最も簡便なセットアップ方法として、AWS マネージドポリシーである ReadOnlyAccess を使用することを推奨しています。全サービスへ一律に ReadOnlyAccess 権限を付与することで、連携する AWS サービスごとにパーミッション設定をする手間が省けること、また AWS マネージドポリシーであるため、常に最新の状態に自動更新されるといった利点があります。
組織のセキュリティポリシーによって、IAM ロールには必要最低限のアクセス権限のみを与えたい、といった要件があることも認識しています。そのような場合には、要件に応じて独自の IAM ポリシーを設定することも可能です。
Metric streams 方式の AWS 連携において最低限必要となる IAM ポリシーはこちらのドキュメントに記載されています。これらのポリシーは、エンティティのリソースタグを取得し、Metric streams を通じて送信されたメトリクスを装飾するために使用されます。
API Polling 方式の AWS 連携で最低限必要となる IAM ポリシーは、こちらのドキュメントをご参照ください。ドキュメント内の CloudFormation テンプレートを使用してセットアップするか、ご利用中の AWS サービスに合わせ、ドキュメントからサービス毎に必要となるポリシーをピックアップして、任意の IAM ポリシーを作成してください。
複数の AWS アカウントとの連携
複数の AWS アカウントから、一つの New Relic アカウントに集約する形でデータを送信することも可能です。
この場合、各 AWS アカウントに IAM ロールをご用意の上、New Relic 側で連携する AWS アカウントごとにセットアップ手順を実施してください。
複数の New Relic アカウントとの連携
一つの AWS アカウントから、複数の New Relic アカウントへ同時にデータ連携を行うことも可能です。なお、AWS 側でのデータ転送料金、またはメトリクス取得にかかる API リクエスト料金が多重で発生する点については、あらかじめご了承頂ければと存じます。
Metric streams 方式、API Polling 方式どちらの場合も、連携先の New Relic アカウントそれぞれで AWS 連携の設定を行う必要があります。Metric streams 方式の場合は、連携先の New Relic アカウントごとに、Amazon Data Firehose 配信ストリームを作成する必要があります。
また、こちらも 2 つの連携方式に共通して、New Relic が API リクエストを行う際に引き受ける IAM ロールの指定が必要となります。連携先の New Relic アカウントごとに別個の IAM ロールを作成するか、あるいは既存 IAM ロールに対して、引き受け可能な外部 ID (sts:ExternalId) を追加します。
New Relic アカウントごとにそれぞれ、連携用の IAM ロールを作成する場合、この先の手順は不要です。
既に特定の New Relic アカウントとの連携用に IAM ロールを作成されている場合、当該 IAM ロールの信頼関係において、以下のように連携先の New Relic アカウント ID を列挙することで、一つの IAM ロールで複数 New Relic アカウントとの連携が実現できます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::754728514883:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": [
"1つ目のNew RelicアカウントID",
"2つ目のNew RelicアカウントID"
]
}
}
}
]
}New RelicとCloudWatchとで値が一致しない
ELB や ALB における Availability Zone (AZ) 名の有無のように、同じデータが複数のディメンションで報告される場合、New Relic 上ではそれぞれの属性の組み合わせからなるメトリクスを別個のデータとして記録します。そのため、単純にリソース名だけでクエリした場合、CloudWatch 上の値と比べて値が 2 倍に見えるなど、表示上の不一致が見られる可能性があります。
ELB 関連メトリクスをクエリする際は、NRQL クエリの WHERE 句で AZ 名が存在するデータか、あるいは存在しないデータだけを絞り込むことで、CloudWatch と同様に実数値が得られることが想定されます。
その他に、EC2 の CPU 使用率などいくつかの代表的なメトリクスは、CloudWatch 側では OS 外部のハイパーバイザで観測した値が記録されているのに対して、New Relic の host メトリクスは Infrastructure Agent が OS 内部で計測した値が記録されるため、参照する値とその特性によって多少の差異が発生することがある点にご留意ください。
リソースタグが付与されないことがある
通常、New Relic 上では AWS 上でリソースに付与されたタグ（リソースタグ）を自動的に収集してエンティティと紐付けており、これにより NRQL クエリによる集計時に、リソースタグを使用した対象の絞り込みやグルーピングが可能となっています。
しかしながら、Metric streams 方式で連携されているデータに関しては特定の環境下で、一部のリソースにタグが付与されていない、といった状況が発生する可能性があります。
具体的には、メトリクスの更新頻度が 24 時間よりも長い周期となる場合です。例えば 1 日に 1 回より長い間隔で定期実行される Lambda 関数で、リソースタグを使用した集計に問題が生じているような場合、この制約に該当している可能性があります。このような場合には、お手数ですがリソースタグ以外の属性での代替をご検討ください。
本項執筆時点の情報に基づく補足ですが、New Relic では、Metric streams 連携を通じて新しいエンティティに対するメトリクスを受信した際、そのエンティティにタグ等のメタデータによる修飾が行われていなければ、そのタイミングで対応する AWS リソースのメタデータの取得を試みます。次の 24 時間以内に受信するメトリクスは取得済のメタデータで修飾されますが、すでに記録された最初のメトリクスは修飾されない点にご留意ください。
また、特定のメトリクスが最後に報告されてから約 24 時間にわたり更新されない状態が続いた場合、保持されたメタデータの情報は破棄され、次回受信時には新たなメトリクスとして扱われるため、前述のメタデータの引当処理が再度行われる挙動となります。
GuardDutyにより異常パターンとして検知される
New Relic の AWS 連携機能がお客様の AWS アカウントにアクセスする際の接続元アドレスは、ドキュメントに記載されている CIDR 範囲から決定されます。多くの場合、実際の接続に使用される IP アドレスは更に特定のレンジに収まる傾向がありますが、ご利用ユーザーの増加など内部的なリソース調整によって、ドキュメントに記載の範囲内で、普段とは異なる IP アドレスが使用される場合があります。
Amazon GuardDuty は機械学習モデルなどのインテリジェンスフィードを利用して、継続的なモニタリングにより脅威検知を行うサービスです。Amazon GuardDuty は、これまで New Relic からのリクエストで使われたことのなかった接続元 IP アドレスからの API リクエストを、予期しないアクティビティとして検知し、ユーザーに確認を促すことがあります。
これは両者ともに正常な挙動で、その性質上 False Positive をゼロにすることは困難です。Amazon GuardDuty による検知の詳細を確認し、New Relic からの接続元 IP アドレスがこちらのドキュメントに記載の CIDR 範囲に収まっている場合には、正常なリクエストとなりますので、当該の検知は Archive して頂いて問題ありません。
次のステップ
- 製品ドキュメントのほか、ユーザーフォーラム Explorers Hub でも有益なヒントを得られる可能性があります。
- それでもお困りの問題が解決しない場合には、テクニカルサポートまたは弊社アカウントチーム担当者まで気兼ねなくお問い合わせください。
- お問い合わせの際は、ご参照頂いたドキュメントや切り分けの実施状況、お困りの状況が客観的に把握できるログやスクリーンショット等の共有にご協力頂けると幸いです。
- AWS 連携に関する問題の場合、IAM ロールのポリシーや、CloudTrail 側で記録されたエラーの詳細など、AWS 側で確認できる情報も併せて共有頂けると、より円滑な対応が可能です。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
