AWS認定資格 WEB問題集&徹底解説
ソリューションアーキテクト-プロフェッショナル
AWSサービスの一つであるAmazon DynamoDBはどんな内容なのでしょうか?また、AWS認定資格のソリューションアーキテクト-プロフェッショナル(SAP)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか?
ここでは、そんなあなたの疑問に回答していきたいと思います
1. サービス概要
Amazon DynamoDB は、フルマネージドのサーバーレスNoSQLデータベースサービスです。 キーバリューおよびドキュメントデータモデルをサポートし、1桁ミリ秒台の低レイテンシーを任意のスケールで実現します。 容量管理・パッチ・バックアップ・フェイルオーバーをAWSが担当し、ストレージは自動的に拡張されます。
データは複数AZに自動的に3コピーされて高可用性を確保します。 主なユースケースは、Webアプリのセッション管理、モバイルバックエンド、ゲームランキング、IoTデータ収集、eコマースカートなど、スキーマレスで超高スループットが求められるワークロードです。
2. 主な特徴と機能
2.1 テーブル構造とプライマリキー
DynamoDBのテーブルはスキーマレス(プライマリキー以外の属性は自由)です。プライマリキーは2種類あります:
- パーティションキーのみ(単純プライマリキー): 1属性で一意に特定。
- パーティションキー+ソートキー(複合プライマリキー): パーティションキーが同じアイテムをソートキーで並べて格納。範囲クエリが可能。
パーティションキーの値でデータが分散されるため、高カーディナリティ(値が均等分散)なキーを選ぶことがパフォーマンスの鍵です。
2.2 読み書きキャパシティ
- プロビジョニングモード: 事前にRCU(読み込みキャパシティユニット)とWCU(書き込みキャパシティユニット)を指定。Auto Scalingと組み合わせて自動調整可能。1RCU=最大4KBの強整合性読み取り1回(結果整合性は2回分)、1WCU=最大1KBの書き込み1回。
- オンデマンドモード: 容量指定不要でリクエスト数に応じた従量課金。スパイクが読めない場合に適するが単価はプロビジョニングより高め。
2.3 セカンダリインデックス
- LSI(ローカルセカンダリインデックス): 同じパーティションキーで異なるソートキーでクエリ。テーブル作成時のみ定義可能。強整合性読み取りに対応。
- GSI(グローバルセカンダリインデックス): 任意の属性をパーティションキー/ソートキーに指定。テーブル作成後でも追加可能。最終整合性のみ(独自のRCU/WCU設定)。
2.4 整合性モデル
- 結果整合性(デフォルト): 低コスト・高スループット。直後の読み取りが古いデータを返す可能性あり。
- 強整合性: 最新データを保証。RCUを2倍消費。
2.5 DynamoDB Streams
テーブルへのデータ変更(挿入・更新・削除)を変更ストリームとして最大24時間保持します。 Lambdaと組み合わせてイベント駆動処理(集計・通知・別テーブルへの同期)に使います。
2.6 グローバルテーブル
複数リージョンにマルチマスターでレプリカを作成し、最寄りリージョンで読み書きを実現します。 障害時は別リージョンへ自動フェイルオーバー(RPO≈0、RTO数秒〜数十秒)。DynamoDB Streamsが内部で使用されます。
2.7 DAX(DynamoDB Accelerator)
DynamoDB互換のインメモリキャッシュクラスター。マイクロ秒台のレイテンシーを実現します。 読み取り集中型のワークロード向けで、API互換のため既存コードの変更が最小限。VPC内に配置。
2.8 TTL・バックアップ・トランザクション
- TTL(Time to Live): アイテムに有効期限を設定し、期限切れアイテムを自動削除(追加料金なし)。
- PITR(Point-in-Time Recovery): 有効化後35日間の任意時点への復元。誤操作に対する保護。
- バックアップ: オンデマンドバックアップ(AWS Backup統合)で長期保持。
- トランザクション: TransactGetItems / TransactWriteItemsで最大100アイテムにまたがるACIDトランザクション(RCU/WCU×2消費)。
3. アーキテクチャおよび技術要素
- パーティションキーのハッシュ値でデータをパーティションに分散格納。各パーティションは3AZに同期レプリカ。
- アプリはSDK/APIでGetItem・PutItem・Query・Scan等のAPIを呼び出す。
- Queryはパーティションキーを指定して高速取得、Scanはフルテーブルスキャン(コスト高・遅い)。
- GSI/LSIで異なるアクセスパターンに対応。DynamoDB Streamsで変更を下流サービスへ通知。
- DAXをVPC内にクラスターとして配置し、読み取りキャッシュとしてインメモリレイテンシーを実現。
フルサーバーレスのため容量の事前計画が不要(オンデマンドモード)またはAuto Scalingで自動調整(プロビジョニングモード)。 ホットパーティション問題(特定のキーに書き込みが集中する状態)を避けるには、高カーディナリティなキー設計とWrite Sharding(キーにランダムサフィックス追加)が重要です。
4. セキュリティと認証・認可
- IAMポリシー: テーブル・インデックス単位で操作(GetItem/PutItem等)を細粒度に制御。条件キー(
dynamodb:LeadingKeys)でユーザーが自分のデータのみアクセスを強制できる。 - 保存時暗号化: デフォルトでAWS管理キー(DynamoDB所有キー)で暗号化。KMS CMKに切り替えて監査・キーポリシー制御も可能。
- 転送時暗号化: HTTPS(TLS)で保護。
- VPCエンドポイント(Gatewayタイプ): インターネットを経由せずVPC内からアクセス。無料(S3と同様)。
- CloudTrail: DynamoDBへのAPI操作(コントロールプレーン)を記録。データプレーンの操作も有効化可能。
5. 料金形態
- プロビジョニングモード: RCU/WCUを事前指定して時間単位で課金。Auto Scalingと組み合わせると効率的。無料枠: 25 RCU + 25 WCU + 25GB/月。
- オンデマンドモード: 実際のリクエスト数(読み取りリクエストユニット/書き込みリクエストユニット)で課金。プロビジョニングより単価は高め。
- ストレージ: GB/月単位。最初の25GBは無料枠内。
- DAX: クラスターノードの稼働時間に応じて課金(EC2に近い体系)。
- グローバルテーブル: レプリカリージョンへの書き込みに追加料金(rWCU)。
- PITR: 有効化したテーブルのストレージに応じて課金(追加GB/月)。
6. よくあるアーキテクチャ・設計パターン
- セッション管理: TTLでセッション自動削除。パーティションキー=セッションIDで超高速アクセス。
- サーバーレスAPI: API Gateway + Lambda + DynamoDBでスケールするRESTful APIを構築。DynamoDBがボトルネックになりにくい。
- イベント駆動処理: DynamoDB Streams → Lambda で変更を検知し、ElasticSearch/OpenSearch同期・通知・集計を実行。
- グローバルアプリ: グローバルテーブルで複数リージョンにマルチマスター展開。各地域ユーザーが最寄りリージョンで低レイテンシー読み書き。
- 高速キャッシュ: DAXをDynamoDBの前段に置き、同一クエリを繰り返すゲームランキング・商品カタログなどをマイクロ秒台で応答。
- タイムシリーズデータ: パーティションキー=デバイスID、ソートキー=タイムスタンプでデータを格納し、時系列範囲クエリ。TTLで古いデータを自動削除。
7. 設定・デプロイ手順(ハンズオン例)
- DynamoDBコンソールで「テーブルの作成」。パーティションキー(必須)とソートキー(任意)を定義。
- キャパシティモードを選択(オンデマンド推奨、または プロビジョニング+Auto Scaling)。
- 必要に応じてGSIを追加(テーブル作成後でも可)。LSIはこの時点でのみ追加可能。
- PITR・TTL・暗号化(KMS CMK)・CloudWatch Contributorインサイトを有効化。
- AWS SDK/CLIでPutItem・GetItem・Query・Scanを試す。
- DynamoDB Streamsを有効化し、Lambda関数をトリガーとして設定(変更通知/集計テスト)。
8. 試験で問われやすいポイント
8.1 プライマリキーとインデックス(最頻出)
- Q: 同じパーティションキーでソートキーを変えてクエリしたい場合のインデックスは?
A: LSI(ローカルセカンダリインデックス)。ただしテーブル作成時のみ定義可能。 - Q: 別の属性をキーとして後からクエリしたい場合は?
A: GSI(グローバルセカンダリインデックス)。テーブル作成後でも追加可能。最終整合性のみ。 - Q: LSIとGSIで強整合性読み取りが使えるのはどちら?
A: LSIのみ(ベーステーブルと同じパーティションを共有するため)。GSIは最終整合性のみ。
8.2 RCU・WCUの計算
- Q: 1 RCUで読めるデータ量は?
A: 強整合性で4KB以下×1回、結果整合性で4KB以下×2回。 - Q: 1 WCUで書けるデータ量は?
A: 1KB以下×1回。 - Q: トランザクション(TransactWrite)のコストは?
A: 通常の2倍のWCU/RCUを消費。
8.3 整合性モデル
- Q: デフォルトの読み取り整合性は?
A: 結果整合性(Eventual Consistency)。強整合性を求めるには読み取り時に明示的に指定(RCU×2消費)。
8.4 DynamoDB Streams
- Q: DynamoDB Streamsの用途は?
A: テーブルへの変更(INSERT/MODIFY/REMOVE)を最大24時間順序保証で保持。Lambdaで後続処理(通知・集計・他テーブル同期)。グローバルテーブルの内部でも使用。
8.5 オンデマンドvsプロビジョニング
- Q: 予測困難なトラフィックスパイクに対応するには?
A: オンデマンドモード(容量指定不要、リクエスト数従量課金)。 - Q: 安定したワークロードでコストを抑えるには?
A: プロビジョニングモード+Auto Scalingで単価を抑えつつ自動調整。 - Q: ProvisionedThroughputExceededExceptionが発生したら?
A: RCU/WCUが上限超過。Auto Scalingの有効化、オンデマンド切替、またはアクセスパターンの見直し(ホットパーティション対策)。
8.6 DAXとキャッシュ
- Q: DynamoDBの読み取りレイテンシーをマイクロ秒台に下げるには?
A: DAX(DynamoDB Accelerator)をVPC内に配置。API互換のため既存コードの変更最小限。 - Q: DAXとElastiCacheの違いは?
A: DAXはDynamoDB専用のインメモリキャッシュ。ElastiCacheはRDS等も含む汎用キャッシュ(Redis/Memcached)。
8.7 TTL・PITR・バックアップ
- Q: 古いセッションデータを自動削除するには?
A: TTL(Time to Live)を設定。期限切れアイテムは数日以内に非同期削除(追加料金なし)。 - Q: 誤ってテーブルのデータを大量削除してしまった場合は?
A: PITR(Point-in-Time Recovery)を有効にしておけば35日以内の任意時点に復元可能。
8.8 グローバルテーブルとホットパーティション
- Q: 複数リージョンでDynamoDBをマルチマスター構成にするには?
A: グローバルテーブルを有効化。内部でDynamoDB Streamsを使い各リージョンにレプリケーション。 - Q: ホットパーティション問題を解消するには?
A: パーティションキーを高カーディナリティに設計する。書き込み集中時はキーにランダムサフィックス(Write Sharding)を付与。
8.9 類似・関連サービスとの比較
- Q: RDSとDynamoDBの使い分けは?
A: 複雑なJOIN・トランザクション・既存SQLはRDS。超高スループット・スキーマレス・スケールアウトはDynamoDB。 - Q: DynamoDBのVPCエンドポイントは何タイプで料金は?
A: Gatewayタイプで無料(S3と同様)。