Amazon DynamoDBの設計入門｜パーティションキー設計とグローバルテーブルによるマルチリージョン冗長化

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ AWS(Amazon Linux) ＞ Amazon DynamoDBの設計入門｜パーティションキー設計とグローバルテーブルによるマルチリージョン冗長化

「DynamoDBを使いたいが、パーティションキーをどう設計すればいいのかわからない」
「RDSとDynamoDBの使い分けが曖昧で、とりあえずDynamoDBを選んだが本当に正解なのか自信がない」

AWSでNoSQLデータベースを使い始める際に、こうした悩みに直面するエンジニアは多い。
DynamoDBはRDSのようなRDB感覚で設計すると、後からパフォーマンス問題やコスト超過が発生しやすい。

この記事では、Amazon DynamoDBの基本的な設計方針から、パーティションキーとソートキーの選び方、グローバルセカンダリインデックス（GSI）の活用、そしてグローバルテーブルを使ったマルチリージョン冗長化の設計パターンまでを実践的に解説する。

この記事のポイント

・DynamoDBは設定不要でマルチAZ冗長化済み。スキーマレスでスケールが自動
・パーティションキーはカーディナリティが高いものを選ぶのが設計の基本
・グローバルテーブルで複数リージョンへの自動レプリケートが実現できる
・最初はオンデマンド課金で動かし、安定後にプロビジョンドへ移行するのが定石

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

DynamoDBとは何か｜RDBとの違いとAWS上での位置づけ

Amazon DynamoDBは、AWSが提供するフルマネージドなNoSQLデータベースです。EC2やOSの管理が不要で、テーブルを作成するだけで即座に使い始められます。

RDBと比較したときの最大の特徴は「スキーマレス」と「自動スケーリング」の2点です。

・RDB: 行と列を持つ固定スキーマ。JOINで複数テーブルを横断した検索が得意
・DynamoDB: キーとアトリビュートで構成。スキーマは柔軟。JOINはできないが低レイテンシで高スループット

DynamoDBはデータを複数のアベイラビリティゾーン（AZ）に自動で複製します。追加設定なしでマルチAZ冗長化が実現できるため、RDSマルチAZ設定のような手動操作は不要です。

用途の向き不向きをまとめると以下のとおりです。

比較項目	DynamoDB向き	RDS向き
アクセスパターン	キーを指定した単純な読み書き	複雑なJOIN・集計クエリ
スケール	突発的な大量リクエスト	トランザクション整合性重視
具体的な用途	セッション管理・IoTデータ・カート	会計・在庫・マスタデータ管理

テーブル設計の基本｜パーティションキーとソートキーの選び方

DynamoDBのテーブル設計で最も重要なのが「パーティションキー」の選択です。

DynamoDBは内部でパーティションキーのハッシュ値をもとにデータを複数のパーティション（物理ノード）に分散します。同じパーティションキーへのアクセスが集中すると「ホットパーティション」が発生し、スループット上限に達してエラーになります。

1. カーディナリティを意識したパーティションキーの選択

パーティションキーの選定ルールは次のとおりです。

・カーディナリティが高いキーを選ぶ: ユーザーIDやセッションIDのように値の種類が多いものが適切
・低カーディナリティのキーを避ける: 性別・都道府県名など値の種類が少ないキーは特定パーティションへの偏りが発生する
・書き込みが均等に分散するか事前に確認する: 「月別」のようなキーは古い月への書き込みが止まり不均等になる

2. ソートキーで範囲検索に対応する

ソートキー（レンジキー）を組み合わせることで、同一パーティション内のアイテムを範囲検索（begins_with・between）やソートができます。

例: パーティションキーを「user_id」、ソートキーを「created_at」にすると、特定ユーザーの活動履歴を日時順に効率よく取得できます。

実際のテーブル作成はコマンドで行います。

# パーティションキー: user_id、ソートキー: created_at のテーブル作成 aws dynamodb create-table --table-name UserActivity --attribute-definitions AttributeName=user_id,AttributeType=S AttributeName=created_at,AttributeType=S --key-schema AttributeName=user_id,KeyType=HASH AttributeName=created_at,KeyType=RANGE --billing-mode PAY_PER_REQUEST --region ap-northeast-1 # テーブル作成状況の確認 aws dynamodb describe-table --table-name UserActivity --query 'Table.TableStatus'

テーブルが正常に作成されると以下のように返ってきます。

# 出力例（作成完了後） "ACTIVE"

グローバルセカンダリインデックス（GSI）でクエリパターンを拡張する

DynamoDBはパーティションキー、またはパーティション＋ソートキーの組み合わせでしか直接検索できません。「商品IDでユーザーアクティビティを検索したい」「作成日時でソートしてリスト表示したい」など別の検索軸が必要な場合に使うのがグローバルセカンダリインデックス（GSI）です。

GSIは元テーブルとは別のパーティションキー・ソートキーを持つインデックスで、最大20個まで作成できます。書き込みのたびにGSIへも非同期でレプリケートされるため、最終的整合性を持つ点に注意が必要です。


# 既存テーブルにGSIを追加（product_id + created_at で検索できるインデックス）
aws dynamodb update-table   --table-name UserActivity   --attribute-definitions     AttributeName=product_id,AttributeType=S     AttributeName=created_at,AttributeType=S   --global-secondary-index-updates '[
    {
      Create: {
        IndexName: product-index,
        KeySchema: [
          {AttributeName: product_id, KeyType: HASH},
          {AttributeName: created_at, KeyType: RANGE}
        ],
        Projection: {ProjectionType: ALL}
      }
    }
  ]'   --region ap-northeast-1

# GSIのステータス確認
aws dynamodb describe-table   --table-name UserActivity   --query 'Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}'

コマンド実行後、インデックスのステータスが「ACTIVE」になれば検索に利用できます。GSIを乱用するとストレージコストと書き込みコストが増加するため、本当に必要な検索パターンに絞って設計することが重要です。

グローバルテーブルでマルチリージョン冗長化する

マルチAZ冗長化はDynamoDBのデフォルト動作ですが、リージョン障害に備えてさらなる冗長性が必要な場合は「グローバルテーブル」を使います。

グローバルテーブルは、複数のAWSリージョンにデータを自動でレプリケートする機能です。東京（ap-northeast-1）と大阪（ap-northeast-3）など複数リージョンで展開でき、書き込みは任意のリージョンで受け付けて他リージョンに非同期でレプリケートされます。

AWSのインフラ設計をLinuxエンジニアとして体系的に学びたい方は、AWSをLinuxエンジニアが学ぶためのロードマップもあわせてご覧ください。

グローバルテーブルの有効化手順は以下のとおりです。

# ステップ1: テーブルのバージョン確認（Version 2019.11.21 推奨） aws dynamodb describe-table --table-name UserActivity --query 'Table.GlobalTableVersion' # ステップ2: 大阪リージョンへのレプリカを追加 aws dynamodb update-table --table-name UserActivity --replica-updates '[ { Create: { RegionName: ap-northeast-3 } } ]' --region ap-northeast-1 # ステップ3: レプリカのステータス確認 aws dynamodb describe-table --table-name UserActivity --query 'Table.Replicas' --region ap-northeast-1 # 出力例 [ { "RegionName": "ap-northeast-3", "ReplicaStatus": "ACTIVE" } ]

グローバルテーブルを使う際の注意点をまとめます。

・書き込み競合: 同一アイテムへの同時書き込みはタイムスタンプが最新のものが優先される（ラストライターウィン）
・レプリケーション遅延: リージョン間の同期は数十～数百msの遅延がある（結果整合性）
・コスト増: 書き込みキャパシティはリージョン数分発生する（東京・大阪の2リージョンなら書き込みコストが実質2倍）

DynamoDB DAXでキャッシュ層を追加する設計

DynamoDB Accelerator（DAX）は、DynamoDB専用のインメモリキャッシュサービスです。読み取りレイテンシをミリ秒単位からマイクロ秒単位に短縮できます。

DAXはVPC内にクラスターとして配置し、アプリケーションはDynamoDBエンドポイントの代わりにDAXエンドポイントへリクエストを送ります。DynamoDB側の設定変更は不要で、アプリ側のエンドポイントを差し替えるだけで導入できます。

マルチAZ構成の場合、DAXクラスターも複数のAZにノードを分散して配置するのが基本です。

# DAXクラスター作成（3ノード・3AZ分散構成の例） aws dax create-cluster --cluster-name UserActivityDax --node-type dax.r6g.large --replication-factor 3 --iam-role-arn arn:aws:iam::123456789012:role/DAXRole --subnet-group dax-subnet-group --security-group-ids sg-xxxxxxxxxxxxxxxxx --region ap-northeast-1 # クラスターのエンドポイント確認 aws dax describe-clusters --cluster-names UserActivityDax --query 'Clusters[].ClusterDiscoveryEndpoint' --region ap-northeast-1 # 出力例（アドレスはマスク表示） { "Address": "userdax.xxxxxx.dax-clusters.ap-northeast-1.amazonaws.com", "Port": 8111, "URL": "daxs://userdax.xxxxxx.dax-clusters.ap-northeast-1.amazonaws.com" }

DAXは読み取りが多く同一データへのアクセスが繰り返されるワークロード（ゲームのランキング・商品カタログ・ECのセッション管理等）で特に効果を発揮します。書き込み頻度が高いワークロードや頻繁にデータが変わる用途では効果が限られるため、導入前にアクセスパターンを確認してください。

コスト設計｜プロビジョンドとオンデマンドの使い分け

DynamoDBの課金モデルは2種類あります。

・オンデマンド: リクエスト単位で課金。キャパシティの事前設定が不要。開発・テスト環境や突発的なトラフィックに適する
・プロビジョンドキャパシティ: 読み書きユニット数を事前に設定。Auto Scalingと組み合わせると柔軟に対応できる。安定したトラフィックの本番環境ではコストを抑えやすい

実際の運用では、まずオンデマンドで動かしてCloudWatchのメトリクスでトラフィックパターンを把握してから、プロビジョンドへの切り替えを検討するのが現場での定石です。グローバルテーブルを有効にしている場合、書き込みコストはリージョン数分かかるためコスト試算を事前に行うことを推奨します。

本記事のまとめ

Amazon DynamoDBの設計で押さえておくべきポイントをまとめます。

設計項目	ポイント
パーティションキー	カーディナリティが高く均等に分散されるキーを選ぶ
ソートキー	同一パーティション内の範囲検索・ソートに使う
GSI	複数の検索パターンが必要な場合に追加する（最大20個）
グローバルテーブル	マルチリージョン冗長化。書き込みは結果整合性に注意
DAX	読み取り多いワークロードのレイテンシ削減に使う
課金モデル	最初はオンデマンドで動かし、安定後にプロビジョンドへ移行を検討

DynamoDBはRDBとは設計の考え方がまったく異なります。「アクセスパターンを先に決めてからテーブルを設計する」というDynamoDBの原則を押さえることで、後からのやり直しを防げます。

AWSでのインフラ設計を体系的に学びたい方は、AWSをLinuxエンジニアが学ぶためのロードマップもあわせてご覧ください。

DynamoDBの設計は、AWSの「NoSQLの型」を知っていれば迷わない

パーティションキーの選び方やGSIの設計方法は調べれば分かります。でも「なぜこのアクセスパターンにこの設計を選ぶのか」を説明できますか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒）＞＞図解60P'Linux入門マニュアル'を受け取る

※ 「独学の時間がもったいない」「プロから直接、AWSを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

前のページへ：Amazon Auroraのクラスター設計とフェイルオーバー｜マルチAZ構成とGlobal Databaseで高可用性を実現する方法
この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る