SAA高性能なアーキテクチャの設計
あるソーシャルアプリ企業が、ユーザープロフィールを Amazon DynamoDB に格納しています。トラフィックは読み取りが圧倒的に多く(読み取り:書き込み = 約95:5)、人気アカウントへの同一アイテムの読み取りが集中します。要件は、これらの読み取りをマイクロ秒レベルのレイテンシで応答することで、結果整合性で問題ありません。アプリケーションの改修と運用負荷を最小限に抑えたいと考えています。最も適切な構成はどれですか。
AAmazon DynamoDB Accelerator(DAX)クラスタを追加し、読み取りをキャッシュしてマイクロ秒レベルの応答を実現する
✓ 正解
DAX は DynamoDB 専用のフルマネージドインメモリキャッシュで、結果整合性読み取りをマイクロ秒で返します。API 互換のためアプリ改修が最小でキャッシュ管理も透過的に行われ、読み取り集中シナリオの要件に最適です。
BAmazon ElastiCache for Redis を前段に配置し、アプリケーション側でキャッシュの読み書きロジックを実装する
ElastiCache for Redis は汎用キャッシュで、キャッシュへの読み書きや無効化のロジックをアプリ側で自前実装する必要があります。改修と運用負荷が大きく、運用負荷最小化の要件に反します。
CDynamoDB のグローバルテーブルを構成し、複数リージョンへ読み取りを分散してレイテンシを下げる
グローバルテーブルはマルチリージョンでのデータ複製と地理的分散・可用性向上のための機能です。単一リージョン内のホットアイテムをマイクロ秒で応答する目的には合致しません。
D読み取りを強力な整合性に変更し、対象テーブルの読み取りキャパシティユニットを大幅に増やす
強力な整合性への変更はレイテンシを増やす方向に働きます。RCU を増やしても DynamoDB 自体の応答はミリ秒台が限界でマイクロ秒には届かず、コストも大きく増加します。
解説
DAX は DynamoDB 専用のインメモリキャッシュで、結果整合性の読み取りをマイクロ秒レベルのレイテンシで返します。DynamoDB API と互換性があり、アプリは DAX エンドポイントを向けるだけでキャッシュ管理は DAX 側が透過的に行うため、改修・運用負荷が最小です。読み取り集中・ホットアイテムのシナリオに最適です。
選択肢Bの ElastiCache for Redis は汎用キャッシュで、キャッシュの読み書き・無効化ロジックをアプリ側で実装する必要があり、改修と運用負荷が増えます。
選択肢Cのグローバルテーブルはマルチリージョンの可用性・地理的分散のための機能で、単一リージョン内のマイクロ秒応答を実現するものではありません。
選択肢Dの強力な整合性への変更はレイテンシをむしろ増やし、RCU 増強もミリ秒単位が限界でマイクロ秒には到達せず、コストも増大します。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →