Amazon OpenSearch Service で構築するログ分析基盤 - インデックス設計とダッシュボード構築
OpenSearch Service によるログ分析基盤の構築、インデックスライフサイクル管理、OpenSearch Dashboards の活用法を解説します。
OpenSearch Service の概要と Serverless
この記事は約 4 分で読めます。 OpenSearch Service は Elasticsearch 互換の検索・分析エンジンのマネージドサービスです。ログ分析、全文検索、アプリケーションモニタリング、セキュリティ分析に広く使用されています。プロビジョンドドメインではインスタンスタイプとノード数を指定してクラスタを構成しますが、OpenSearch Serverless ではクラスタ管理が完全に不要です。Serverless はコレクション (インデックスのグループ) を作成するだけで、キャパシティが自動スケールします。ログ分析のように取り込み量が変動するワークロードに特に適しています。
この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。
ログ収集とインデックス設計
ログの収集は Kinesis Data Firehose 経由が標準的なパターンです。CloudWatch Logs のサブスクリプションフィルターで Firehose にログを送信し、Firehose が OpenSearch にバッチで書き込みます。インデックスは日次 (logs-2026-04-03) で作成し、検索範囲を日付で限定することでクエリ性能を維持します。マッピング (スキーマ) はインデックステンプレートで事前定義し、フィールドの型 (keyword、text、date、ip) を明示的に指定します。text 型は全文検索に、keyword 型は完全一致とアグリゲーションに使用します。ログの構造が不定の場合は dynamic mapping を活用しますが、フィールド数の爆発 (mapping explosion) に注意が必要です。
ライフサイクル管理とコスト最適化
ISM ポリシーでインデックスのライフサイクルを自動管理します。典型的な設計として、作成後 7 日間はホットノード (高速 SSD) で保持し、7-30 日は UltraWarm (S3 ベースの低コストストレージ) に移行し、30-90 日は Cold Storage に移行し、90 日後に削除するポリシーが挙げられます。UltraWarm は Hot と比較して最大 90% のコスト削減が可能で、検索性能は若干低下しますが、過去ログの調査には十分です。OpenSearch Dashboards で Discover (ログの検索)、Visualize (グラフの作成)、Dashboard (複数グラフの統合) を使用し、リアルタイムのログ監視ダッシュボードを構築します。
さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。
まとめ
OpenSearch Service はログ分析基盤の標準的な選択肢です。Serverless でクラスタ管理を排除し、ISM ポリシーでストレージコストを最適化し、Dashboards でリアルタイム監視を実現します。Kinesis Data Firehose との統合で、AWS サービスのログを自動的に収集・分析する基盤を構築できます。
AWS の優位点
- CloudWatch Logs、VPC フローログ、CloudTrail、ALB アクセスログを OpenSearch に集約し、横断的な検索・分析が可能
- OpenSearch Serverless でクラスタ管理が不要になり、インデックスの作成とクエリに集中できる
- Index State Management (ISM) ポリシーでインデックスのライフサイクル (ホット → ウォーム → コールド → 削除) を自動管理し、ストレージコストを最適化できる
- OpenSearch Dashboards で Kibana 互換のビジュアライゼーションとダッシュボードを構築し、リアルタイムのログ監視が可能
- UltraWarm と Cold Storage で低頻度アクセスのログデータを低コストで保持し、必要時に検索できる