導入
DynamoDBは「速い」で終わらせず、パーティションキーの選び方1つで性能もコストも大きく変わるサービスです。SAPでは、既存のDynamoDB設計の何が悪いかを見抜かせる問題が頻出します。
説明
DynamoDBはデータを複数のパーティションに分散して保存します。パーティションキー（Partition Key）の値によってどのパーティションに保存されるかが決まるため、**特定のキー値にアクセスが集中すると、そのパーティションだけが過負荷になる（ホットパーティション）**という問題が起きます。
flowchart TD
BAD["悪い設計<br/>キー = 日付のみ"] --> P1["今日のパーティションに<br/>全アクセスが集中"]
GOOD["良い設計<br/>キー = ユーザーID + 日付"] --> P2["多数のパーティションに<br/>均等に分散"]
| 概念 | 役割 |
|---|---|
| パーティションキー（PK） | データの分散先を決める。値の種類（カーディナリティ）が高いものを選ぶ |
| ソートキー（SK） | 同じPK内でのデータの並び順・範囲検索を可能にする |
| GSI（グローバルセカンダリインデックス） | PK/SKと異なる列の組み合わせで別の検索経路を追加（別テーブル相当の容量・スループットを持つ） |
| LSI（ローカルセカンダリインデックス） | 同じPKで異なるソート順を追加。テーブル作成時にしか追加できない |
読み書きのキャパシティモードも要件に応じて選びます。
| モード | 特徴 | 向いている状況 |
|---|---|---|
| オンデマンド | トラフィックに応じて自動スケール、使った分だけ課金 | 負荷が予測できない、立ち上げ初期 |
| プロビジョンド | 事前にキャパシティを確保、Auto Scalingと併用可 | 負荷パターンが安定していてコストを最適化したい |
グローバルにユーザーを持つサービスでは、DynamoDB Global Tables で複数リージョンにテーブルを複製し、どのリージョンからでも低レイテンシーで読み書きできるようにします（マルチリージョンでのマルチアクティブ書き込みに対応）。
読んでみよう
「特定のパーティションだけスロットリングが発生している」という記述を見たら、**パーティションキーの設計ミス（カーディナリティ不足）**を疑いましょう。SAPでは「PKを見直してアクセスを分散させる」という改善提案が正解になる典型パターンです。