1.4標準
イベントをパーティションへ分散するが、特定キーへの集中を避けたい。
同じ顧客の順序は保ちながら、異なる顧客を複数パーティションへ分散する。
最も適切な考え方はどれか。
× 不正解
エンティティIDをパーティションキーにすると同一エンティティの順序を保ちやすく、ハッシュで異なるエンティティを分散できる。
詳細解説
正しい顧客IDをハッシュ化してパーティションキーにする
同じ顧客は同じキーへ送って順序を保ち、異なる顧客をハッシュで分散しやすい。
同じ顧客は同じキーへ送って順序を保ち、異なる顧客をハッシュで分散しやすい。
誤り全イベントを固定パーティションへ送る
順序は保てるが、容量が1箇所へ集中してスケールしない。
順序は保てるが、容量が1箇所へ集中してスケールしない。
誤りランダムキーだけを使い同一顧客を分ける
分散はするが、同じ顧客の順序保証を失う。
分散はするが、同じ顧客の順序保証を失う。
誤りS3の保存クラスで分散アルゴリズムを選ぶ
ストレージクラスは取り込みパーティションの選択を決めない。
ストレージクラスは取り込みパーティションの選択を決めない。
実際に確かめる
一時的な検証環境で実行できる例です。
Kinesis・Kafkaのpartition key、ハッシュ分散、順序性の公式説明を確認する。期待される結果
順序保証と負荷分散のトレードオフを説明できる。理解のポイント
- ハッシュ
- パーティションキー
- 順序性
- 分散処理
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 1と各サービスの公式ドキュメントを確認する。
基礎のおさらい
キー設計
順序を保つ単位と負荷を分散する単位を同じキー設計で表現する。
ホットキー
顧客ごとのイベント量が偏る場合は、サブキー・ソルト・容量拡張を検討する。
問題IDAWS-DEA-085
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告