あるeコマース企業は、Amazon RDS for PostgreSQL(db.r6g.4xlarge、マルチAZ)上で商品カタログサービスを運用している。読み取りトラフィックの約90%は、人気上位500商品の詳細を取得

Question

あるeコマース企業は、Amazon RDS for PostgreSQL(db.r6g.4xlarge、マルチAZ)上で商品カタログサービスを運用している。読み取りトラフィックの約90%は、人気上位500商品の詳細を取得する同一の参照系クエリで占められ、これらの商品データは1日に数回しか更新されない。ピーク時にプライマリの CPU 使用率が95%に達し読み取りレイテンシが悪化している。すでにリードレプリカを2台追加したが、レプリカの CPU も高止まりしている。
要件は次のとおりである。
(1)反復される同一クエリによる DB 負荷を大幅に削減する。
(2)アプリケーションの変更を最小化する。
(3)データ更新後の陳腐化を一定時間内に抑える。
最も適切な改善策はどれか。

Accepted Answer

正解: ElastiCache for Redis を導入し、遅延読み込み(Lazy Loading)で商品詳細をキャッシュして TTL を設定し、データ更新時に該当キャッシュを無効化する。トラフィックの90%が上位500商品への同一クエリに集中し、更新頻度が低いという特性は、インメモリキャッシュの典型的な適用シナリオである。

ElastiCache for Redis を遅延読み込みで導入すると、初回ミス時のみ DB を参照し以降はキャッシュから返すため、反復される同一クエリの大半が DB に到達せずプライマリとレプリカの CPU 負荷を大幅に削減できる。TTL で陳腐化の上限を制御し、更新時に該当キーを無効化することで一定時間内の鮮度も担保できる。キャッシュ参照層の追加はアプリ改修が限定的で済む。

選択肢Bの RDS Proxy は接続プーリングが目的で、同一クエリ結果をキャッシュしないため、CPU を占める繰り返しクエリの実行負荷は削減できない。
選択肢Cのリードレプリカ追加は総クエリ処理量を減らさず、既にレプリカが飽和しておりコスト増のわりに根本解決にならない。
選択肢Dの DAX は DynamoDB 専用のキャッシュであり、RDS PostgreSQL の前段には使用できない。

Answer

RDS Proxy を導入して接続プーリングを行い、データベース接続確立のオーバーヘッドを削減してプライマリ DB の CPU 負荷を低減する — RDS Proxy は接続プーリングによりコネクション確立のオーバーヘッドを軽減するが、クエリ結果をキャッシュする機能はない。CPU を占有しているのは同一クエリの繰り返し実行そのものであり、その処理負荷は削減されないため要件1を満たさない。

Answer

リードレプリカをさらに3台追加し、アプリケーションの読み取りエンドポイントを Route 53 の加重ルーティングで各レプリカに分散する — リードレプリカを追加しても各レプリカが同一クエリを実行する総処理量は減らず、既存レプリカが既に飽和している状況では効果が乏しい。コストが線形に増大するうえ反復クエリの根本対策にならず、要件1を効率的に満たせない。

Answer

DynamoDB Accelerator(DAX) を商品カタログ DB の前段に配置し、商品詳細の読み取りリクエストをインメモリキャッシュから返す — DAX は Amazon DynamoDB 専用のインメモリキャッシュであり、RDS for PostgreSQL のクエリをキャッシュすることはできない。データソースが DynamoDB ではないため技術的に適用不可能で、本シナリオの構成では機能しない。

解説

解説