New Relicで始めるクラウド監視～3大プラットフォームの接続方法とデータ収集の特徴～

みなさんこんにちは。マネージドサービス課の塩野です。

クラウドサービスの監視を効果的に行うには、各プラットフォームの特性を理解することが重要です。New RelicはAWS、Google Cloud、Microsoft Azureという3大クラウドプラットフォームに対応していますが、それぞれのインテグレーション方式には明確な違いがあります。

この記事では、New Relicの公式ドキュメントに基づいて、各クラウドプラットフォームとの接続方法やデータ収集の仕組みを詳しく解説します。

インテグレーション方式の基本

New Relicがクラウドサービスからデータを収集する方法は、大きく分けて2つのアプローチがあります。それは「プッシュ型」と「プル型」です。

プッシュ型は、クラウド側からNew Relicに向けてデータを送信する方式です。メトリクスが生成されるとすぐにストリーミング配信されるため、リアルタイム性が高く、データの遅延が最小限に抑えられます。この方式では、New Relic側からAPIを呼び出す必要がないため、API制限の影響を受けにくいという利点があります。

一方、プル型は、New Relicが定期的にクラウド側のAPIを呼び出してデータを取得する方式です。ポーリング間隔ごとにデータを収集するため、プッシュ型と比べるとデータの配信に若干の遅延が発生します。ただし、きめ細かな設定が可能で、監視対象のサービスや収集頻度を柔軟に調整できます。

3つのクラウドプラットフォームは、それぞれ異なる方式を採用しています。次の表で簡単に比較してみましょう。

項目	AWS	Google Cloud	Azure
データ収集方式	プッシュ型（推奨）	プル型	プル型
主要な仕組み	CloudWatch Metric Streams	APIポーリング	Azure Monitor integration
データ配信間隔	2分未満	5分（固定）	1分〜（設定可能）

この違いは、各クラウドプラットフォームの設計思想や提供するサービスの特性に基づいています。それでは、各プラットフォームのインテグレーション方式を詳しく見ていきましょう。

AWSインテグレーションの特徴

AWSとNew Relicのインテグレーションで推奨されているのは、CloudWatch Metric Streamsを使用したプッシュ型のデータ収集です。この方式は、従来のAPIポーリングと比較して大きな利点があります。

CloudWatch Metric Streamsは、AWSサービスからCloudWatchに送られたメトリクスを、ほぼリアルタイムでNew Relicにストリーミング配信します。具体的には、メトリクスがKinesis Data Firehoseを経由してNew Relicに送られ、通常2分未満でデータが到達します。この仕組みでは、60秒ごと、または1MBのデータが蓄積された時点でFirehoseがデータをプッシュするため、非常に高速な配信が実現されています。

この方式の大きなメリットは、個別のAWSサービスごとにAPI呼び出しを行う必要がない点です。CloudWatch Metric Streamsを設定すれば、すべてのCloudWatchネームスペースのメトリクスが自動的に配信されます。新しいAWSサービスがリリースされても、追加の設定なしで自動的に監視対象に含まれるため、監視の抜け漏れを防げます。

さらに、APIのレート制限の影響を受けないことも重要なポイントです。大規模な環境で多数のリソースを監視する場合でも、安定したパフォーマンスを維持できます。加えて、パーセンタイル統計（p90、p95、p99など）もサポートされているため、詳細なパフォーマンス分析が可能です。

ただし、CloudWatch Metric Streamsには一部対応していないサービスがあります。AWS CloudTrail、AWS Health、AWS Trusted Advisor、AWS X-Rayの4つのサービスについては、従来のAPIポーリング方式を併用する必要があります。New Relicでは、この2つの方式を組み合わせた運用が可能で、セットアップ時に自動的に両方を設定できます。

Google Cloudインテグレーションの特徴

Google CloudとNew Relicのインテグレーションは、APIポーリング方式を採用しています。New RelicがGoogle Cloud Monitoring API（旧Stackdriver API）を定期的に呼び出すことで、Google Cloudサービスのメトリクスを収集します。

ポーリング間隔は5分に固定されており、データ解像度は1分ごとに1データポイントとなっています。この方式では、New Relicが主体的にデータを取得しに行くため、監視対象のサービスや収集するメトリクスを細かく制御できます。

Google Cloudインテグレーションの特徴は、プロジェクト単位での管理が可能な点です。複数のGoogle Cloudプロジェクトを同時に選択して監視対象に追加できるため、組織内で複数のプロジェクトを運用している場合でも効率的に管理できます。また、プロジェクトごとに監視するサービスを個別に設定できるため、必要なデータだけを収集することでコストを最適化できます。

認証方式として推奨されているのは、サービスアカウント認証です。New Relicが専用のGoogleサービスアカウントを管理し、公開鍵と秘密鍵のペアによる認証を行います。ユーザー側でキーを管理する必要がないため、セキュリティ面でも安心です。セットアップ時には、New RelicのUIでGoogle Cloudアカウントを追加し、サービスアカウントIDに閲覧権限を付与するだけで、簡単に接続できます。

Google Cloudのリソースラベルは自動的に収集され、メトリクスに付与されます。これにより、環境やチームごとにリソースをフィルタリングして監視することが可能です。BigQueryについては、テーブルメトリクスの収集がデフォルトで無効になっていますが、必要に応じて有効化できます。

Azureインテグレーションの特徴

AzureとNew Relicのインテグレーションで推奨されているのは、Azure Monitor integrationを使用したポーリング方式です。この統合は、従来の個別サービスAPIを呼び出す方式から進化したもので、より包括的な監視を実現しています。

Azure Monitor integrationの最大の特徴は、Azure Monitorがサポートするすべてのサービスのメトリクスを単一のインテグレーションで収集できる点です。従来の方式では各Azureサービスごとに個別の設定が必要でしたが、新しい統合により、新しいAzureサービスが追加されても自動的に監視対象となります。

ポーリング間隔は、メトリクスについては最短1分から設定可能です。Google Cloudの5分固定と比較すると、より高頻度なデータ収集が可能で、問題の早期発見に役立ちます。メタデータやタグの収集間隔も個別に設定できるため、運用要件に応じた柔軟な調整ができます。

Azureの特筆すべき点は、Azure Native New Relic Serviceという特別な統合オプションが用意されていることです。これは、Azureポータルから直接New Relicを設定・管理できるサービスで、Azure Marketplaceからサブスクライブすることで利用できます。この方式では、インフラストラクチャ監視、APM、ログ管理のすべてをAzureポータルから一元管理でき、請求もAzureに統合されます。データはAzure内に保存されるため、データ主権やコンプライアンスの要件がある場合に有効です。

Azure Monitor integrationでは、リソースタイプ、リソースグループ、タグによる柔軟なフィルタリングが可能です。カスタムタグは自動的に収集され、メトリクスのディメンションとして利用できるため、組織の運用ポリシーに沿った監視が実現できます。

実際の運用で押さえておきたいポイント

3つのクラウドプラットフォームのインテグレーション方式を理解したうえで、実際の運用で重要なポイントをいくつか紹介します。

まず、データ配信速度については、AWSのCloudWatch Metric Streamsが最も高速で、2分未満でメトリクスがNew Relicに到達します。Azureは最短1分間隔でのポーリングが可能なため、比較的リアルタイムに近い監視が実現できます。Google Cloudは5分固定のポーリング間隔となっているため、秒単位での迅速な対応が必要な場合は、この遅延を考慮する必要があります。

メタデータやタグの収集についても、各プラットフォームで特徴があります。AWSではAWS Configと連携することで、リソースの詳細なメタデータを収集できます。EC2インスタンスについては、インスタンスタイプやVPC情報などが自動的に付与されるため、きめ細かなフィルタリングや分析が可能です。Google CloudとAzureでも、リソースラベルやタグが自動的に収集され、メトリクスに装飾されます。

運用コストの観点では、各プラットフォームでAPI呼び出しやデータ転送に関する料金が発生します。AWSのCloudWatch Metric Streamsは、従来のGetMetricData APIと比較して70%低コストとされており、1,000メトリクス更新あたり0.003ドルです。ただし、Kinesis Data Firehoseの料金も別途発生するため、全体のコストを見積もる必要があります。Google CloudとAzureについても、それぞれのAPIコール数やデータ量に応じた料金が発生するため、監視対象を適切に選択することが重要です。

まとめ

New Relicの3大クラウドプラットフォームインテグレーションは、それぞれ異なる技術的アプローチを採用しています。AWSはCloudWatch Metric Streamsによるプッシュ型で高速なデータ配信を実現し、Google Cloudは5分間隔のAPIポーリングでプロジェクト単位の柔軟な管理を提供し、Azureは1分から設定可能なポーリング間隔とAzure Nativeサービスによる統合管理を特徴としています。

クラウド監視は、システムの安定性とパフォーマンスを維持するための重要な取り組みです。New Relicのインテグレーション機能を活用することで、各クラウドプラットフォームの特性を活かした効果的な監視が実現できるでしょう。

この記事がどなたかのお役に立てれば幸いです。