New Relic AWS統合設定の基本概念と設定手順

AWS環境でNew Relicによる監視を始めたい方に向けて、基本概念から実際の設定手順までを分かりやすく解説します。複雑なコードや設定に惑わされる前に、まずは「なぜAWS統合が必要なのか」「どんなメリットがあるのか」を理解しましょう。

なぜAWS統合が必要なのか

AWS上でシステムを運用している場合、監視すべき対象は大きく2つに分かれます。

New RelicのAWS統合は、これらを統一されたダッシュボードで監視することを可能にします。

Infrastructure AgentはEC2インスタンス上で動作し、ホストレベルの詳細なメトリクスを収集します。一方、AWS統合はCloudWatch APIを通じてAWSマネージドサービスのメトリクスを収集します。この2つは独立して動作し、それぞれ異なる範囲をカバーします.

1. 統一されたダッシュボード

Infrastructure Agentによる監視

EC2インスタンスのCPU、メモリ、ディスク使用率
実行中のプロセスとサービスの状態
ネットワークトラフィックの詳細
カスタムメトリクスとログファイル

AWS統合による監視

RDSデータベースのパフォーマンスメトリクス
Lambda関数の実行回数とエラー率
ALB/ELBのレスポンスタイムとエラー
S3バケットのリクエスト数とサイズ

AWS統合を有効にすると、New RelicがCloudWatchからメトリクスを自動収集します。手動でメトリクスを設定する手間が大幅に削減されます。

3. アラート統合

AWS CloudWatchアラートとNew Relicアラートを統合することで、一元的なアラート管理が可能になります。

基本的なセットアップの流れ

ステップ1: IAMロールの準備

なぜIAMロールが必要なのか

New RelicがAWSのリソース情報を収集するためには、適切な権限が必要です。セキュリティのベストプラクティスとして、専用のIAMロールを作成します。

AWSマネジメントコンソールでの設定手順

IAMサービスにアクセス
- AWSマネジメントコンソール → IAM → ロール
ロールの作成
- 「ロールを作成」をクリック
- 信頼されたエンティティタイプ: AWSのサービス
- 使用事例: EC2
必要な権限の付与 以下のAWS管理ポリシーを付与します：
- CloudWatchReadOnlyAccess
- EC2ReadOnlyAccess
ロール名の設定 推奨名: NewRelic-Infrastructure-Role

最小権限の原則

実際の運用では、以下のようなカスタムポリシーの使用も検討できます：

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeTags",
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

ステップ2: EC2へのInfrastructure Agent設定

基本的なインストール方法

最も簡単な方法は、EC2インスタンスに直接ログインしてインストールすることです。

Amazon Linux/RHEL系の場合

bash

# セキュリティベストプラクティス: AWS Secrets Managerからライセンスキーを取得
# 事前にAWS Secrets Managerまたはパラメータストアにライセンスキーを保存してください

# AWS Secrets Managerから取得する場合
NEW_RELIC_LICENSE_KEY=$(aws secretsmanager get-secret-value \
    --secret-id "newrelic/license-key" \
    --query SecretString --output text)

# AWS Systems Manager Parameter Storeから取得する場合（別の方法）
# NEW_RELIC_LICENSE_KEY=$(aws ssm get-parameter \
#     --name "/newrelic/license-key" --with-decryption \
#     --query Parameter.Value --output text)

if [ -z "$NEW_RELIC_LICENSE_KEY" ]; then
    echo "ERROR: New Relic ライセンスキーを取得できませんでした"
    exit 1
fi
INSTANCE_NAME=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
AVAILABILITY_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
INSTANCE_TYPE=$(curl -s http://169.254.169.254/latest/meta-data/instance-type)

# システム更新
yum update -y

# New Relic Infrastructure Agent インストール
curl -o /etc/yum.repos.d/newrelic-infra.repo https://download.newrelic.com/infrastructure_agent/linux/yum/el/7/x86_64/newrelic-infra.repo
yum -q makecache -y --disablerepo='*' --enablerepo='newrelic-infra'
yum install newrelic-infra -y

# 設定ファイル作成
cat > /etc/newrelic-infra.yml << EOF
license_key: ${NEW_RELIC_LICENSE_KEY}
display_name: ${INSTANCE_NAME}
verbose: 0

# カスタム属性（タグ）の設定
custom_attributes:
  environment: production
  aws_region: ${AVAILABILITY_ZONE%?}
  availability_zone: ${AVAILABILITY_ZONE}
  instance_type: ${INSTANCE_TYPE}
  deployment_method: user_data

# ログ設定
log:
  level: info
  file: /var/log/newrelic-infra/newrelic-infra.log
EOF

# サービス開始
systemctl enable newrelic-infra
systemctl start newrelic-infra

# CloudWatch Logsエージェントのインストール（オプション）
yum install -y awslogs
cat > /etc/awslogs/awslogs.conf << EOF
[general]
state_file = /var/lib/awslogs/agent-state

[/var/log/newrelic-infra/newrelic-infra.log]
datetime_format = %Y-%m-%d %H:%M:%S
file = /var/log/newrelic-infra/newrelic-infra.log
buffer_duration = 5000
log_stream_name = {instance_id}/newrelic-infra.log
initial_position = start_of_file
log_group_name = /aws/ec2/newrelic
EOF

systemctl enable awslogsd
systemctl start awslogsd

CloudFormationによる自動デプロイ（参考）

EC2インスタンスにInfrastructure Agentを自動インストールする場合は、CloudFormationテンプレートを使用できます。詳細なテンプレートは公式ドキュメントを参照してください。

基本的な構成要素：

IAMロール（EC2インスタンス用）
セキュリティグループ
User DataスクリプトによるAgent自動インストール

AWS統合の仕組み

AWS統合は、New RelicがあなたのAWSアカウントのIAMロールを引き受けて、CloudWatch APIからメトリクスを定期的に収集する仕組みです。

New RelicでのAWS統合有効化

New Relicダッシュボードから簡単に設定できます：

New Relicダッシュボードでの設定
- Infrastructure > AWS > Add AWS accountをクリック
- 設定方法を選択（推奨: CloudFormation）
- External IDをメモする
IAMロールの作成（AWSコンソール）
- IAM > ロール > ロールを作成
- 信頼されたエンティティタイプ: 別のAWSアカウント
- アカウントID: 754728514883（New RelicのAWSアカウント）
- External ID: New Relicダッシュボードで表示された値を入力
- ポリシー: ReadOnlyAccessをアタッチ
必要最小限の権限（カスタムポリシー）

特定のサービスのみ監視する場合は、より制限的なポリシーを作成できます。以下は主要サービスの例：

EC2: ec2:Describe*
RDS: rds:Describe*、rds:ListTagsForResource
Lambda: lambda:GetFunction*、lambda:List*
ELB/ALB: elasticloadbalancing:Describe*

Infrastructure as Code（IaC）による自動化

TerraformやCloudFormationを使用して、AWS統合の設定を自動化できます。詳細な実装例はGitHubリポジトリを参照してください。

主要な設定項目：

IAMロールのARN
External ID（セキュリティトークン）
メトリクス収集間隔（デフォルト: 5分）
タグの収集有無

CloudWatchとの高度な連携

CloudWatch Logsの統合

CloudWatch LogsをNew Relicに転送するには、Lambda関数を使用します：

New Relic Log Ingestion Lambdaのデプロイ
- AWSサーバーレスアプリケーションリポジトリから「newrelic-log-ingestion」を検索
- ライセンスキーを設定してデプロイ
CloudWatchログサブスクリプションの設定
- 転送したいログループを選択
- サブスクリプションフィルターを作成
- 送信先にNew Relic Lambda関数を指定

X-Ray統合設定

AWS X-RayトレースをNew Relicに統合することで、分散トレーシングを実現できます：

X-Rayトレースの有効化
- Lambda関数でX-Rayトレースを有効化
- API GatewayでX-Rayトレースを有効化

New Relic AWS Lambda Extensionの利用

Lambda Layerとして追加
環境変数で設定

NEW_RELIC_ACCOUNT_ID=<your-account-id>
NEW_RELIC_LAMBDA_HANDLER=<your-handler>
NEW_RELIC_LICENSE_KEY=<your-license-key>

トレースの統合
- New RelicダッシュボードでDistributed Tracingを確認
- X-Rayのトレース情報が自動的に統合される

カスタムダッシュボードの作成

重要なメトリクスを一箇所で確認するため、カスタムダッシュボードの作成が効果的です。

推奨ウィジェット:

CPU使用率の時系列グラフ
メモリ使用率の現在値
ディスク使用量の円グラフ
AWSサービス別のヘルスチェック

トラブルシューティング

Infrastructure Agentは起動時にEC2のタグを自動的に取得します。特別な設定は不要ですが、カスタム属性を追加することもできます：

yaml

# /etc/newrelic-infra.yml
license_key: YOUR_LICENSE_KEY
display_name: production-web-01

# カスタム属性の追加
custom_attributes:
  monitoring_tier: premium
  backup_enabled: true
  team: backend

EC2のタグは自動的にNew Relicのインベントリに表示され、NRQLクエリで使用できます。

コスト最適化設定

AWS統合のコストを最適化するための推奨設定：

メトリクス収集間隔の調整
- New Relicダッシュボードで各サービスの収集間隔を設定
- 重要度の低いサービスは10分または15分間隔に変更
不要なサービスの無効化
- Infrastructure > AWS > Configure
- 使用していないサービスのチェックを外す
リージョンの限定
- 実際に使用しているリージョンのみを有効化
- 不要なリージョンは統合から除外
タグベースのフィルタリング
- 本番環境のリソースのみを監視対象にする
- テスト環境は別アカウントで管理

段階的な導入戦略

フェーズ1: 基本監視の確立（1-2週間）

プライベートサブネットからの通信

プライベートサブネットのEC2インスタンスでInfrastructure Agentを使用する場合：

NATゲートウェイまたはNATインスタンス
- インターネット向け通信を許可
- New Relicのエンドポイントへの接続を可能にする
プロキシサーバー経由
- HTTP/HTTPSプロキシを設定
- Infrastructure Agent設定でプロキシを指定：
yaml
```
proxy: http://your-proxy-server:3128
```
1
セキュリティグループ設定
- アウトバウンド: HTTPS (443) を許可
- インバウンド: 不要（Agentはアウトバウンド接続のみ）

まとめ

New RelicのAWS統合により、従来別々のツールで行っていたインフラストラクチャ監視を統一することができます。特に重要なのは以下の点です：

導入のメリット

統一されたダッシュボードでインフラからアプリケーションまで一括監視
自動的なメトリクス収集により手動設定の手間を削減
タグベースの管理で複数環境・チームでの運用を効率化

次のステップ

基本設定の完了後
- アラート設定の最適化
- カスタムダッシュボードの作成
運用の成熟化
- ログ統合の設定
- 自動化スクリプトの導入
- チーム間での監視ナレッジ共有

AWS統合を活用して、より効率的で信頼性の高いインフラストラクチャ監視を実現しましょう。

New Relic AWS統合設定の基本概念と設定手順 ​

なぜAWS統合が必要なのか ​

1. 統一されたダッシュボード ​

3. アラート統合 ​

基本的なセットアップの流れ ​

ステップ1: IAMロールの準備 ​

なぜIAMロールが必要なのか ​

AWSマネジメントコンソールでの設定手順 ​

最小権限の原則 ​

ステップ2: EC2へのInfrastructure Agent設定 ​

基本的なインストール方法 ​

Amazon Linux/RHEL系の場合 ​

CloudFormationによる自動デプロイ（参考） ​

AWS統合の仕組み ​

New RelicでのAWS統合有効化 ​

Infrastructure as Code（IaC）による自動化 ​

CloudWatchとの高度な連携 ​

CloudWatch Logsの統合 ​

X-Ray統合設定 ​

カスタムダッシュボードの作成 ​

トラブルシューティング ​

コスト最適化設定 ​

段階的な導入戦略 ​

フェーズ1: 基本監視の確立（1-2週間） ​

プライベートサブネットからの通信 ​

まとめ ​

導入のメリット ​

次のステップ ​

関連記事 ​