Amazon OpenSearch Service で構築するログ分析基盤 - インデックス設計とダッシュボード構築
ログ分析基盤を構築し、インデックスライフサイクル管理でコストを最適化する。OpenSearch Dashboards と Serverless モードの活用を紹介します。
OpenSearch Service の概要と Serverless
OpenSearch Service は Elasticsearch 互換の検索・分析エンジンのマネージドサービスで、ペタバイト規模のデータに対してミリ秒単位の検索レスポンスを提供します。ログ分析、全文検索、アプリケーションモニタリング、セキュリティ分析に広く使用されています。プロビジョンドドメインではインスタンスタイプとノード数を指定してクラスタを構成しますが、OpenSearch Serverless ではクラスタ管理が完全に不要です。Serverless はコレクション (インデックスのグループ) を作成するだけで、キャパシティが自動スケールします。Serverless のコレクションには検索用 (search) と時系列用 (timeseries) の 2 種類があり、ログ分析には時系列タイプが適しています。時系列コレクションはデータの取り込みに最適化されており、古いデータを自動的に低コストストレージに移行します。プロビジョンドドメインは細かなチューニングが可能ですが、ノード障害時の自動復旧やシャードリバランスの運用負荷が発生します。取り込み量が日中と夜間で大きく変動するログワークロードでは、Serverless のオートスケーリングがコスト面でも運用面でも有利に働きます。
ログ収集とインデックス設計
ログの収集は Kinesis Data Firehose 経由が標準的なパターンで、1 秒あたり最大 1,000 レコードのバッチ書き込みに対応します。CloudWatch Logs のサブスクリプションフィルターで Firehose にログを送信し、Firehose が OpenSearch にバッチで書き込みます。インデックスは日次 (logs-2026-04-03) で作成し、検索範囲を日付で限定することでクエリ性能を維持します。マッピング (スキーマ) はインデックステンプレートで事前定義し、フィールドの型 (keyword、text、date、ip) を明示的に指定します。text 型は全文検索に、keyword 型は完全一致とアグリゲーションに使用します。ログの構造が不定の場合は dynamic mapping を活用しますが、フィールド数の爆発 (mapping explosion) に注意が必要です。フィールド数上限はデフォルトで 1,000 ですが、マイクロサービスごとに異なるカスタムフィールドが追加される環境では容易に到達します。対策として、インデックスをサービス単位で分割する、あるいは構造化が困難なフィールドを 1 つの JSON 文字列として keyword 型に格納して必要時にスクリプトで解析するアプローチが有効です。シャード数はインデックスあたり 10-50 GB を目安に設計し、シャードが小さすぎるとクラスタのオーバーヘッドが増加、大きすぎるとリカバリ時間が延びます。
ライフサイクル管理とコスト最適化
ISM ポリシーでインデックスのライフサイクルを自動管理します。典型的な設計として、作成後 7 日間はホットノード (高速 SSD) で保持し、7-30 日は UltraWarm (S3 ベースの低コストストレージ) に移行し、30-90 日は Cold Storage に移行し、90 日後に削除するポリシーが挙げられます。UltraWarm は Hot と比較して最大 90% のコスト削減が可能で、検索性能は若干低下しますが、過去ログの調査には十分です。Cold Storage はさらに低コストでデータを保持し、必要時にクラスタにアタッチして検索可能にします。ISM ポリシーの設計で陥りがちな落とし穴は、rollover 条件の設定ミスです。max_size を 50 GB、max_age を 1 日に設定した場合、どちらかの条件を先に満たした時点で新インデックスが作成されます。取り込み量が少ない環境で max_size だけを条件にすると、インデックスが長期間オープンのままとなり、UltraWarm への移行が遅れてコストがかさみます。OpenSearch Dashboards で Discover (ログの検索)、Visualize (グラフの作成)、Dashboard (複数グラフの統合) を使用し、リアルタイムのログ監視ダッシュボードを構築します。 OpenSearch の設計パターンを網羅的に学ぶなら、技術書 (Amazon)を参照してください。
CloudWatch Logs Insights との比較と使い分け
ログ分析には CloudWatch Logs Insights も選択肢に入ります。Logs Insights は CloudWatch Logs に保存されたログをそのままクエリでき、追加インフラの構築が不要で、スキャンしたデータ量に対する従量課金のみで動作します。一方 OpenSearch は、複数フィールドにまたがる複雑な集計、ダッシュボードによるリアルタイム可視化、全文検索やファセット分析に強みがあります。選択の基準として、ログ量が月間数十 GB 未満でクエリが単純 (フィルタリング + 集計) なら Logs Insights がコスト効率に優れます。ログ量が月間数百 GB を超える、相関分析やアラート条件の柔軟な設定が必要、あるいは複数 AWS アカウントのログを横断検索する場合は OpenSearch が適しています。両者を併用するパターンも有効で、即時的なトラブルシューティングは Logs Insights で行い、長期傾向分析や高度なダッシュボードは OpenSearch に集約する構成が実務で多く採用されています。
設計のベストプラクティスと落とし穴
本番運用で頻出するトラブルと回避策を整理します。まず取り込みスパイクへの対策として、Firehose のバッファサイズとバッファ間隔を調整し、OpenSearch 側の bulk 拒否 (HTTP 429) を防ぎます。バッファ間隔を 60-300 秒に設定すると、短時間の大量ログ発生時にも平準化されます。次にクラスタの安定性として、専用マスターノードを 3 台配置することでスプリットブレインを防止し、データノード障害時のシャード再配置をマスターが安全に管理します。ストレージ容量はデータノードの総ディスクの 80% を超えないよう設計し、超過するとインデックスが read-only に切り替わって書き込みが停止します。セキュリティ面では、ドメインへのアクセスを VPC 内に閉じ、きめ細かいアクセス制御 (FGAC) でインデックス単位・フィールド単位の権限を設定します。監査ログを有効化してユーザーの操作を記録し、コンプライアンス要件を満たすことも重要です。最後に、Serverless を選択した場合でも OCU (OpenSearch Compute Unit) の最小値設定に注意が必要で、最小 OCU を 0 にすると初回クエリでコールドスタートが発生し、応答に数秒かかる場合があります。
まとめ
OpenSearch Service はログ分析基盤の標準的な選択肢です。Serverless でクラスタ管理を排除し、ISM ポリシーでストレージコストを最適化し、Dashboards でリアルタイム監視を実現します。Kinesis Data Firehose との統合で、AWS サービスのログを自動的に収集・分析する基盤を構築できます。CloudWatch Logs Insights との使い分けを明確にし、シャード設計・ISM ポリシー・セキュリティ設定のベストプラクティスを押さえることで、安定してスケールするログ分析基盤を運用できます。