SAA高性能なアーキテクチャの設計
あるオンライン小売企業は800万件の商品情報を管理しています。
顧客は自然言語キーワードと複数のフィルター（価格帯・ブランド・カテゴリ・評価・在庫状況）を組み合わせて商品を検索します。
以下の要件があります。
・現在はAmazon RDS（PostgreSQL）で検索処理をしているが、ピーク時にタイムアウトが頻発している
・同時アクセス10,000ユーザーのピーク時にも安定して動作する
・P95レイテンシを100ms以内に抑える
最もパフォーマンス要件を満たすアーキテクチャはどれですか？
AAmazon DynamoDBで商品属性にGlobal Secondary Indexを設定し、頻繁にアクセスされるアイテムにDAXキャッシュレイヤーを追加する
DynamoDBは全文検索機能を持たず、複数属性の絞り込みには属性ごとのGSIとアプリ側での結合処理が必要です。P95 100ms以内を10,000同時ユーザー下で保証することが困難です。
BAmazon OpenSearch Serviceに専用マスターノードとデータノードを構成し、複数のインデックスシャードでマルチAZ展開する
✓ 正解
OpenSearch Serviceは転置インデックスによる全文検索と複数条件の同時ファセット検索が得意です。シャード分散で水平スケールでき、専用マスターノード構成で10,000同時ユーザーでもP95 100ms以内を達成できます。
CAmazon ElastiCache for Redisでソート済みセットを使ってランキングを管理し、ハッシュ構造で商品属性を格納・検索する
ElastiCache for Redisはキャッシュ用途には優れますが、自然言語全文検索や複合ファセット検索を直接サポートしていません。800万件を対象にした任意キーワード検索への応用は設計が複雑化し不向きです。
DAmazon Aurora PostgreSQLで複数のリードレプリカを設定し、pg_trgm拡張機能で全文検索インデックスを最適化する
Aurora PostgreSQLのpg_trgmは全文検索を改善しますが、リレーショナルDBのスキャンベースアーキテクチャでは10,000同時ユーザーのピーク時に複合フィルタークエリのスケールに限界があります。
解説
選択肢AのAmazon DynamoDB（DAX含む）は全文検索機能を持たず、複数GSIをまたいだファセット検索はアプリケーション側での結合処理が必要となりP95 100msの達成が困難です。
選択肢BのAmazon OpenSearch Serviceは全文検索とファセット検索に特化した分散検索エンジンです。転置インデックスにより自然言語クエリを高速処理し、価格帯・ブランド・カテゴリ・評価など複数フィルターを単一クエリで同時適用できます。専用マスターノードとデータノードの分離でクラスター管理と検索処理を分離し、シャード分散による水平スケールで10,000同時ユーザー下でもP95 100ms以内を達成できます。
選択肢CのAmazon ElastiCache for Redisはキャッシュに優れますが、自然言語全文検索や複合ファセット検索の実装には複雑なデータモデルが必要で800万件規模の検索インデックスには適していません。
選択肢DのAmazon Aurora PostgreSQLのpg_trgm（PostgreSQLのトリグラムマッチング拡張機能）は全文検索を改善できますが、10,000同時ユーザー下での複合フィルタークエリでは専用検索エンジンの性能には及ばず根本的なスケーラビリティ問題は解決しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →