SQL から NoSQL へ : Amazon DynamoDB へのアプリケーション移行の計画

本記事は 2025/07/03に投稿された SQL to NoSQL: Planning your application migration to Amazon DynamoDB を翻訳した記事です。
翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。

リレーショナルデータベースから Amazon DynamoDB に移行する組織は、データモデルとアクセスパターンを再設計する際に課題に直面することがよくあります。アプリケーションの機能を維持しながら最適なパフォーマンスを実現するためには、クエリ機能、データモデリングアプローチ、アプリケーションアーキテクチャの根本的な違いを理解することが不可欠です。
実際の例でこれらの課題を説明します。急成長している SNS プラットフォームでは、リレーショナルデータベースが複数のテーブル間の結合が必要な複雑なクエリに苦戦しており、特に人気の投稿や有名人とのやりとりなどのコンテンツで顕著です。ユーザー数が今後大幅に増加すると予測されており、既存のアーキテクチャのスケーラビリティに懸念が生じています。数千人の同時ユーザーがいるバイラルイベントでは、人気コンテンツの複雑な結合クエリに負荷がかかり、現在のアーキテクチャではプラットフォームの成長に伴うスケーラビリティニーズを満たせない可能性があることを示唆しています。

この記事は SQL から DynamoDB に移行する際の効果的な移行方法を解説するシリーズの第1回目です。DynamoDB データモデル設計に役立つデータベーススキーマの分析、クエリパターン、使用状況のメトリクスに焦点を当てて、既存のデータベース構造とアクセスパターンを分析して移行の準備方法を検討します。今後の記事では、データモデリング戦略とデータアクセスレイヤーの最新化について説明します。

リレーショナルデータベースと NoSQL データベースの比較

アプリケーションを従来のリレーショナルデータベースから DynamoDB に移行する際、リレーショナルデータベース同士の移行とは大きく異なる点がいくつかあります。これらの違い (次の表を参照) を理解することが、モダナイゼーションの成功には不可欠です。

項目	リレーショナルデータベース	Amazon DynamoDB
クエリ言語	構造化されたクエリパターンを使用する SQL を使用	最適化されたパーティションキーとソートキーへのアクセスにより、一貫した一桁ミリ秒のレイテンシーを提供する API ベースの操作を提供
データモデル	確立された正規化されたデータ構造を使用	パフォーマンスとスケーラビリティを最適化した柔軟な非正規化データモデリングを提供
データアクセスフレームワーク	Entity Framework や Hibernate などの成熟した ORM フレームワークを使用	馴染みのあるオブジェクト指向パターンを維持しながら、複数のプログラミング言語に対して包括的かつ高パフォーマンスを実現する専用ライブラリを備えたネイティブ SDK を提供

リレーショナルデータベースから別のリレーショナルデータベースへの移行は、基本的な構造やアクセスパターンが類似するため、データアクセス層への影響は比較的小さいです。DynamoDB への移行では、その強力な NoSQL 機能を活用する異なるアプローチが導入されます。データモデル、クエリ言語、アクセスパターンの変更により、アプリケーションは DynamoDB の高いパフォーマンスとスケーラビリティを活用できるようになります。チームは DynamoDB の設計原則に合わせてデータアクセス層を適応させ、一貫したパフォーマンスと効率性を最適化できます。

さらに、従来のリレーショナルデータベースの移行では、データベースチームが主にデータベース設定を担当しますが、アプリケーションチームの関与は限られていることがよくあります。しかし、DynamoDB に移行する場合、アプリケーションチームとデータベースチームの協力が重要になります。アプリケーションチームは、データベース専門家と密接に協力して、アプリケーションのデータアクセス要件に合わせた最適な DynamoDB データモデルを設計する必要があります。この協力体制が、DynamoDB NoSQL データベースへの移行を成功させる鍵となります。

データモデリングのための分析

リレーショナルデータベースから DynamoDB への移行では、パフォーマンスとコスト効率を最適化するために、慎重な計画が必要です。まず、要件を定義するために、既存のリレーショナルデータベースの複雑さを評価します。この評価に基づいて、ワークロードに合わせて効果的にスケーリングできる適切な DynamoDB データモデルを設計します。入念な初期評価により、DynamoDB への移行がスムーズになります。移行プロセスでは、現在のデータ構造を分析し、アクセスパターンを特定し、DynamoDB のキーと値のデータモデルに最適化します。

ソーシャルメディアプラットフォームのユースケース

この記事を通して概念を説明するために、ユーザーが投稿を作成し、投稿に対してコメントや「いいね」をつけられるソーシャルメディアプラットフォームを使用します。次の図に示すように、主要なエンティティには、投稿を作成するユーザー、投稿に関連するコメント、「いいね」をつけたユーザの機能が含まれます。このプラットフォームは、ユーザーカウンターと投稿カウンターのエンティティを通じてメトリクスを追跡し、ユーザーあたりの投稿総数や投稿毎のエンゲージメント指標などの統計を維持しています。この図は、現在のリレーショナルモデルにおける主要な関係を示しています。

ユーザーと投稿 (1 対多の関係)
投稿からコメント (1 対多の関係)
ユーザーとそれぞれのカウンターへの投稿 (1 対 1 の関係)
ユーザーと「いいね」 (多対多の関係)による投稿では、ユーザーは複数のポストに「いいね」をしたり、複数のユーザーから投稿に対して「いいね」を受けられる

ユーザー投稿の関係を示すソーシャルプラットフォームのデータベーススキーマ。カウンター追跡機能と、いいね/コメントなどのエンゲージメント機能が含まれています

スキーマ分析

既存のデータベース構造を徹底的に調査することから始めてください。この分析により、どのテーブルを移行するかを判断し、DynamoDB でのデータモデリングの複雑さを理解するのに役立ちます。

データベース構造の分析

まず、現在のデータベースアーキテクチャを調査してください。

テーブル (トランザクション、分析、監査ログなど) とそれらの関係を特定する
データ型 (文字列、数値、日時、GUID、空間データなど) を分析し、DynamoDB の同等のデータ型を特定する
DynamoDB の 1 アイテムあたり 400 KB のサイズ制限を考慮しながら、テーブルサイズと増加パターンをドキュメント化する

アプリケーションがさまざまなデータ型をどのように使用しているかを理解することは、DynamoDB でのおけるそれらの表現方法を導くことになります。日時フィールドは、クエリとソートの要件に基づいて、ISO 文字列またはエポック数にマッピングする必要があります。複数のフィールドを単一のアイテムに非正規化できる場合は、TEXT フィールドのサイズを評価する必要があります。この分析により、データの整合性を維持しながら効率的なクエリをサポートするデータモデルの設計に役立ちます。

マイクロサービスに関する考慮事項

マイクロサービスアーキテクチャでモダナイズする場合は、各サービスのテーブル依存関係を特定してください。

サービスごとに必要なテーブルを一覧にする
サービス間のデータ依存関係をドキュメント化する
非正規化の戦略を立てる
データ整合性の要件を評価する

サービス間でデータを共有およびアクセスする必要性を検討してください。たとえば、投稿サービスではユーザー名とプロフィール画像の表示が必要になる一方で、通知サービスではアラート配信のためにユーザー設定が必要になる場合があります。このようなサービス間のデータ依存関係は、DynamoDB のモデリング決定に影響します。アクセスパターンと更新頻度に基づいて、厳格なサービス分離とデータ非正規化のトレードオフを評価してください。サービス間の呼び出しによるパフォーマンスへの影響を考慮し、アプリケーションパターンの変化に伴ってサービス境界の調整が必要になる状況に備えてください。

部分的な移行分析

一部のテーブルのみを DynamoDB に移行する場合は、移行したテーブルと移行していないテーブルの関係を理解する必要があります。

移行範囲と依存関係を特定する
パフォーマンスへの影響を評価する
アプリケーションの変更を計画する
データ整合性戦略を設計する
将来の移行フェーズを定義する

投稿やコメントなどの頻繁にアクセスされるデータは DynamoDB に移行し、履歴分析データはリレーショナルデータベースに残すシナリオを考えてみましょう。以前はテーブル間のトランザクション整合性に依存していた操作を処理するデザインパターンを計画します。クロスデータベースクエリによる潜在的なレイテンシーへの影響を検討し、適切なデータ同期メカニズムを実装する必要があります。この理解は、移行中と移行後のデータ整合性とアプリケーションのパフォーマンスを維持するための効果的な戦略を立てるのに役立ちます。

スキーマオブジェクトの評価

DynamoDB の設計で SQL スキーマオブジェクトの機能をどのように実装するかを評価してください:

SQL ビューとそのアプリケーション使用方法をドキュメント化する
共通テーブル式 (CTE) を含む、ストアドプロシージャの複雑さを分析する
トリガーベースのビジネスロジックの移行を計画する
移行対象外のテーブルへの参照を評価する
複雑な分析クエリの代替案を検討する
大規模なデータ変更を計画する

テーブル全体でエンゲージメント指標を集計する SQL ビュー、時間ウィンドウ付きデータを使用してトレンドコンテンツを計算するストアドプロシージャ、投稿数などの派生データを管理するトリガーは、DynamoDB 向けに再設計する必要があります。SQL 操作に依存せずに効率的なアクセスパターンをサポートするようにデータモデルを設計してください。大規模なデータ変更にはバッチ処理アプローチを検討し、従来はデータベースプロシージャやトリガーで処理されていた操作をアプリケーションロジックでどのように処理するかを計画してください。入念なスキーマ分析と慎重な計画を行うことで、チームは実装要件を予測し、クエリパターンを最適化し、効果的なデータ整合性戦略を策定できます。この理解は、モダナイゼーションの取り組みに不可欠であり、チームがアプリケーションで DynamoDB の機能を最大限に活用できるようにするための鍵となります。

クエリ分析

アプリケーションで使用される SQL クエリ (インラインの SQL、ORM 生成のクエリ、その他の動的クエリを含む) を分析します。この分析により、DynamoDB データモデルの適切なパーティションキー、ソートキー、リレーションシップを選択するための情報が得られます。SQL クエリの各コンポーネントを次のように調査します。

SELECT 句の分析

SELECT 句を調べることで、アプリケーションがデータをどのように消費する方法と、さまざまなエンティティ間の関係について洞察を得ることができます。SELECT 句を分析する際には、次の重要な側面を考慮してください:

サブクエリ – 既存のアクセスパターンの中で、通常は集約、複雑な条件に基づくフィルタリング、関連エンティティの詳細の取得、または最新のレコードの取得を行うサブクエリを探します。たとえば、ユーザープロファイルのクエリではサブクエリを使って総投稿数やフォロワー数を計算し、投稿のクエリでは最新のコメントを取得するかもしれません。これらのパターンを理解することで、DynamoDB で非正規化するデータと、事前計算した値として維持する属性を特定するのに役立ちます。

-- User profile with total posts count 
 SELECT u.name, u.profile_pic,
(SELECT COUNT(*) FROM posts WHERE user_id = u.user_id) as post_count 
 FROM users u 
 WHERE u.user_id = '123'

複数テーブルのカラム選択 – クエリが複数のテーブルのカラムを組み合わせる方法を分析し、頻繁に一緒にアクセスされるデータを示します。典型的な投稿表示クエリは、1 回のフェッチで、コンテンツ、著者の詳細、エンゲージメント統計を組み合わせます。この分析により、異なるエンティティからどの属性を 1 つのアイテムに非正規化して、DynamoDB での効率的な読み取り操作をサポートできるかを判断できます。

-- Post with author details 
 SELECT p.content, p.created_at, u.name, u.profile_pic 
 FROM posts p 
 JOIN users u ON p.user_id = u.user_id 
 WHERE p.post_id = '456'

ユーザー定義関数 – クエリでデータを変換または計算するユーザー定義関数の使用状況を確認してください。複数のエンゲージメント要因を時間ベースの重み付けで組み合わせてトレンドスコアを計算する関数は、クエリでの計算が複雑になります。これらの計算を理解することで、事前に計算して格納すべき属性と、DynamoDB でこれらの計算値を効率的に更新できるようにデータモデルを構造化する方法を特定するのに役立ちます。
派生列 – 複数のフィールド値を組み合わせたり、ビジネスロジックを適用してクエリ内の計算または条件付きの列を調査してください。多くの場合、クエリでは全体的なエンゲージメント指標を導出し、インタラクションのしきい値に基づいてコンテンツのステータスを判断します。この分析により、アイテムに計算済みの属性を維持するかどうか、および DynamoDB でこれらの派生値を最新に保つための効率的な更新パターンを設計するうえでの判断材料となります。

-- Derived engagement score and post status 
 SELECT post_id, content,
(like_count + comment_count) as total_engagement,
 CASE WHEN like_count > 1000 THEN 'TRENDING'
 WHEN like_count > 100 THEN 'POPULAR'
 ELSE 'NORMAL'
 END as post_status 
 FROM posts 
 WHERE created_at > DATEADD(year, -1, GETUTCDATE())

JOIN 句の分析

SQL クエリの JOIN 句を調べると、さまざまなエンティティ間の関係と、アプリケーションが複数のテーブルからどのようにデータを結合しているかがわかります。この分析により、DynamoDB での最適なデータモデル戦略を決定するのに役立ちます。JOIN 句を分析する際は、次の重要な側面を考慮してください。

エンティティの関係 – クエリでどのテーブルがよく結合されているかを分析します。投稿の表示クエリでは、投稿、コメント、いいね、ユーザーテーブルのデータを組み合わせることがあり、この操作ではこれらのエンティティが一緒にアクセスされることが多いことを示しています。これらの組み合わせを理解することで、効率的にアクセスするために DynamoDB で非正規化またはモデル化する必要があるデータの特定に役立ちます。
結合条件 – テーブル間の関係の条件と多重度を評価します。たとえば、投稿はコメントと一対多の関係になる可能性がありますが、ユーザープロファイルとは一対一の関係になります。結合条件には、単純なキーの一致以外にも、日付範囲やステータスフラグが含まれる場合があります。この多重度を理解することで、データをアイテム内に埋め込むか、別のアイテムを維持するかなど、適切なモデリング戦略を決定するのに役立ち、さまざまなモデリング手法のパフォーマンスとコストの影響を見積もるのに役立ちます。

-- Post with its comments 
 SELECT p.*, u.*, c.comment_text, c.created_at 
 FROM posts p 
 JOIN comments c ON p.post_id = c.post_id 
 AND c.created_at > DATEADD(hour, -24, GETUTCDATE())
 JOIN users u ON p.user_id = u.user_id 
 WHERE p.post_id = '456'

サービス間およびハイブリッドアーキテクチャの結合 – 異なるサービスに属するテーブル、または移行が計画されていないテーブルを含む結合を確認します。たとえば、投稿データが別のサービスによって管理されるユーザープロファイルデータと結合する場合や、リレーショナルデータベースに残る分析データと結合する場合などです。このようなパターンはデータモデリングの決定に影響します。この分析により、サービス境界を越えたデータアクセス戦略や、異なるデータベースに対する戦略の指針となります。

WHERE 句の分析

SQL クエリの WHERE 句を調べると、アプリケーションがデータをどのようにフィルタリングしてアクセスしているかを知ることができます。この分析は、DynamoDB で効率的なアクセスパターンを設計する上で役立ちます。WHERE 句を分析する際は、次の点に留意してください。

単一値フィルター – クエリで頻繁に使用される単一値フィルターを特定します。たとえば、特定のユーザー ID で投稿をフィルタリングしたり、ステータス別に投稿を取得したりするパターンです。これらのパターンは、DynamoDB のベーステーブルまたはグローバルセカンダリインデックス (GSI) の潜在的なパーティションキーを特定するのに役立ち、さまざまなアクセスパターンでデータを効率的に取得できるようになります。

-- Single value filter 
 SELECT * FROM posts WHERE user_id = '123'
 AND status = 'ACTIVE'

範囲ベースのフィルター – エンティティ識別子と範囲条件を組み合わせたクエリを探します。ユーザー ID と日付範囲で投稿をフィルタリングするクエリは、DynamoDB で複合キーを構造化する方法を示しています。これらのパターンを理解することで、パーティション内の効率的な範囲クエリをサポートする適切なソートキーを決定するのに役立ちます。

-- Getting user's recent posts 
 SELECT * FROM posts 
 WHERE user_id = '123'
 AND created_at > DATEADD(year, -1, GETUTCDATE())
 ORDER BY created_at DESC

複数値フィルター – 属性に対して複数の値が存在する条件を調査します。たとえば、あるユーザー ID グループによる投稿の検索や、特定のハッシュタグを含む投稿の検索などです。これらのパターンは、DynamoDB のデータモデリングの決定に影響を与えます。たとえば、複数のユーザーによる投稿を取得する場合は、ユーザー ID をパーティションキーとする GSI を使って個別のクエリを実行する必要がありますが、ハッシュタグによる投稿の検索では、ハッシュタグをパーティションキーとし、関連する投稿 ID を集合として格納する、逆インデックス構造が有益かもしれません。

-- Finding posts with specific hashtags 
 SELECT DISTINCT p.*
 FROM posts p 
 JOIN post_hashtags ph ON p.post_id = ph.post_id 
 WHERE ph.hashtag IN ('#POPULAR', '#TRENDING')

クロスエンティティフィルター – SQL クエリ内で複数のエンティティにまたがるフィルターを特定します。たとえば、投稿属性とユーザー属性 (ユーザーの場所やユーザータイプなど) の両方に基づいて投稿を検索するクエリは、DynamoDB モデルの非正規化の決定に影響を与える関係を示しています。これらのフィルターに、異なるマイクロサービスによって管理されるエンティティ、または DynamoDB に移行されないエンティティを含む場合は、クライアントサイドのフィルタリングとサービス境界を越えたデータ取得のパフォーマンス影響を分析します。

-- Finding active user posts with high engagement 
 SELECT p.post_id, p.content,
 FROM posts p 
 JOIN users u ON p.user_id = u.user_id 
 WHERE u.status = 'ACTIVE'
 AND p.like_count > 100 
 ORDER BY p.created_at DESC

ORDER BY 句と TOP/LIMIT 句の分析

ORDER BY 句と TOP/LIMIT 句を調べると、アプリケーションでのデータのソートとページネーションの要件が明らかになります。この分析は、DynamoDB での効果的なソートキーの設計を決定するのに役立ちます。以下の点を考慮してください:

ソート要件 – データの並べ替えに使用される属性と属性の組み合わせを特定します。たとえば、最新の投稿を表示するために作成日でソートする、または人気のコンテンツを表示するためにエンゲージメント指標でソートするなどです。一部のクエリでは、日付でソートした後、各日付内でいいね数でソートするなど、複合ソートが必要になる場合があります。これらのパターンを把握することで、必要なソート機能をサポートする適切な DynamoDB のソートキー構造を決定するのに役立ちます。
ページネーション要件 – TOP/LIMIT 句とソートを使用するクエリを分析します。最新の投稿を制限付きで取得するクエリや、エンゲージメント指標に基づいて人気の投稿を取得するクエリは、ページネーションが必要であることを示しています。これらのパターンを理解することで、DynamoDB の limit 機能と LastEvaluatedKey 機能を使って効率的なページネーション戦略の設計に役立ちます。

GROUP BY 句の分析

GROUP BY 操作を調査することで、アプリケーションで集約が必要な部分を明らかにできます。この分析により、DynamoDB データモデルで維持する必要がある指標やカウンターを特定できます。以下の点を考慮してください:

集約パターン – クエリ内のグループ化と集約操作を特定します。たとえば、ユーザーごとの投稿数のカウント、投稿ごとの合計いいね数の計算、投稿タイプごとのエンゲージメント指標の要約などです。これらのパターンを理解することで、アイテムに事前計算された値として維持する必要がある属性なのか判断するのに役立ちます。

-- Posts count by user 
 SELECT user_id, COUNT(*) as total_posts 
 FROM posts 
 GROUP BY user_id

更新頻度 – これらの集計値がどのくらいの頻度で変化するかを分析します。投稿へのいいね数は、ユーザーの操作に応じて頻繁に更新されますが、ユーザーの投稿総数は投稿を作成または削除したときにのみ変化します。このようなパターンを把握することで、書き込みパターンと、事前計算された値を維持する上での影響を評価するのに役立ちます。

アプリケーション使用状況の分析

アプリケーションの使用統計情報 (時間ごとの HTTP リクエスト頻度など) を収集します。ビジネス上の重要度と使用状況のメトリクスを、以下の目的で分析します。

特別な注意を要するエッジケースに優先順位をつける。例:
- 有名人が最新情報を投稿した場合、システムはその投稿を数百万人のフォロワーのフィードに即座に配信する必要がある。
- 口コミで広まった投稿には、数分以内に突然多くの「いいね」やコメントが付く可能性がある。
移行すべき主要なモジュールを特定する。

このデータ駆動型のアプローチでは、アプリケーションの最も重要で頻繁に使用される部分が移行プロセス中に優先されるため、リソースの割り当てが最適化され、コア業務機能への潜在的な中断が最小限に抑えられます。次の目標で、テーブルの平均行サイズ、読み取り/書き込み比率、予測成長率を分析します。

エンティティ関係を構築する最適なアプローチを決定する。たとえば、単一アイテム戦略と垂直パーティショニングのどちらを選択するか
読み取りと書き込みのキャパシティを正確に見積もり、割り当てる

結論

現在のデータベース構造、アクセスパターン、使用状況メトリクスを分析することで、DynamoDB への移行の基盤を構築できます。この理解は次のフェーズである DynamoDB のデータモデルの設計を形作るのに役立ちます。これについては、このシリーズのパート 2で説明します。この構造化されたアプローチに従うことで、移行戦略が現在のニーズと将来のスケーラビリティ要件の両方に合致していることを確認できます。

Amazon Web Services ブログ