Amazon DVA-C02: Amazon DynamoDB と NoSQL 設計 — 学習ガイド

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Developer Associate DVA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

データモデリングとアクセスパターン

DynamoDBの設計はアクセスパターンから始まります。すべてのクエリは、プライマリキー、グローバルセカンダリインデックス (GSI)、またはローカルセカンダリインデックス (LSI) のいずれかにマッピングされるべきです。テーブル設計は、リレーショナルスキーマがどのように構成されるかではなく、アプリケーションがどのように項目を読み書きするかによって決まります。ホットパーティションを避けるためにカーディナリティの高いパーティションキーを選択し、範囲クエリが必要な場合は複合プライマリキー（パーティションキー + ソートキー）を使用します。Queryオペレーションでは、パーティションキーに対する等価条件と、ソートキーに対するオプションのKeyConditionExpressionが必要です。SDKでは、DynamoDBドキュメント抽象化の利用が推奨されます。AWS SDK for JavaScript v3ではDynamoDBDocumentClientを使用し（マーシャリング/アンマーシャリングは自動的に処理されます）、JavaではDynamoDB Enhanced Clientを使用してオブジェクトを属性にマッピングします。シングルテーブルパターンは、読み込みパターンがキーを共有し、タイプ属性を介して項目タイプをエンコードできる場合にのみ実装します。スパースGSIを使用して、必要な項目にのみ属性を書き込むことで、セカンダリのアクセスパスを公開します。よくある落とし穴はScanを使いすぎることです。大きなテーブルのスキャンは高コストで、ページ分割されます (LastEvaluatedKey)。RCUの使用量を削減するために、ProjectionExpressionを指定したQueryを優先してください。条件付き書き込みには、ConditionExpressionを指定したUpdateItemを使用するか、複数項目にわたる原子性のためにはTransactWriteItemsを使用します。ConditionalCheckFailedExceptionを処理し、ジッター付きでバックオフしてください。

インデックス、クエリ、トランザクションパターン

ローカルセカンダリインデックスはテーブル作成時にのみ作成され、ベーステーブルと同じパーティションキーを共有し、クエリのためにテーブルの読み込みキャパシティを消費します。一方、GSIはテーブル作成後に追加でき、独立したキャパシティまたはオンデマンド請求を持ち、異なるパーティションキーを許可します。Query呼び出しではKeyConditionExpressionとExpressionAttributeNames/Valuesを使用します。プロジェクション式はデータ転送量を削減します。GSIはデフォルトで結果整合性であり、追加の書き込みコストが発生します。なぜなら、インデックス付き属性を射影するすべてのベーステーブルへの書き込みは、対応するGSIへの書き込みを生成するためです。したがってWCUを計画し、インデックスのConsumedWriteCapacityUnitsを監視してください。強力な整合性のためには、ベーステーブルに対してGetItemまたはConsistentRead=trueを指定したQueryを使用します（GSIは強力な整合性のある読み込みをサポートしません）。トランザクション (TransactWriteItemsおよびTransactGetItems) は、最大25項目または4MBのペイロードにわたる原子性を保証します。失敗を調査するにはReturnValuesOnConditionCheckFailureを使用します。BatchWriteItemとBatchGetItemはそれぞれ25項目と100項目に制限されており、トランザクションではありません。コードはUnprocessedItemsを、指数関数的バックオフで再試行することで処理する必要があります。よくある注意点は、リレーショナルな結合をインデックスに移行する際に、GSIのコストと結果整合性の影響を忘れがちなことです。

キャパシティモード、パフォーマンスチューニング、トラブルシューティング

プロビジョニングモードとオンデマンドモードのどちらを選択するかは、予測可能性に基づいて決定します。プロビジョニングモードとAuto Scaling (DynamoDB用のApplication Auto Scaling) を組み合わせることで、安定したワークロードに対してRCU/WCUとコストを制御できます。一方、オンデマンドモードは、キャパシティプランニングなしでバースト的なトラフィックを簡素化しますが、リクエストあたりの料金は高くなります。ターゲット使用率と複数のスケーリングポリシーを設定してAuto Scalingを有効にします。CloudWatchメトリクスのConsumedReadCapacityUnits、ConsumedWriteCapacityUnits、ThrottledRequests、SuccessfulRequestLatency、SystemErrors、ConditionalCheckFailedRequestsを監視して、ホットスポットやスロットリングを検出します。アダプティブキャパシティを使用して単一キーのスロットリングを緩和できますが、それに依存するのではなく、均一なキー分散を設計してください。読み込み負荷の高いワークロードには、マイクロ秒単位の読み込みを実現するDAX、またはAmazon ElastiCacheによるキャッシュを検討します。書き込み負荷の高い場合は、書き込みシャーディング（プレフィックスやバケット）を使用して、書き込みをパーティション間に分散させます。トラブルシューティングは、ProvisionedThroughputExceededExceptionを調査し、SDKクライアントでジッター付きの指数関数的バックオフを実装することから始めます。CloudWatch Contributor Insightsを有効にしてホットキーを見つけ、セグメント化されたワーカーによる大規模な1回限りの分析には、パラレルスキャンを使用します。項目サイズの制限 (400 KB) と、大きな項目はRCU/WCUを増加させることを忘れないでください。必要に応じて、大きなBLOBはS3に分割し、メタデータをDynamoDBに格納します。

ストリーム、統合、バックアップ、および運用上のベストプラクティス

DynamoDB Streamsは、アイテムレベルの変更（INSERT、MODIFY、REMOVE）をパーティションキーごとに順序を維持してキャプチャし、イベントソースマッピングを介してLambdaと直接統合します（startingPositionをTRIM_HORIZONまたはLATESTとして設定し、batchSizeとmaximumBatchingWindowInSecondsを設定し、bisectBatchOnErrorとmaximumRetryAttemptsを調整します）。堅牢な処理のためには、デッドレターキュー（SQSまたはSNS）を持つLambdaを使用するか、分析のためにストリームレコードをKinesisまたはKinesis Data Firehoseにルーティングします。アイテムの自動失効のためにTime To Live (TTL)を有効にします。TTLによる削除は結果的に処理されるため、即時整合性を期待すべきではないことに注意してください。ディザスタリカバリにはポイントインタイムリカバリ（PITR）とオンデマンドバックアップを使用します。マルチリージョンでの可用性のためには、Global Tablesを使用してリージョン間で変更をレプリケートします。サービスには最小権限のIAMロールを適用し、Lambdaには必要なdynamodb:Query、dynamodb:PutItem、dynamodb:UpdateItem、dynamodb:GetItem、dynamodb:DescribeStream、dynamodb:ListStreamsアクションのみを許可します。一般的な運用上の落とし穴には、コンシューマーでのリトライ/バックオフロジックの欠如、不適切なGSIキャパシティプランニング、ラグ検出のためのStreamsのIteratorAgeの監視の失敗などがあります。CloudWatch LogsとX-Rayで計測し、エンドツーエンドのレイテンシーを追跡します。

実践的な問題：ユースケースシナリオ

シナリオ：AcmeMedia社は、数千万のアイテムを含むメタデータカタログをus-east-1の単一のDynamoDBテーブルで運用しています。新たに導入された画像処理パイプラインでは、photographerIdとuploadTimestampの範囲による低レイテンシのクエリが必要であり、ダウンストリームのLambdaコンシューマーは変更を確実に処理する必要があります。

課題：テーブルの再設計なしにphotographerId + タイムスタンプ範囲のための効率的なクエリパスを追加し、ダウンストリームのLambdaが少なくとも1回のセマンティクスでストリームレコードを処理することを保証し、多作な写真家によるホットパーティションを回避すること。

推奨アプローチ：

パーティションキーをphotographerId、ソートキーをuploadTimestampとして、photographer-gsiという名前のGSIを作成します。UpdateTable APIまたはコンソールを使用してGSIを追加し、UpdateTableを介してProvisionedThroughputまたはOn-Demand課金を指定し、IndexStatusのモニタリングを設定します。
アイテムを書き込む際にphotographerIdとuploadTimestamp属性を含めることで、インデックスのプロジェクションをスパースにします。ストレージと書き込みコストを削減するために、クエリに必要な非キー属性を指定してProjectionType=INCLUDEを選択します。
テーブルでDynamoDB StreamsをENABLEDに設定し、startingPosition=TRIM_HORIZON、調整されたbatchSize（例：100）、bisectBatchOnError=true、maximumRetryAttempts=2でLambdaイベントソースマッピングを作成し、Lambda関数の設定でSQSキューをデッドレター送信先として設定します。
ジッター付きのSDKクライアントリトライを実装し（AWS SDK組み込みのリトライ戦略を使用）、単一のphotographerIdが依然としてスロットリングを引き起こす場合はライトシャーディングを適用します（書き込み時にphotographerIdにN個のバケットのプレフィックスを付け、読み取り時にクライアント側でプレフィックスを削除します）。

論理的根拠：GSIを追加することで、ベースのプライマリキーを変更することなく、必要なアクセスパターンを公開できます。必要な属性のみをプロジェクションすることで、GSIの書き込みコストが削減されます。DLQとリトライ制御を備えたStreams + Lambdaは、信頼性の高い少なくとも1回の処理を提供し、シャーディングはカーディナリティの高いトラフィックによるホットパーティションを防ぎます。

← Amazon API Gateway とアプリケーション統合 · すべてのドメイン · CloudFormation と Infrastructure as Code (SAM →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →