DynamoDBリレーション設計の現在地 - 2025年の最新アプローチ

DynamoDBを初めて触るエンジニアの方から「RDBMSみたいにJOINできないなら、どうやってリレーションを表現するんですか？」という質問をよく受けます。確かに、SQLのような宣言的なクエリ言語に慣れていると、NoSQLの設計思想は最初戸惑うかもしれません。

でも実は、DynamoDBにおけるリレーション設計には明確なパターンがあり、それらを理解することで、RDBMSでは実現困難な高いスケーラビリティとパフォーマンスを両立できるんです。2025年現在のAWS公式ドキュメントによれば、単一テーブル設計と複数テーブル設計のどちらも有効であり、アクセスパターンに基づいて選択することが推奨されています。

本記事では、DynamoDBでリレーションを表現する3つの基本パターンを、最新のベストプラクティスと共に解説していきます。

設計の前提となる最新の制約事項

DynamoDBの設計を始める前に、2025年時点での重要な制約事項を整理しておきましょう。これらの制約を理解しておくことで、後々の設計変更や運用上の問題を回避できます。

インデックスの上限と特性

DynamoDBでは、1つのテーブルに対して「GSI（グローバルセカンダリインデックス）」を最大20個、「LSI（ローカルセカンダリインデックス）」を最大5個まで作成できます。重要なのは、LSIはテーブル作成時にのみ追加可能という制約があることです。一方、GSIは後からオンラインで追加・削除が可能なので、初期設計時に全てを決める必要はありません。

私の経験上、プロジェクト初期に「念のため」と大量のインデックスを作成してしまうケースをよく見かけますが、これはコスト面で非効率です。GSIは独立したストレージとキャパシティを持つため、使用しないGSIは純粋なコスト増要因となります。必要最小限から始めて、アクセスパターンが明確になってから追加する方が賢明です。

整合性モデルの違い

DynamoDBの整合性モデルについて、GSIとテーブル・LSIで大きな違いがあります。GSIからの読み取りは「結果整合性」のみサポートされており、強整合性読み取りはできません。これは、GSIが非同期でレプリケートされる別のストレージだからです。

実務では、「ユーザーが登録した直後に、そのメールアドレスでログインしようとしたら見つからない」といった問題に繋がることがあります。こういったケースでは、登録直後の確認画面では主キーでの読み取りを行うか、適切な待機時間を設けるなどの工夫が必要になります。

データサイズとAPI制限

アイテムの最大サイズは400KBという制限があり、Query/Scanの1回の返却上限は1MBです。また、BatchGetItemは最大100項目または16MB、BatchWriteItemは最大25項目または16MBという制限があります。

大量のデータを扱う場合は、これらの制限を考慮したページネーション処理が必須です。特にN:Mリレーションで大量の関連データを扱う場合、1回のクエリで全てを取得できない可能性があることを設計段階で考慮しておく必要があります。

1:1リレーション - ユニーク属性による代替キーアクセス

1:1リレーションの最も一般的なユースケースは、「メールアドレスからユーザー情報を取得したい」といった、主キー以外の属性での高速アクセスです。RDBMSではユニークインデックスを張れば解決しますが、DynamoDBでは少し工夫が必要です。

GSIを活用した代替キー検索の実装

最もシンプルな実装方法は、GSIを使用してメールアドレスをパーティションキーとすることです。以下のようなテーブル構造を考えてみましょう。

表 ユーザーテーブルの基本構造

このテーブルに対して、MailAddressをパーティションキーとするGSIを作成します。

表 メールアドレスGSIの構造

GSIを使用することで、メールアドレスからユーザー情報を効率的に取得できますが、前述の通り結果整合性のみという制約があります。ユーザー登録直後のログインなど、強整合性が必要な場面では注意が必要です。

一意制約を保証する堅牢な設計

メールアドレスの重複を防ぐ「一意制約」の実装は、DynamoDBでよく議論になるトピックです。AWSの公式ブログでは、トランザクション機能と条件付き書き込みを組み合わせた実装パターンが推奨されています。

具体的には、ユーザー登録時に以下の2つのアイテムをトランザクションで同時に書き込みます。

