DVAトラブルシューティングと最適化
DynamoDBテーブルを使う読み取り中心のアプリケーションで、同一アイテムへの高頻度な読み取りが大量に発生している。結果整合性のある読み取りで十分だが、p99で一桁ミリ秒〜マイクロ秒台の応答が求められ、読み取りキャパシティのコストも削減したい。既存のDynamoDB APIを使うコードへの変更を最小限にしてこれを実現する方法はどれか。
ADynamoDB Accelerator (DAX) クラスターを構築し、アプリケーションをDAXクライアントSDK経由でアクセスさせる
✓ 正解
DAXはDynamoDB専用のインメモリ・ライトスルーキャッシュで、マイクロ秒台のレイテンシを提供する。DAXクライアントはDynamoDB APIと互換性があり、エンドポイントを差し替えるだけで済むためコード変更が最小。キャッシュヒット分のRCU消費も削減でき全要件を満たす。
BElastiCache for Redisをlook-asideキャッシュとして導入し、キャッシュミス時にDynamoDBを読む
ElastiCache for Redisのlook-asideは有効だが、キャッシュの読み書き・ミス処理・失効ロジックをアプリ側で実装する必要があり、DynamoDB APIコードへの変更が大きい。レイテンシもマイクロ秒台ではなくミリ秒台にとどまる。
CElastiCache for Memcachedを導入し、アプリ側でキャッシュの読み書きと失効を実装する
ElastiCache for Memcachedも同様にlook-asideパターンでアプリ側のキャッシュ管理コードが必要で、DynamoDBとの整合も自前実装になる。コード変更最小という要件を満たさず、ライトスルー機能も備えない。
DDynamoDBのグローバルテーブルを有効化し、最寄りリージョンのレプリカから読み取る
グローバルテーブルはマルチリージョンのレプリケーション機能でありキャッシュではない。読み取りキャパシティ消費は減らず、マイクロ秒台のレイテンシ要件にも応えられないため目的に合致しない。
解説
DynamoDB Accelerator (DAX) は、DynamoDB専用のフルマネージドなインメモリキャッシュで、結果整合性のある読み取りに対しマイクロ秒台のレイテンシを実現する。
DAXクライアントSDKはDynamoDBのAPIと互換性があり、既存コードのクライアント接続先をDAXエンドポイントに変更するだけで利用できるため、アプリケーション変更が最小限で済む。キャッシュヒットした読み取りはテーブルのRCUを消費せず、コスト削減にもつながる。
選択肢B・CのElastiCache(Redis/Memcached)は汎用キャッシュで、look-asideのキャッシュ管理ロジックをアプリ側に実装する必要があり変更が大きい。
選択肢Dのグローバルテーブルはレプリケーション機能でありキャッシュではなく、レイテンシ・コスト要件を満たさない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →