DEA / ドメイン2 データストア管理
Amazon OpenSearch Service
は、全文検索、ログの分析と可視化、を行うです。オープンソースの OpenSearch (Elasticsearch から派生) を動かし、OpenSearch Dashboards で可視化します。DEA-C01 では、検索とログ分析のためのデータストアとしての選び方、インデックスとの考え方、OpenSearch Serverless と OpenSearch Ingestion、・コールドストレージによるコストの削減が問われます。
Point
- インデックス (index): ドキュメント (JSON) を入れる入れ物です。RDB のテーブルに近い単位です。
- シャード (shard): インデックスを分割したかけらです。プライマリシャードとそのコピーのレプリカシャードがあります。
- 転置インデックス (inverted index): 単語から、その単語を含むドキュメントを引ける索引です。全文検索が速い理由です。
- 和訳
- Shard: 破片、かけら
- Weblio英和辞書「shard」
概要
| 提供形態 | 容量の管理 | 向くケース |
|---|---|---|
| マネージドドメイン | インスタンスの種類と数、ストレージを自分で選ぶ | 細かい調整、・コールドの階層、大規模で安定した負荷 |
| Serverless | 自動 (OCU で課金) | 容量の計画をしたくない、負荷が変動する |
試験では、「全文検索」「ログを数秒で検索・可視化」「キーワード検索との組み合わせ」とあれば OpenSearch を選びます。長期の安価な保管や大規模な 集計は や が担います。
主要技術
①インデックス・シャード・ドメインの構成
| 要素 | 内容 | 設計の観点 |
|---|---|---|
| プライマリ | インデックスのデータを分けて持つ。作成後に数を変えるには作り直し (reindex) や分割が必要 | 1シャードを数十 GiB 程度に収める。小さすぎるシャードが多いとメモリと を浪費する |
| レプリカシャード | プライマリのコピー。読み取りを分担し、障害に備える | 本番では1つ以上 |
| データノード | シャードを持ち、検索と書き込みを処理する | 3つの に分けて置く |
| 専用マスターノード | クラスターの状態を管理する | 本番では3台を推奨。 の前提 |
| with Standby | 1つの AZ を待機にして、AZ の障害でもすぐ切り替える | 高い可用性が必要な本番 |
ログのように時間で増えるデータは、日ごとや週ごとにインデックスを分け (時系列インデックス)、古いインデックスを丸ごと階層移動・削除できるようにします。
②ストレージの階層とインデックスのライフサイクル ⚠️ 頻出
| 階層 | 置き場所 | 読み書き | 向くデータ |
|---|---|---|---|
| ホット | データノードのや | 読み書きとも最速 | 直近のログ、活発に検索するデータ |
| + | 読み取り専用 (書き込むにはホットへ戻す) | 書き込みの終わった、ときどき検索するログ | |
| コールドストレージ | S3 | 読み書きできない (使うときは UltraWarm へ戻す) | めったに見ないが、すぐ消せない過去のログ |
UltraWarm は、専用マスターノードを持つドメインで使えます。S3 を使うため、ホットのようなレプリカの容量が要らず、使った容量だけ課金されます。
Index State Management (ISM) のポリシーで、「作成から7日でUltraWarm へ、30日でコールドへ、90日で削除」のような移行を自動化します。
③OpenSearch Serverless
Serverless は、クラスターを用意せずに使える形態です。インデックス作成 (取り込み) と検索の処理を分け、データは に置きます。処理能力は OCU (1 OCU = メモリ 6 GiB と対応する vCPU) で数え、取り込みと検索で別々に自動で増減します。
| コレクションタイプ | 用途 | 特徴 |
|---|---|---|
| 時系列 (Time series) | ログ分析 | 直近をホット、古いものをウォームに置く。カスタムのドキュメント ID での書き込み・ はできない |
| 検索 (Search) | 全文検索 | すべてホットに置き、応答を速くする |
| (Vector search) | 、 | k-NN のインデックスを使える (他の2つでは使えない) |
| 注意点 | 内容 |
|---|---|
| タイプの変更 | 作成後に変えられない |
| アカウントをまたぐ | 他のアカウントのコレクションへのアクセスは設定できない |
| 自動のスナップショットのみ (手動はない) | |
| 移行 | マネージドドメインからの自動移行はなく、再インデックスが必要 |
ナレッジベースのストアとしてもよく使われます (「ベクトル検索とベクトルインデックス」の章)。
④データの取り込み (OpenSearch Ingestion など) ⚠️ 頻出
| 取り込み方 | 内容 | 向くケース |
|---|---|---|
| Amazon Ingestion | のデータパイプライン (オープンソースの Data Prepper をマネージドで動かす)。フィルター、変換、エンリッチ、ルーティングをパイプラインの設定で書く | ログやトレースを整形して取り込む、 や からの取り込み |
| DynamoDB との 統合 | OpenSearch Ingestion で DynamoDB の変更を継続して取り込む | DynamoDB のデータに全文検索を足したい |
| ストリームのレコードを OpenSearch へ配信し、失敗したレコードを S3 へ退避する | のストリームからの配信 | |
| Logs の | ロググループのログを OpenSearch へ流す ( や Firehose 経由) | アプリや AWS サービスのログを検索・可視化 |
| 直接の (bulk) | アプリから一括で書き込む | 自前のアプリから書く |
S3 のデータを OpenSearch へ取り込まずに問い合わせる直接クエリ (zero-ETL) の機能もあります。頻繁に検索するデータだけを取り込み、残りは S3 に置いておけます。
⑤ログ分析と監視での使い方
は、アプリのログ、 フローログ、 のログなどを数秒で検索し、Dashboards で可視化するのに向きます。
| 用途 | 使い方 |
|---|---|
| パイプラインのエラーの調査 | ・ のログを集め、エラーメッセージを全文検索する |
| 運用ダッシュボード | 件数やエラー率を時系列で可視化し、アラートを設定する |
| 監査 | 監査ログを集めて検索する。ドメイン自身の監査ログ (誰が何を検索したか) は、きめ細かなアクセスコントロールで有効にする |
ログ分析のサービスの使い分け (、、OpenSearch) は「AWS サービスによるログ分析」の章、アクセス制御は D4 の各章で扱います。
試験対策
①判断マトリクス
| 問題文のキーワード | 選ぶもの |
|---|---|
| 全文検索、あいまい検索、ログの検索と可視化 | |
| 容量の計画をしたくない、負荷が変動する | OpenSearch Serverless |
| ログ分析用ののコレクション | 時系列コレクション |
| のストア (サーバーレス) | コレクション |
| 書き込みの終わった古いログを安く検索できるように | |
| めったに見ない過去のログを安く残す | コールドストレージ |
| 階層の移動と削除を自動化 | Index State Management |
| ログを整形・絞り込みしてから取り込みたい | OpenSearch Ingestion |
| のデータを全文検索したい | DynamoDB と OpenSearch の 統合 |
| のレコードを OpenSearch へ配信 | |
| 大量のデータを で集計 | OpenSearch ではなく / |
②よくある誤答
- を、長期間の大量データの唯一の保管先にすること。費用が高く、元データは に残します。
- のインデックスに書き込もうとすること。読み取り専用で、書くにはホットへ戻します。
- 小さなを大量に作ること。メモリと を浪費し、遅くなります。
- OpenSearch Serverless の時系列コレクションで k-NN のインデックスを使おうとすること。のコレクションを使います。