New RelicとAWS OpenSearchの比較

こんにちは。ゲームソリューション部の出村です。
オブザーバビリティツールの選択は、システム監視戦略において重要な決定の一つです。そのようなツールとしては、オブザーバービリティツールとしても利用できる、AWS OpenSearchという選択肢もあります。

今回は、このAWS OpenSearchとNew Relicという2つの主要なツールを比較し、それぞれの特徴と適用シーンについて詳しく解説します。

オブザーバビリティツールの概要

今回紹介する2つのオブザーバービリティツールについて簡単に解説しておきます。

AWS OpenSearch Services・OpenSearch Dashboards

AWS OpenSearch ServicesとOpenSearch Dashboardsは、Elasticsearchから派生したオープンソースの検索・分析エンジンです。主にログデータの収集、保存、検索、可視化に特化しており、大規模なログ管理とリアルタイム分析を得意としています。

補足1: OpenSearch ServicesとOpenSearch Dashboardsは、AWSが提供するマネージドサービスとして、インフラの管理負荷を軽減しながら強力な検索・分析機能を提供します。OpenSearch Servicesはデータの保存・検索エンジン部分を担い、OpenSearch Dashboardsはデータの可視化とダッシュボード機能を提供します。

New Relic

New Relicは、包括的なオブザーバビリティプラットフォームとして、APM（Application Performance Monitoring）、インフラ監視、ログ管理、分散トレーシングなどの機能を統合的に提供するSaaSソリューションです。

主要機能で比べてみた

OpenSearchとNew Relicをオブザーバービリティツールの観点から比較してみました。

今回の比較では、OpenSearch 2.xとNew Relicを対象としています。2025年5月にOpenSearch 3.0がリリースされていますが、2025年6月段階ではAWSではまだ利用できないため、現在利用可能なバージョンでの比較となります。

ログ管理

OpenSearch

OpenSearchはログ管理において以下の強力な機能を提供します：

• 柔軟なスキーマ: 任意のログ形式に対応可能
  OpenSearch は「動的スキーマ（Dynamic Mapping）」を採用しており、事前にスキーマを厳密に定義しなくても、初回インデックス時にフィールド型を自動で推定して処理できます。
  

• 高速検索: Luceneベースの強力な検索エンジンによる高速処理
  Apache Luceneという実績のある検索ライブラリをベースとしており、数億件のログレコードからでも数秒以内で目的のデータを検索できます。インデックス構造により、全文検索でも高速な応答を実現します。
  

• 複雑なクエリ: Boolean、ファジー、正規表現検索など多様な検索オプション
  AND/OR/NOTを組み合わせた論理検索、タイポを許容するあいまい検索、パターンマッチングによる正規表現検索が可能です。これにより、「エラーを含むが特定のユーザーIDを除外」といった複雑な条件での検索が実現できます。
  

• 大容量対応: TB〜PB級のログデータ処理が可能
  水平スケーリング（サーバー台数を増やす）により、テラバイトからペタバイト規模の大量ログデータを効率的に処理できます。データが増加してもパフォーマンスを維持できる設計です。
  

• リアルタイム分析: ほぼリアルタイムでの検索・分析機能
  ログが生成されてから数秒以内に検索・分析が可能になります。システム障害の早期発見や、リアルタイムでのトラフィック監視に活用できます。
  

New Relic

New Relicのログ管理機能は以下の特徴があります：

• 検索機能: NRQLを利用した検索システム

  • NRQL（New Relic Query Language）というSQL風のクエリ言語を使用してログを検索します。SQLに慣れた開発者には学習コストが低く、集計やグループ化などの操作も直感的に行えます。

• 柔軟なログ形式: 構造化・非構造化ログの両方に対応

  • New Relic Logsは構造化ログ（JSON）を推奨していますが、プレーンテキストログも取り込み可能です。ただし、構造化ログの方がNRQLでの検索・分析において効率的です。

• 全文検索: 基本的な検索機能を提供

  • 基本的な文字列検索は可能ですが、Elasticsearchのような高度な全文検索機能（スコアリング、アナライザーのカスタマイズなど）は限定的な範囲での提供となります。

メトリクス

OpenSearch

メトリクス管理においてOpenSearchは以下の特徴があります：

• 時系列データの取り扱い: 汎用検索エンジンとしての設計
  OpenSearchは汎用的な検索エンジンのため、時系列データに特化したデータベースと比較すると、メトリクスデータの保存・集計において異なるアプローチを取ります。特に長期間のメトリクス保存では、ストレージ使用量が多くなる傾向があります。
  

• 集計処理: リアルタイム計算と事前集計の両方に対応
  OpenSearchはRollup機能により、時系列データの事前集計（平均値、最大値、パーセンタイルなど）を保存できます。これにより、長期間のデータでも高速な集計表示が可能です。ただし、設定には専門知識が必要です。
  

• メトリクス機能: ログ検索に特化した設計
  OpenSearch には Anomaly Detection や可視化ツール（Dashboards）を通じて、一定のメトリクス分析・相関分析・異常検知が可能です。ただし、New Relic のような機械学習ベースの高度な分析機能と比較すると、機能は限定的です。
  

New Relic

New Relicはメトリクス管理において優れた機能を提供します：

• 自動メトリクス収集: アプリケーション性能メトリクスの自動収集
  アプリケーションにエージェントをインストールするだけで、CPU使用率、メモリ使用量、データベース応答時間、外部API呼び出し時間などの重要なメトリクスを自動的に収集・監視できます。
  

• 事前定義メトリクス: レスポンス時間、スループット、エラー率などの標準メトリクス
  Webアプリケーションで重要とされる「Golden Signals」（レスポンス時間、リクエスト数、エラー率、リソース使用率）が標準で用意されており、すぐに監視を開始できます。
  

• 時系列最適化: 時系列データの効率的な保存・処理
  メトリクスデータに特化したデータ構造により、長期間のデータ保存と高速な集計処理を実現します。データ圧縮技術により、ストレージコストも効率化されています。
  

• 異常検知: 機械学習による自動異常検知機能
  過去のメトリクスパターンを学習し、通常とは異なる値を自動的に検出してアラートを発生させます。閾値を手動設定する必要がなく、動的な異常検知が可能です。
  

• 相関分析: メトリクス間の関係性分析
  複数のメトリクス間の関連性を分析し、問題の根本原因を特定しやすくします。例えば、レスポンス時間の悪化とデータベース接続数の増加の関係を自動的に発見できます。
  

トレーシング

OpenSearch

トレーシング機能においてOpenSearchは以下の特徴があります：

• 実装アプローチ: Trace Analyticsによる分散トレーシング
  OpenSearchはTrace Analytics機能を提供しており、OpenTelemetryと統合して分散トレーシングデータの収集・可視化が可能です。ただし、New Relicと比較すると自動インストルメンテーション機能は限定的です。
  

• 可視化機能: 基本的な可視化機能を提供
  トレースデータの関係性を視覚的に表示する機能は基本的なものが提供されています。複雑なマイクロサービス間の呼び出し関係については、専用ツールと比較してシンプルな表示となります。
  

• 分析機能: ログベースの分析アプローチ
  ボトルネック分析、エラー伝播の追跡、パフォーマンス劣化の原因特定などは、主にログデータの分析を通じて行うアプローチとなります。
  

• インストルメンテーション: カスタマイズ可能な設定
  フレームワークやライブラリの自動計測機能は限定的で、多くの場合、開発者が手動でトレースポイントを設定する必要がありますが、これにより細かな制御が可能です。
  

New Relic

New Relicは包括的なトレーシング機能を提供します：

• 自動インストルメンテーション: コード変更を最小限に抑えたトレーシング
  主要なプログラミング言語とフレームワークに対応したエージェントにより、アプリケーションコードを変更することなく、自動的にトレース情報を収集できます。
  

• サービスマップ: 依存関係の自動可視化
  マイクロサービス間の呼び出し関係を自動的に検出し、視覚的なサービスマップとして表示します。システム全体のアーキテクチャと依存関係が一目で理解できます。
  

• エラー追跡: トレース内でのエラー詳細表示
  エラーが発生したトランザクションについて、エラーが発生したサービス、メソッド、時刻、エラーメッセージなどの詳細情報を、トレース情報と関連付けて表示します。
  

• パフォーマンス分析: ボトルネック特定機能
  各サービスやメソッドの実行時間を分析し、システム全体のパフォーマンスボトルネックを自動的に特定します。最も時間のかかっている処理を優先的に改善できます。
  

• 分散トレーシング: マイクロサービス間の完全な追跡
  単一のリクエストが複数のマイクロサービスを横断する際の、完全な実行経路と各サービスでの処理時間を追跡できます。
  

APM

OpenSearch

• APMアプローチ: Observabilityプラグインによる監視
  OpenSearchはObservabilityプラグインを通じて、OpenTelemetryデータの可視化、トレース分析、メトリクス表示などの機能を提供します。ただし、エージェントベースの自動計測やコード分析などの高度なAPM機能はNew Relicと比較して限定的で、主にデータの可視化と基本的な分析に焦点を当てています。
  

• 調査手法: ログやメトリクスを組み合わせた分析
  アプリケーションの性能問題を調査する際は、ログファイルの詳細な分析や基本的なメトリクス情報を組み合わせて、手動で原因を特定するアプローチとなります。
  

New Relic

• 統合APM機能: Application Performance Monitoringの包括的な機能
  Application Performance Monitoringの包括的な機能が標準で提供されており、アプリケーションのレスポンス時間、スループット、エラー率、データベースクエリ性能、外部サービス呼び出し性能などを統合的に監視し、パフォーマンス問題の早期発見と根本原因分析が可能です。
  

まとめ

ソフトウェアの発祥が違いますので、上記のようにさまざまな違いがあります。そのため、目的・用途によって使い分けるのがよいでしょう。使い分け方としては以下の方法がよいでしょう。

適しているシーン

OpenSearch Services・OpenSearch Dashboards

以下のような要件に適しています：

• ログ中心のシステム: 主にログ分析が中心の監視要件
  アプリケーションログ、Webサーバーログ、システムログなどの大量テキストデータの検索・分析が主要な用途である場合に最適です。
  

• データ検索を多用する: 複雑な検索クエリが頻繁に必要
  「特定の期間内で特定のユーザーが実行したエラーを含むアクション」のような複雑な条件での検索を日常的に行う場合に威力を発揮します。
  

• 監視対象はAWSサービスが中心である: AWS環境に特化した監視
  EC2、RDS、Lambda、CloudFrontなど、AWS内のサービスを主要な監視対象とする場合、AWS統合により簡単にセットアップできます。
  

• 基本的なメトリクス監視、トレース監視で十分: シンプルな監視要件
  CPU使用率、メモリ使用率、ディスク使用率などの基本的なシステムメトリクスの監視で運用要件を満たせる場合に適しています。
  

• 基本的な通知機能で十分: シンプルなアラート機能
  閾値を超えた際のメール通知やSlack通知など、基本的なアラート機能で運用要件を満たせる場合に適しています。
  

New Relic

以下のような要件に適しています：

• AWS、GCP、Azureなど複数のクラウドサービスを監視したい: マルチクラウド環境の統合監視
  ハイブリッドクラウドやマルチクラウド環境で、異なるクラウドプロバイダーのリソースを統一的に監視・管理したい場合に最適です。
  

• APM（Application Performance Monitoring）を利用したい: アプリケーション性能の詳細な監視
  Webアプリケーションやマイクロサービスのパフォーマンス問題を迅速に特定し、ユーザー体験の向上を図りたい場合に必要不可欠です。
  

• すべてのログを一括で検証、管理をしたい: 統合ログ管理
  アプリケーションログ、インフラログ、セキュリティログなど、システム全体の様々なログを一つのプラットフォームで統合管理し、横断的な分析を行いたい場合に適しています。ログの相関分析により、問題の全体像を把握できます。
  

• 通知手段が豊富で、高度な通知設定を活用したい: 重複アラートの自動統合など高度な通知機能
  Slack、PagerDuty、Webhook、SMS、メールなど多様な通知チャネルに対応し、アラートの重要度に応じた通知先の振り分け、同一原因による重複アラートの自動統合、エスカレーション機能など、運用チームの効率化に必要な高度な通知機能を活用したい場合に最適です。
  

補足: 選択の際は、現在の監視要件だけでなく、将来的な拡張性や運用コストも考慮することが重要です。OpenSearchは初期コストを抑えてログ中心の監視から始めたい場合に適しており、New Relicは包括的な監視機能が必要で、運用効率を重視する場合に適しています。これらのツールを選択する際には、チームのスキルレベルや学習コスト、既存システムとの統合性も考慮にいれる必要があることを忘れてはいけません。

それぞれのツールには明確な特徴と強みがあり、組織の要件や技術的な制約に応じて最適な選択が異なります。OpenSearchはログデータの柔軟な検索・分析に優れ、New Relicは統合的なアプリケーション監視に特化しているため、監視戦略全体を考慮した上で適切なツールを選択してください。