1. ユーザー本体のアイテム（PK: USER#<userId>）
2. ユニークトークンアイテム（PK: UNIQUE#EMAIL#<mailAddress>）

TransactWriteItems APIを使用して、ユニークトークンアイテムにattribute_not_exists条件を付けることで、既に同じメールアドレスが存在する場合はトランザクション全体が失敗します。これにより、アトミックな一意性保証が実現できます。

私のプロジェクトでは、このパターンを採用することで、ユーザー登録のレースコンディションを完全に防ぐことができました。GSIだけでは条件付き書き込みができないため、このようなトランザクションベースのアプローチが有効です。

1:Nリレーション - 階層構造とコレクションの表現

1:Nリレーションは、DynamoDBで最も頻繁に使用されるパターンの一つです。ユーザーと投稿、注文と明細、チームとメンバーなど、親子関係を持つデータ構造は実に多岐にわたります。

コンポジットキーによる階層表現

DynamoDBの1:Nリレーションは、パーティションキー（PK）とソートキー（SK）の組み合わせで表現するのが基本です。AWS公式ドキュメントのbegins_withを使用したクエリ例にもあるように、ソートキーにプレフィックスを付けることで、効率的な範囲検索が可能になります。

例えば、ユーザーが複数のチームに所属するケースを考えてみましょう。

表 ユーザー・チーム所属関係テーブル

このような設計にすることで、Query操作でPK = "USER#u123"かつSK begins_with "TEAM#"という条件を指定すれば、特定ユーザーが所属する全てのチーム情報を効率的に取得できます。さらに、SKに日付を含めることで、参加日順でのソートも自動的に実現されます。

逆引きを実現するGSI設計

1:Nリレーションでよくある要件が「逆引き」です。先ほどの例で言えば、「特定のチームに所属するユーザー一覧を取得したい」というケースです。これはGSIを使用した逆引きパターンで解決できます。

表 チーム・ユーザー逆引きGSI

GSIの設計時に重要なのは、射影する属性の選択です。全属性を射影する「ALL」は便利ですが、ストレージコストが増大します。頻繁にアクセスする属性のみを「INCLUDE」で指定するか、キーのみの「KEYS_ONLY」を選択して、必要に応じて本体テーブルから追加情報を取得する方が、コスト効率的な場合が多いです。

ホットパーティション対策

1:Nリレーションで注意すべき点として、書き込みの偏りによる「ホットパーティション」問題があります。例えば、人気のある投稿に大量のコメントが集中すると、特定のパーティションキーへの書き込みが集中してしまいます。

AWSの公式ドキュメントでは、書き込みシャーディングという手法が推奨されています。これは、パーティションキーにランダムなサフィックスを付与することで、書き込みを複数のパーティションに分散させる方法です。

実装例として、コメント数が多い投稿に対しては、POST#p001_0からPOST#p001_9のように10個のシャードに分割し、書き込み時にランダムに選択します。読み取り時は10個全てのシャードからデータを取得して結合する必要がありますが、書き込みスループットを10倍にできます。

N:Mリレーション - 多対多関係の効率的な実装

N:Mリレーションは、RDBMSでは中間テーブルを使って表現しますが、DynamoDBでは「隣接リスト（Adjacency List）」パターンが推奨されています。AWSの公式ドキュメントでも、このパターンが多対多関係の基本として紹介されています。

隣接リストパターンの実装

ユーザーと部署の多対多関係を例に、隣接リストパターンを実装してみましょう。一人のユーザーが複数の部署に所属し、一つの部署に複数のユーザーが所属するケースです。

表 隣接リストによる多対多関係の実装

この設計のポイントは、エッジ（関係）を独立したアイテムとして管理することです。ユーザーから部署への関係と、部署からユーザーへの関係を両方向で保持することで、どちらからでも効率的にクエリできます。

反転GSIによる双方向アクセス

隣接リストパターンをより効率的にするために、GSIを使った反転インデックスを作成します。

表 反転GSI の構造

このGSI設計により、以下の両方向のクエリが高速に実行できます。

ユーザーが所属する部署を取得する場合は、メインテーブルでQuery PK = "USER#u001" AND SK begins_with "EDGE#DEPT"を実行します。逆に、部署に所属するユーザーを取得する場合は、GSIでQuery GSI1PK = "DEPT#d001" AND GSI1SK begins_with "USER"を実行します。

