DOPモニタリングとロギング
高トラフィックなECサイトがAmazon DynamoDBでカタログと注文データを管理しています。ピーク時にDynamoDBのスロットリングエラーが急増していますが、CloudWatchの標準メトリクス（ConsumedWriteCapacityUnits）はテーブル全体の集計値しか表示せず、どのパーティションキー（商品ID・注文ID）にアクセスが集中しているか（ホットパーティション）を特定できていません。追加の実装コストを最小限に抑えつつ、最も効率的にホットパーティションを特定する方法はどれですか？
ADynamoDB Streamsを有効化し、Lambda関数でパーティションキーごとのアクセス数を集計してCloudWatchカスタムメトリクスに発行するパイプラインを構築する
DynamoDB Streams とLambda でパーティションキー別のアクセス数を集計する構成は実現可能ですが、カスタム開発・テスト・運用が必要で実装コストが大幅に増大し、最小コストという要件に反します。
BDynamoDBテーブルでCloudWatch Contributor Insightsを有効化し、最もアクセスされているパーティションキーとソートキーのランキングをリアルタイムで自動的に可視化する
✓ 正解
CloudWatch Contributor InsightsはテーブルまたはGSI単位で有効化するだけで、アクセス数・スロットリング数の多いパーティションキーとソートキーのリアルタイムランキングを追加コードなしに自動生成します。DynamoDBとネイティブ統合され、ホットパーティション特定に最適です。
CCloudWatch Logs InsightsでDynamoDBのアクセスログをクエリし、最も頻繁にアクセスされるパーティションキーを特定する
DynamoDBはパーティションキー単位のアクセスログをCloudWatch Logsへ標準では出力しないため、Logs Insightsでクエリすること自体ができず、この方法ではホットパーティションを特定できません。
DAWS CloudTrailのデータイベントでDynamoDB APIを記録し、Amazon AthenaでS3上のログをクエリしてパーティションキー別集計を行う
CloudTrailデータイベントの有効化・S3保存・Athenaクエリが必要で、リアルタイム性がなく実装・運用コストも高いため、ホットパーティション特定の手段としては非効率です。
解説
CloudWatch Contributor Insightsはテーブルまたはグローバルセカンダリインデックス（GSI）単位で有効化するだけで、アクセス数・スロットリング数の多いパーティションキーとソートキーのリアルタイムランキングを追加コードなしに自動生成します。DynamoDBとネイティブ統合されており、ホットパーティション特定に最も適した手段です。
選択肢AのDynamoDB Streams + Lambda はカスタム開発・テスト・運用が必要で実装コストが大幅に増大します。
選択肢CのCloudWatch Logs Insights は、DynamoDBがパーティションキーレベルのアクセスログをCloudWatch Logsに出力しないため、そもそもクエリ対象が存在せず実現不可能です。
選択肢DのCloudTrail + Athena はCloudTrailデータイベントの有効化・S3保存・Athenaクエリが必要で、リアルタイム性がなくコストも高くなります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →