Amazon OpenSearch Service 設計パターン5選｜SAA-C03 頻出のログ分析・全文検索・リアルタイム分析アーキテクチャ完全攻略
AWS SAA-C03 で頻出の Amazon OpenSearch Service を完全整理。ログ分析パイプライン（CloudWatch Logs → Firehose → OpenSearch）・全文検索・セキュリティインシデント分析・OpenSearch Serverless の設計パターンを体系化。UltraWarm・Cold Storage によるコスト最適化、Athena/Redshift との使い分け表まで、試験シナリオを解法パターンで一気に整理する。
「OpenSearch は何でも検索できる万能ツールではない。『リアルタイム性・全文検索性・ログ集約性』の3要件が揃ったときに選ぶ。SAA では Athena・Redshift との使い分けと、CloudWatch Logs → Firehose → OpenSearch パイプラインの構成が毎回出題される」 — 本記事では SAA-C03 頻出の OpenSearch Service 設計パターン5選を体系化し、試験シナリオを即座に解ける判定軸を身につける。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：OpenSearch を選ぶ場面の判定軸
- パターン1：ログ分析パイプライン（CloudWatch → Firehose → OpenSearch）
- パターン2：全文検索（DynamoDB Streams → Lambda → OpenSearch）
- パターン3：セキュリティインシデント分析（CloudTrail + GuardDuty → OpenSearch）
- パターン4：OpenSearch Serverless（サーバーレス全文検索）
- ドメイン設計とコスト最適化（専用マスターノード・UltraWarm・Cold Storage）
- 試験頻出シナリオ → 解法パターン早見表
- OpenSearch vs Athena vs Redshift 使い分け表
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：OpenSearch を選ぶ場面の判定軸
Amazon OpenSearch Service（旧 Amazon Elasticsearch Service）を選ぶべき場面は「リアルタイム性・全文検索性・ログ集約性の3要件が揃ったとき」に限る。SAA 試験では「ログをリアルタイムで検索したい」「商品カタログを全文検索したい」「セキュリティインシデントを即座に調査したい」という3パターンが最も多く出題される。
| 要件 | OpenSearch | Athena | Redshift |
|---|---|---|---|
| リアルタイム検索（秒以下） | ✅ 最適 | ❌ クエリ遅延あり | △ 高速だがコスト高 |
| 全文検索・日本語検索 | ✅ kuromoji 対応 | ❌ 非対応 | ❌ 非対応 |
| ログ集約・可視化 | ✅ Dashboards 内蔵 | ❌ 別途可視化が必要 | ❌ 別途 BI ツール必要 |
| 大規模バッチ分析 | ❌ 不向き | ✅ S3 ペタバイト級対応 | ✅ DWH として最適 |
| 構造化 SQL 分析 | ❌ SQL 未対応 | ✅ 標準 SQL | ✅ PostgreSQL 互換 |
OpenSearch Service の主なコンポーネント：
| コンポーネント | 役割 |
|---|---|
| OpenSearch クラスター | インデックス・検索エンジン本体 |
| OpenSearch Dashboards | 可視化・ダッシュボード・アラート（旧 Kibana） |
| UltraWarm | S3 バックエンドの低コスト読み取り専用ストレージ |
| Cold Storage | UltraWarm よりさらに低コストのアーカイブ層 |
| OpenSearch Serverless | インフラ管理不要のサーバーレス版 |
2. パターン1：ログ分析パイプライン（CloudWatch → Firehose → OpenSearch）
適用シナリオ
- アプリケーションログ・アクセスログをリアルタイムで検索・可視化したい
- 複数の AWS サービスからのログを一元管理したい
- ログから異常なパターンを即座に発見したい
アーキテクチャ
[アプリケーション / AWS サービス]
↓
[Amazon CloudWatch Logs]（ログ収集）
↓ サブスクリプションフィルター
[Amazon Kinesis Data Firehose]（バッファリング・変換）
↓
[Amazon OpenSearch Service]（インデックス・検索）
↓
[OpenSearch Dashboards]（可視化・アラート）設定のポイント
CloudWatch Logs から Firehose へのサブスクリプションフィルターを設定するだけで、ログを自動的に OpenSearch に転送できる。Firehose はバッファリング（最大 900 秒または 128 MB）を行うため、完全なリアルタイムではなく「ほぼリアルタイム」（数秒〜数分遅延）になる。
# サブスクリプションフィルターの設定例（AWS CLI）
aws logs put-subscription-filter \
--log-group-name "/aws/lambda/my-function" \
--filter-name "AllLogs" \
--filter-pattern "" \
--destination-arn "arn:aws:firehose:ap-northeast-1:123456789012:deliverystream/opensearch-delivery"代替パターン：Kinesis Data Streams → Lambda → OpenSearch
より細かい変換ロジックが必要な場合や、OpenSearch への書き込みを細かく制御したい場合は、Firehose の代わりに Kinesis Data Streams + Lambda を使う。
[CloudWatch Logs] → [Kinesis Data Streams] → [Lambda]（変換・エンリッチ） → [OpenSearch]Lambda を経由することで、ログのパース・フィルタリング・フィールド追加などカスタム変換を挟める。ただし Firehose のほうが運用コストが低い。
3. パターン2：全文検索（DynamoDB Streams → Lambda → OpenSearch）
適用シナリオ
- DynamoDB に保存した商品カタログ・記事・ドキュメントを全文検索したい
- 日本語検索（形態素解析）が必要
- 既存の DynamoDB スキーマを変更せずに検索機能を追加したい
アーキテクチャ
[クライアント]
↓ 検索リクエスト
[API Gateway + Lambda]（検索クエリを OpenSearch に発行）
↓
[Amazon OpenSearch Service]
（DynamoDB のデータのコピー＋全文インデックスを保持）
↑
[AWS Lambda]（DynamoDB Streams のトリガーで自動同期）
↑
[DynamoDB Streams]（DynamoDB のデータ変更をキャプチャ）
↑
[Amazon DynamoDB]（マスターデータ）設計の要点
DynamoDB はマスターデータとして使い続け、OpenSearch には「検索用のレプリカ」を持つ。DynamoDB Streams + Lambda で変更を検知し、OpenSearch のインデックスをリアルタイムに更新する。
4. パターン3：セキュリティインシデント分析（CloudTrail + GuardDuty → OpenSearch）
適用シナリオ
- CloudTrail・GuardDuty・Security Hub のログを一元化してセキュリティ分析したい
- 不審なアクティビティのリアルタイムアラートと調査を行いたい
- SIEM（Security Information and Event Management）を AWS で構築したい
アーキテクチャ
[AWS CloudTrail]（API コール記録） ─┐
[Amazon GuardDuty]（脅威検出結果） ├─→ [Amazon S3] → [Firehose] → [OpenSearch]
[AWS Security Hub]（統合セキュリティ） ─┘ ↓
[Amazon VPC Flow Logs]（通信記録） ──→ [CloudWatch Logs] [OpenSearch Dashboards]
↓ （SIEM ダッシュボード）
サブスクリプション
フィルター → Firehose ──→ [OpenSearch]SIEM 構築のポイント
OpenSearch Dashboards（旧 Kibana）を使って複数のセキュリティログを横断的に可視化できる。不審な API コールのパターンや GuardDuty が検出した脅威を即座にドリルダウンでき、調査効率が大幅に向上する。
5. パターン4：OpenSearch Serverless（サーバーレス全文検索）
OpenSearch Serverless とは
OpenSearch Serverless は 2023 年に GA になったサーバーレス版 OpenSearch。インフラ管理不要でスケールアウト/インが自動化され、ノード数・インスタンスタイプを事前に見積もる必要がない。
| 項目 | OpenSearch（従来型） | OpenSearch Serverless |
|---|---|---|
| インフラ管理 | ノード数・インスタンスタイプを手動設定 | 自動スケール（OCU 単位） |
| コスト | 24 時間稼働のインスタンス料金 | 使用量ベース（OCU + ストレージ） |
| 起動速度 | クラスター作成に数分 | コレクション作成は数秒 |
| 用途 | 大規模・予測可能なワークロード | 不規則・突発的なワークロード |
| UltraWarm | サポート | 非対応 |
| 専用マスターノード | サポート | 不要（自動管理） |
OpenSearch Serverless のコレクション種別
| コレクション種別 | 用途 |
|---|---|
| Search | 全文検索・製品検索（ドキュメント中心） |
| Time series | ログ・メトリクス（時系列データ中心） |
| Vector search | 機械学習・埋め込みベクトル検索 |
6. ドメイン設計とコスト最適化（専用マスターノード・UltraWarm・Cold Storage）
専用マスターノードの役割
本番環境では 専用マスターノード（Dedicated master node）を設置する。マスターノードはクラスターの状態管理（ノードの追加・削除・シャード配置）を専任で行い、データノードの処理に影響しない。
推奨構成（本番環境）
専用マスターノード: 3 台（奇数台で split-brain 防止）
データノード: 最低 2 台（マルチ AZ で冗長化）
レプリカシャード: 1 以上（耐障害性）UltraWarm と Cold Storage によるコスト最適化
| ストレージ層 | 特徴 | ユースケース |
|---|---|---|
| ホット（EBS） | 読み書き最高速 | 直近 30 日のアクティブなログ |
| UltraWarm（S3 + EBS キャッシュ） | ホットの 1/5〜1/10 のコスト、読み取り可能 | 30〜90 日の参照頻度が低いログ |
| Cold Storage（S3） | UltraWarm の 1/10 以下のコスト | 90 日以降のアーカイブ（オフラインに近い） |
マルチ AZ とシャード設計
本番ドメインは必ずマルチ AZ を設定する。推奨は 3 AZ 構成（ap-northeast-1a/b/c）で、プライマリシャードを 3 の倍数にすると各 AZ に均等に分散される。
| 設定 | 開発環境 | 本番環境 |
|---|---|---|
| AZ 数 | 1 | 2〜3（3 推奨） |
| 専用マスターノード | 不要 | 3 台（奇数） |
| レプリカシャード | 0 | 1 以上 |
| 自動スナップショット | 1日1回 | 1時間ごと（手動設定） |
7. 試験頻出シナリオ → 解法パターン早見表
| シナリオ（要件文キーワード） | 正解パターン | 落とし穴 |
|---|---|---|
| 「アプリケーションログをリアルタイムで検索・可視化したい」 | CloudWatch Logs → Firehose → OpenSearch | CloudWatch Logs Insights は単一ロググループ向け、横断検索には OpenSearch |
| 「DynamoDB の商品データを全文検索したい」 | DynamoDB Streams → Lambda → OpenSearch | DynamoDB の GSI は等値検索のみ、全文検索は不可 |
| 「S3 のログを定期的に分析したい（即時性不要）」 | Amazon Athena | 即時性不要なら OpenSearch は過剰コスト |
| 「セキュリティログを一元化してリアルタイムに調査したい」 | CloudTrail + GuardDuty → Firehose → OpenSearch | CloudWatch Logs Insights は複数サービス横断が苦手 |
| 「最小運用でスケールアウトする全文検索が欲しい」 | OpenSearch Serverless | 従来型は事前にノード数を見積もる必要がある |
| 「大量の過去ログを低コストで保管しつつ検索したい」 | UltraWarm / Cold Storage の 3 階層 ILM 構成 | 全データをホットに置くとコスト爆増 |
| 「OpenSearch のデータノード障害でもサービスを継続したい」 | マルチ AZ + 専用マスターノード 3 台 + レプリカシャード 1 以上 | シングル AZ 構成は可用性設計の誤答 |
| 「ペタバイト規模の構造化データをアドホック SQL で分析したい」 | Amazon Redshift または Athena | OpenSearch は大規模バッチ SQL 分析に不向き |
8. OpenSearch vs Athena vs Redshift 使い分け表
| 観点 | Amazon OpenSearch | Amazon Athena | Amazon Redshift |
|---|---|---|---|
| 主な用途 | 全文検索・ログ分析・可視化 | S3 上のアドホック SQL 分析 | データウェアハウス・複雑な集計 |
| クエリ言語 | OpenSearch DSL（JSON） | 標準 SQL | PostgreSQL 互換 SQL |
| 全文検索 | ✅ ネイティブ対応（kuromoji） | ❌ 非対応 | ❌ 非対応 |
| データ鮮度 | リアルタイム（秒以内） | S3 更新後すぐ参照可能 | COPY コマンドでロード後 |
| スケール | 数十 TB まで（UltraWarm 活用で拡張） | ペタバイト級（S3 活用） | ペタバイト級（RA3 ノード） |
| コスト特性 | インスタンス常時起動 | スキャン量課金（$5/TB） | ノード常時起動（RA3 は S3 分離） |
| SAA での選択基準 | 全文検索・ログ分析・SIEM 構築 | S3 上のデータを SQL で一時分析 | DWH・BI・長期集計分析 |
9. 次のアクション チェックリスト
- OpenSearch ドメインをマルチ AZ（3 AZ 推奨）で構成しているか
- 専用マスターノード 3 台（奇数）を設定しているか（本番環境）
- UltraWarm / Cold Storage を使った 3 階層 ILM を設定しているか
- CloudWatch Logs → Firehose → OpenSearch のサブスクリプションフィルターが機能しているか
- Firehose のサービスロールに OpenSearch への
es:ESHttp*権限を付与しているか - DynamoDB 連携では DynamoDB Streams + Lambda で同期処理を実装しているか
- OpenSearch Serverless（突発的・不規則ワークロード）と従来型（定常的・大規模ワークロード）を要件で使い分けられるか
- 本番ドメインが VPC 内に配置され、パブリックエンドポイントを無効化しているか
10. 関連記事
- Amazon Kinesis Data Streams 完全ガイド
- Amazon Kinesis Data Firehose 完全ガイド
- Amazon CloudWatch Logs 完全ガイド
- AWS CloudTrail 完全ガイド
- Amazon GuardDuty 完全ガイド
- Amazon Athena 完全ガイド
- Amazon Redshift 完全ガイド
- SAA Kinesis ストリーミング設計パターン
- SAA データレイク設計パターン
- SAA CloudWatch 監視設計パターン