実際のプロジェクトでは、この双方向アクセスパターンを使って、組織図の表示やアクセス権限の管理を効率的に実装できました。特に、部署異動が頻繁に発生する大規模組織では、このパターンの柔軟性が大きなメリットとなります。

グラフ構造が複雑になった場合の選択肢

隣接リストパターンは多くのケースで有効ですが、グラフ構造が複雑になると限界があります。例えば、「友達の友達」のような多段階の関係や、最短経路探索が必要な場合です。

AWS公式の見解では、高度に連結したグラフデータを扱う場合は、Amazon Neptuneの使用を検討することが推奨されています。DynamoDBは高速なキー・バリューアクセスに最適化されているため、複雑なグラフクエリには向いていません。

私の経験では、SNSの友達関係のような単純な多対多は隣接リストで十分ですが、推薦システムや経路探索が主要な要件の場合は、最初からNeptuneを選択する方が賢明です。

容量モードとスケーリング戦略

DynamoDBの設計において、容量モードの選択は運用コストとパフォーマンスに直結する重要な決定です。2025年現在、多くのプロジェクトで「オンデマンドモード」が第一選択肢となっています。

オンデマンドモードの実力と制約

オンデマンドモードの公式仕様によると、初期状態で最大4,000書き込み/秒、12,000読み取り/秒の処理能力を持ちます。さらに、直近のピークトラフィックの2倍まで瞬時に対応できる自動スケーリング機能を備えています。

ただし、注意すべき点があります。前回のピークの2倍を超えるトラフィックが30分以内に発生すると、スロットリングが発生する可能性があります。例えば、通常100リクエスト/秒のアプリケーションが、突然のバズで10,000リクエスト/秒になるようなケースです。

このような極端なスパイクが予想される場合は、事前に「ウォームアップ」を行うことが推奨されます。段階的に負荷を上げることで、DynamoDBの内部でパーティション分割が適切に行われ、大規模なトラフィックに対応できるようになります。

プロビジョンドモードとの使い分け

プロビジョンドモードは、安定したトラフィックパターンがある場合にコスト効率的です。公式のスロットリング対策ドキュメントにあるように、テーブル本体とGSIそれぞれに独立したキャパシティを設定する必要があります。

実務では、開発・検証環境はオンデマンドモードで始めて、本番環境への移行時にトラフィックパターンを分析し、プロビジョンドモードへの切り替えを検討するアプローチが効果的です。CloudWatchメトリクスで実際の使用量を監視し、平均使用量の1.5〜2倍程度のキャパシティを設定することで、コストとパフォーマンスのバランスを取ることができます。

実装時の重要な考慮事項

FilterExpressionの落とし穴

DynamoDBのQueryやScanでよく使われるFilterExpressionですが、これは「後段フィルタ」であることを理解しておく必要があります。つまり、キー条件で絞り込んだ後の結果に対してフィルタを適用するため、読み取りキャパシティユニットは全件分消費されます。

スパースインデックスの活用に関する公式ドキュメントでは、フィルタ条件をGSIのキー条件に組み込む設計が推奨されています。例えば、「未処理」のステータスを持つアイテムのみを頻繁に検索する場合、ステータスが「未処理」の場合のみGSIに投影される「スパースGSI」を作成することで、大幅なコスト削減が可能です。

アクセス制御とマルチテナント設計

SaaSアプリケーションでは、テナントごとのデータ分離が重要な要件となります。DynamoDBのFine-grained access controlを使用すると、IAMポリシーでパーティションキー単位のアクセス制御が可能です。

例えば、パーティションキーにTENANT#<tenantId>#USER#<userId>のようなプレフィックスを付けることで、特定のテナントのデータのみにアクセスできるIAMポリシーを作成できます。これにより、アプリケーション層でのアクセス制御に加えて、データベース層でも強固なセキュリティを実現できます。

変更データの連携とイベント駆動アーキテクチャ

DynamoDB Streamsを活用することで、テーブルの変更をリアルタイムで他のシステムに連携できます。変更データは最大24時間保持され、Lambda関数などで処理できます。

実際のプロジェクトでは、DynamoDB Streamsを使って以下のような処理を実装しています。

検索用のElasticsearchへのデータ同期では、アイテムの追加・更新・削除を検知してElasticsearchのインデックスを更新します。集計データの非正規化では、注文データの変更を検知して、日次・月次の売上集計テーブルを自動更新します。監査ログの記録では、重要データの変更履歴を別のテーブルに自動保存します。

さらに、2024年に一般提供が開始されたDynamoDBからRedshiftへのZero-ETL統合により、分析要件をRedshiftにオフロードすることも容易になりました。

設計を成功に導くツールとベストプラクティス

Cloudshepherdによる設計検証

Cloudshepherdは、Ragateが提供するAmazonDynamoDB専用設計ツールツールです。

このツールを使うことで、アクセスパターンの可視化、クエリの検証、サンプルコードの生成が可能になります。

特に有用なのは、アクセスパターンとデータモデルの関係を視覚的に確認できる機能です。設計レビューの際にこのツールを使用することで、ステークホルダーとの認識合わせがスムーズになり、設計の妥当性を客観的に評価できます。

私のチームでは、設計フェーズで必ずCloudshepherdでモデリングを行い、主要なアクセスパターンが効率的に実行できることを確認してから実装に入るようにしています。これにより、後から大きな設計変更が必要になるリスクを大幅に減らすことができました。

段階的な最適化アプローチ

DynamoDBの設計は、最初から完璧を目指す必要はありません。むしろ、段階的に最適化していくアプローチが現実的です。

初期フェーズでは、シンプルな設計から始めます。必要最小限のGSIのみを作成し、オンデマンドモードで運用を開始します。成長フェーズでは、CloudWatchメトリクスを分析してボトルネックを特定し、必要に応じてGSIを追加したり、ホットパーティション対策を実施します。成熟フェーズでは、コスト最適化のためにプロビジョンドモードへの移行を検討し、使用頻度の低いGSIを削除します。

このような段階的アプローチにより、過剰な初期投資を避けながら、ビジネスの成長に合わせて最適な設計に進化させることができます。

コスト最適化の実践的テクニック

DynamoDBのコスト最適化において、「スパースGSI」の活用は特に効果的です。例えば、ECサイトの注文テーブルで「未発送」の注文のみを頻繁に検索する場合、発送済みフラグがfalseの場合のみGSIに含まれるように設計することで、GSIのサイズとコストを大幅に削減できます。

また、TTL（Time To Live）機能を活用した自動削除も重要です。ログデータや一時的なセッションデータなど、一定期間後に不要になるデータは、TTLを設定することで自動的に削除され、ストレージコストを抑えることができます。削除操作自体は無料で実行されるため、バッチ処理で削除するよりもコスト効率的です。

まとめ - DynamoDBリレーション設計の本質

DynamoDBのリレーション設計は、RDBMSとは異なるアプローチが必要ですが、適切なパターンを理解すれば、高いスケーラビリティとパフォーマンスを実現できます。

重要なのは、「アクセスパターンファースト」の考え方です。どのようなクエリが必要かを事前に明確にし、それに最適なデータモデルを設計することが成功の鍵となります。単一テーブル設計が絶対ではなく、要件に応じて柔軟に複数テーブルを使い分けることも、2025年現在のベストプラクティスです。

また、GSIの結果整合性、一意制約の実装方法、ホットパーティション対策など、DynamoDB特有の制約や課題に対する理解も不可欠です。これらの知識を持って設計に臨むことで、後々の運用で問題が発生するリスクを最小限に抑えることができます。

最後に、設計は一度で完璧にする必要はありません。Cloudshepherdなどのツールを活用して設計を可視化・検証し、CloudWatchメトリクスで実際の使用状況を監視しながら、段階的に最適化していくことが、実践的で持続可能なアプローチです。

DynamoDBは確かに学習曲線が急ですが、その特性を理解して適切に活用すれば、従来のRDBMSでは実現困難な規模とパフォーマンスを持つシステムを構築できます。本記事で紹介したパターンとベストプラクティスが、皆さんのDynamoDB設計の一助となれば幸いです。