グローバルメディアストリーミング企業が、コンテンツメタデータをAmazon DynamoDBで管理しています。 【現在の構成】 ・テーブル：content_metadata（データ量5TB、us-east-1） ・プロビジョニングキャパシティ：80,000 RCU / 2,000 WCU ・月次DynamoDBコスト：$92,000（85%が読み込みキャパシティのコスト） ・アプリケーション層：Amazon ECS Fargateタスク（プライベートサブネット、VPC: 10.0.0.0/16内） ・読み込みパターン：結果整合性読み込み（Eventually Consistent Read）を使用。5,000万アイテム中、上位2,000件の「トレンドコンテンツ」へのリクエストが全体の75%を占めるホットパーティション状態 ・平均読み込みレイテンシ：8ms（SLA要件：トレンドコンテンツは1ms未満） 【課題】 ・ピーク時間帯（20:00〜24:00）にホットパーティション起因の読み込みスロットリングが発生し、リクエストの3〜5%が失敗している ・RCUをさらに増加させてもスロットリングは解消されなかった 【要件】 ・トレンドコンテンツの読み込みレイテンシを1ms未満にする ・読み込みスロットリングを解消する ・読み込みコストを60%以上削減する ・コード変更を最小限に抑える（エンドポイントURLの変更は許容するが、SDKの全面書き直しは不可） すべての要件を満たす最適なソリューションはどれですか？
正解： Amazon DynamoDB Accelerator（DAX）クラスター（3ノード: dax.r6g.2xlarge、マルチAZ）をECS Fargateと同じVPC（10.0.0.0/16）内にデプロイする。アプリケーション設定をDAXクラスターエンドポイントに変更するのみで対応する（エンドポイントURL変更のみ）。DAXは結果整合性読み込みのアイテムキャッシュヒットをマイクロ秒レイテンシで処理する。95%のキャッシュヒット率を見込み、プロビジョニングDynamoDB RCUを80,000から8,000に削減する。DAXアイテムキャッシュのTTL（生存時間）を60秒に設定し、データ鮮度とキャッシュヒット率のバランスを確保する。 DAX（DynamoDB Accelerator）はDynamoDB APIと完全互換のインメモリキャッシュサービスです。アプリケーションはエンドポイントURLをDAXクラスターに変更するだけで利用でき、SDKの書き直しが不要です。結果整合性読み込みのキャッシュヒット時はマイクロ秒レイテンシ（1ms未満）を実現し、SLAを達成します。75%がトレンド2,000件に集中するパターンで95%キャッシュヒット率が見込めるため、実際にDynamoDBに届くリクエストは約5%に激減し8,000 RCUで対応可能（コスト約60%削減）です。ホットパーティション問題はDAXインメモリキャッシュがトレンドコンテンツを直接返すことで根本解消されます。 強整合性読み込み設定案が誤りの理由：DAXは強整合性読み込み（Strongly Consistent Read）をキャッシュしません。強整合性読み込みは常にDAXをバイパスしてDynamoDBに直接到達します。RCUを5,000に削減した場合、バイパスされるすべての読み込みで深刻なスロットリングが発生し、コスト削減と障害解消の両方に失敗します。 ElastiCache Redis案が誤りの理由：ElastiCacheはDynamoDB APIと互換性がなく、キャッシュアサイドパターン（キャッシュ確認→DynamoDB取得→キャッシュ更新のロジック）をアプリケーションに実装する必要があり、「SDKの全面書き直し不可」という要件に違反します。 Auto Scaling + GSI案が誤りの理由：Auto ScalingはキャパシティAdjustmentに数分を要し、突発的なピークトラフィックへの即時対応ができません。GSIは書き込み分散には有効ですが、特定のトレンドコンテンツIDへの集中読み込みというホットキー問題の本質は解決できません。どちらも1ms未満のレイテンシ要件を達成できません。