Q1 — 単一選択既存の商品カタログでは、同じレコードに対して、商品IDによる高頻度な取得と、商品名・説明文に対する全文検索の両方を1つのデータベースで処理しています。
AWS上では、商品IDによる取得量が今後10倍へ増えても個別シャード管理を増やさず拡張でき、全文検索側も独立してスケール・改善できる構成へ再設計したいと考えています。データの正規の更新先を1つに保つ必要もあります。
最も適切なターゲット構成はどれですか。
A. Amazon DynamoDBを正規データストアとし、Amazon OpenSearch Serviceへ検索用インデックスを作成する
B. Amazon OpenSearch Serviceだけを正規の更新先とし、商品IDによる取得と全文検索の両方を検索インデックスだけで処理する
C. Amazon DynamoDBだけを使用し、商品説明の全文検索はテーブル全体のScanを繰り返して実現する
D. Amazon RDSだけを維持し、商品IDアクセスと全文検索を同じデータアクセス経路のまま処理し続ける
答えと解説
答え：A
商品IDによるキーアクセスと全文検索では、求められるデータアクセス方法が異なります。
DynamoDBを正規データストアとして登録・更新・キー取得を担当させ、キーアクセスの増加へスケールさせます。OpenSearch Serviceには検索用の派生インデックスを持たせ、全文検索側を独立して拡張・改善します。2つのサービスを独立した正規データストアとして扱うのではなく、正規データと検索用データの役割を分けます。
Q2 — 単一選択Amazon DynamoDBを商品の正規データストアとして採用し、OpenSearch Ingestionを使用してAmazon OpenSearch Serviceへ検索用データを連携します。
既存データを最初に取り込んだ後、作成・更新・削除も継続して検索インデックスへ反映したいと考えています。
必要な構成として最も適切なものはどれですか。
A. PITRを有効にして初期データをS3へエクスポートし、継続変更は対応するストリームビュータイプのDynamoDB Streamsから取り込む
B. DynamoDB StreamsをKEYS_ONLYで有効にし、既存データと変更後の完全な項目内容をすべて取得する
C. PITRを無効のまま初期スナップショットを作成し、その後はアプリケーションからOpenSearch Serviceへ直接二重書き込みする
D. OpenSearch Serviceを正規データストアに変更し、検索インデックスからDynamoDBへ定期的に変更を書き戻す
答えと解説
答え：A
初期データをOpenSearch Ingestionで取り込む構成では、DynamoDBのポイントインタイムリカバリを有効にし、S3へのエクスポートを利用します。
その後の変更を取り込む場合はDynamoDB Streamsを有効にし、OpenSearch Ingestionで利用する変更イメージに対応したストリームビュータイプを構成します。NEW_IMAGEまたはNEW_AND_OLD_IMAGESを利用できる構成があるため、特定のストリームビュータイプだけを唯一の必須設定として扱いません。
Q3 — 単一選択DynamoDBからOpenSearch Serviceへ検索用データをほぼリアルタイムに反映する構成を採用しました。
注文更新APIの直後に、同じ注文の最新状態を必ず確認してから後続処理を開始する必要があります。一方、利用者向けの商品検索では短い反映遅延を許容できます。
最も適切な設計はどれですか。
A. 最新状態の確認はDynamoDBの強い整合性のある読み取りで行い、OpenSearch Serviceは反映遅延を許容できる検索経路として使用する
B. 最新状態の確認も商品検索も常にOpenSearch Serviceだけから行い、検索インデックスへの反映完了を前提とする
C. DynamoDBへの書き込み後はOpenSearch Serviceのインデックスを同期的に直接更新し、DynamoDB側の結果確認は行わない
D. 検索の反映遅延をなくすためDynamoDBを廃止し、すべての更新処理をOpenSearch Serviceへ移す
答えと解説
答え：A
DynamoDBからOpenSearch Serviceへの変更反映はほぼリアルタイムですが、検索インデックスへの反映がDynamoDBへの更新と同じ瞬間に完了するとは限りません。
更新直後の最新状態を厳密に確認するキーアクセスでは、正規データストアであるDynamoDBの強い整合性のある読み取りを利用します。一方、短い反映遅延を許容できる全文検索はOpenSearch Serviceへ分離できます。
Q4 — 単一選択商品カタログではAmazon DynamoDBを正規データストアとし、Amazon OpenSearch Serviceを検索用の派生インデックスとして使用しています。変更はDynamoDBからOpenSearch Serviceへ継続的に反映しています。
販売終了した商品をDynamoDBから削除した後、その商品が検索結果にも残らないようにしたいと考えています。
この構成の役割分担として最も適切なものはどれですか。
A. DynamoDBで発生した削除を変更データとして検索インデックスへ反映し、対応するOpenSearch Service上のドキュメントも削除する
B. DynamoDBから削除してもOpenSearch Service上の商品は独立した正規データとして残し、検索結果からはアプリケーション側だけで除外する
C. OpenSearch Service上の商品を先に削除し、その削除結果を正規データとしてDynamoDBへ逆方向に書き戻す
D. DynamoDBとOpenSearch Serviceの削除処理を関連付けず、それぞれを独立した正規データストアとして管理する
答えと解説
答え：A
この構成ではDynamoDBが正規データストアであり、OpenSearch Serviceはそこから派生した検索インデックスです。
正規データで商品が削除された場合は、その変更を検索用派生データにも反映し、検索インデックスから対応するドキュメントを削除します。OpenSearch Service側を独立した正規データとして扱ったり、検索側の状態をDynamoDBへ逆方向に書き戻したりすると、正規状態の所在が曖昧になります。
Q5 — 単一選択DynamoDBの各商品には約80個の属性がありますが、OpenSearch Serviceで検索に使用するのは商品名、説明、カテゴリ、ブランド、公開状態だけです。
検索インデックスの容量と取り込み処理を不要に増やしたくありません。
最も適切な設計はどれですか。
A. OpenSearch Ingestionで検索に必要な属性を選んでインデックス化し、不要な属性は検索インデックスへ送らない
B. 将来使う可能性があるため、DynamoDBの全属性を必ず同じ形でOpenSearch Serviceへ複製する
C. OpenSearch Serviceには主キーだけを保存し、検索対象の本文は検索要求ごとにDynamoDBから取得する
D. 検索対象の属性数を減らす代わりに、DynamoDB側のテーブルから不要な属性をすべて削除する
答えと解説
答え：A
検索インデックスには、検索で実際に必要となるデータを中心に取り込みます。正規データストアに存在する属性をすべてOpenSearch Serviceへ複製する必要はありません。
検索対象の属性を選択することで、検索インデックスの容量や取り込み処理を不要に増やすことを避けられます。