Azure Cosmos DB から Amazon DynamoDB に移行する際に想定される相違点

(本記事は 2023/01/27に投稿された Differences to expect when migrating from Azure Cosmos DB to Amazon DynamoDB を翻訳した記事です。)

Azure Cosmos DBのワークロードをAmazon DynamoDBに移行することを検討しているお客様から、どのような違いが想定されるのかと聞かれることがあります。この記事では、Azure Cosmos DBからDynamoDBへの移行時に想定される相違点と、それに備えるための計画について説明します。DynamoDBは、一般的なアクセスパターン (通常は大量のデータの保存と取得) に合わせて最適化された、サーバーレスなキーバリュー型のデータベースです。DynamoDBではマルチリージョン、アクティブーアクティブなフルマネージドのデータベースであり、あらゆる規模で１桁ミリ秒という一貫したレイテンシー、保存時の暗号化、バックアップと復元、インメモリキャッシュを実現します。DynamoDBはイベント駆動型アーキテクチャの一部として一般的に使用されており、他のAWS サービスを使用することでDynamoDBの機能を拡張することができます。

用語とアーキテクチャの比較

Azure Cosmos DBとDynamoDBはどちらもNoSQLデータベースですが、移行を開始する前にアーキテクチャと用語の違いを考慮する必要があります。

表 1: DynamoDB と Azure Cosmos DB の用語とアーキテクチャの比較
（注：より理解しやすいように本文の英語を併記しています）

Amazon DynamoDB テーブル、スキーマ、およびインデックス

移行をシンプルにするため、Azure Cosmos DBのコレクションとDynamoDBのテーブル間を１対 １でマッピングするようにしてください。DynamoDBにはデータベースの概念はなく、テーブルと呼ばれるエンティティがあります。Azure Cosmos DBのコレクションに基づいてDynamoDBのテーブルを作成する場合：

1. 1. カーディナリティの高いパーティションキーを選択します。DynamoDBはパーティションキーの値を内部ハッシュ関数への入力として使用します。ハッシュ関数の出力によって、項目が保存されるパーティションが決まります。各項目の場所は、そのパーティションキーのハッシュ値によって決定されます。ほとんどの場合、同じパーティションキーを持つ項目は項目コレクションにまとめて格納されます。項目コレクションは、パーティションキーは同じでソートキーが異なる項目のグループとして定義されます。複合プライマリキーを含むテーブルでは、ソートキーはパーティションの境界として使用できます。DynamoDBは、コレクションサイズが10 GBを超えると、仮想的なパーティションをソートキーごとに分割します。ソートキーを使用してAzure Cosmos DBのプライマリ複合インデックスを置き換えることもできます。パーティションキーを選択する方法の詳細については、「Choosing the Right DynamoDB Partition Key」を参照してください。
   2. 同じパーティションキーと異なるソートキーを必要とするクエリパターンの場合では、非キー属性とともに、メインテーブル作成時にGSIまたはLSIを作成できます。GSIは、非キー属性とともに、テーブルの作成中または作成後でも作成することができます。
      注: GSIが推奨されるオプションです。LSIを使用する場合、１つのパーティションキー値に対するインデックス項目の合計サイズが 10GB を超えることはできません。
   3. プライマリキーとソートキーが異なるクエリパターンには、GSIを使用することが推奨されます。GSIはメインテーブルの作成中または作成後に、非キー属性とともに作成することができます。Amazon Simple Storage Service (Amazon S3) から DynamoDB データをインポートする場合、インポート中にGSIが追加されます。ローカルおよびグローバルセカンダリインデックスは、一度定義されると、DynamoDBによって自動的に管理されます。セカンダリインデックスを使用すると、ベーステーブルと比較してデータサイズを削減するのに役立ちます。セカンダリインデックスのサイズが小さくなるかどうかは、使用される非キー属性の数によって異なりますが、プロビジョニングされたスループットのパフォーマンスを向上させるのに役立ちます。プロビジョニングモードのテーブルにGSIを作成する場合、そのインデックスに予想される負荷に応じて読み取りと書き込みキャパシティーユニットを指定する必要があります。GSI上でのクエリ操作は、ベーステーブルではなく、インデックスから読み取りキャパシティユニットを消費します。テーブル内の項目を追加、更新、削除すると、そのテーブルのグローバルセカンダリインデックスは非同期で更新され、インデックス更新は、ベーステーブルではなくインデックスの書き込みキャパシティーユニットを消費します。テーブル属性をGSIに投影する場合は、新しい更新がベーステーブルとGSIの両方に書き込みを行うため、プロビジョニングされた書き込みキャパシティーユニットをベーステーブルの書き込み容量と同等かそれ以上の値に設定することを推奨します。なお、GSIの更新には ２つの書き込みが必要となり、１つは、インデックスから前の項目を削除する書き込み、もう１つはGSIのパーティションキーまたはソートキーである属性を更新する際に、新しい項目をインデックスに追加するための書き込みとなります。
   4. Azure Cosmos DBは、２つ以上のプロパティを持つ複合インデックスをサポートしています。ソートキーを連結して DynamoDBプライマリキーとセカンダリインデックスにマッピングできます。例えば、Azure Cosmos DBのEmployee ID、Country、State、Cityの各フィールドが複合キーとして定義されている場合、DynamoDB では、Employee IDをパーティションキー、ソートキーをcountry#state#cityに置き換えます。なお、ソートキーの#はユーザー指定の区切り文字で、コロン（:）、カンマ（,）、チルダ（~）などの他の区切り文字に変更できることに注意してください。
   5. DynamoDBはAzure Cosmos DBのデータ型をサポートしているほか、バイナリとセットのデータ型もサポートしています。Azure Cosmos DBからDynamoDBへの属性マッピングについては、表２を参照してください。

表 2: DynamoDB 属性マッピング

6. DynamoDBインデックスはAzure Cosmos DBとは異なります。Azure Cosmos DBは転置インデックスを使用しますが、DynamoDBはテーブルパーティションとインデックスパーティションにハッシュアルゴリズムを使用します。Azure Cosmos DBのネストされたJSONインデックスを移行する場合、Azure Cosmos DBのインデックス付き属性は DynamoDB のプライマリキー、LSI、または GSIの一部である必要があります。ネストされたインデックス化されていないオブジェクトをマップデータ型として追加できます。
7. DynamoDBにはAzure Cosmos DBストアドプロシージャやユーザー定義関数と同等のものはありませんが、AWS LambdaまたはDynamoDB StreamsとLambdaの組み合わせを使用して同等の機能を実行することは可能です。DynamoDBクライアントはDynamoDBデータの事後後処理に責任を持ちます。

キャパシティユニット

DynamoDBには、読み取りキャパシティーユニット (１つの RCU は、強力な整合性のある読み取りでは1秒あたり4KB、結果整合性のある読み取りでは 8KB/秒) と書き込みキャパシティーユニット (1 WCU はDynamoDBテーブルへの書き込みで1秒あたり1KB) があります。DynamoDBのRCUとWCUの要件を把握するには、DynamoDBをオンデマンドモードで実行することをお勧めします。移行を完了する前にオンデマンドモードでテーブルの負荷テストを実行することで、アプリケーションとテーブルがライブトラフィックに最適化されていることを確認できます。トラフィックパターンが急上昇するような場合には、引き続きDynamoDBオンデマンドモードの使用を継続します。予測可能なトラフィックパターンでは、負荷テストのベースラインを使用してプロビジョニングされたキャパシティを設定します。DynamoDBがアプリケーショントラフィックの増加に合わせてスケールすることができ、プロビジョニングされたスループットが不十分であることによるエラーを回避できるようにするために、プロビジョニングされたキャパシティーでオートスケーリングを使用することを推奨します。

グローバルテーブルの場合、書き込みキャパシティーの設定は、使用する各リージョンのレプリカテーブルとセカンダリインデックス全体で一貫して設定する必要があります。また、グローバルテーブルのレプリカの読み込みキャパシティー設定は、リージョンの読み取り要件に基づいている必要があります。

有効期限 (TTL)

Azure Cosmos DBの有効期限（TTL）設定をDynamoDBに移植できます。Azure Cosmos DBのTTL（秒単位）をDynamoDB のエポックタイムに変換する必要があります。DynamoDB TTLでは、項目ごとにタイムスタンプを定義して、項目が不要になる時期を判断できます。項目が不要になったことを示すタイムスタンプから48時間以内に、DynamoDB は書き込みスループットを消費せずにその項目をテーブルから削除します。TTL は、ワークロードのニーズに合わせて最新の項目のみを保持することで、保存されるデータ量を削減する手段として、追加コストなしで提供されます。

DynamoDBのきめ細かなアクセス

Azure Cosmos DBには、ロールベースのアクセス制御（RBAC）が組み込まれています。DynamoDBは、AWS Identity and Access Management（IAM）を使用して、項目および属性レベルでのきめ細かなアクセスを提供します。IAMポリシーは、DynamoDBのテーブルに格納された項目や属性へのアクセスを制御します。以下は、きめ細かいアクセス制御の２つの例です。

• ユーザーの位置情報に基づいて近くの空港の情報を表示するモバイルアプリ。アプリは、航空会社名、到着時刻、フライト番号などの属性にアクセスして表示することができます。ただし、パイロットの名前や乗客数にアクセスしたり表示したりすることはできません。
• ユーザーのハイスコアを１つのテーブルに保存するモバイルゲーム。各ユーザーは自分のスコアを更新できますが、他のプレイヤーのスコアを更新することはできません。

マイクロ秒単位のパフォーマンスを実現するAmazon DynamoDB DAX

Azure Cosmos DBの読み取り時でマイクロ秒のレスポンスにサードパーティのキャッシュソリューションを使用している場合、Amazon DynamoDB Accelerator（DAX）を使用することもできます。DAXを使用すると、コードをリファクタリングすることなくキャッシュソリューションを組み込むことができます。DAXは、DynamoDBのための結果整合性のあるライトスルーキャッシュレイヤーです。DAX は、必要に応じてリードスルーモード、ライトスルーモード、またはライトアラウンドモードで使用することができます。

Azure Cosmos DB変更フィードをDynamoDBに再設計する

Azure Cosmos DBは、Azure Cosmos DBの変更フィードを使用して他のAzureサービスに変更を伝搬します。DynamoDBには、変更データキャプチャ（CDC）用にAmazon Kinesis Data StreamsとAmazon DynamoDB Streamsという２つのストリーミングオプションがあります。それぞれのストリーミングオプションは、以下で説明するユースケースに対応しています。

Kinesis Data Streamsは、ログデータのキャプチャ、リアルタイムメトリックスとレポート、リアルタイムデータ分析、複雑なストリーム処理などのユースケースに使用します。データストリームは、レコードの順序付けや重複が重要ではない場合に使用します（最終的な宛先で重複を処理し、冪等性のある処理を実現することができます）。たとえば、Amazon OpenSearch Serviceでは、複数のコンシューマーが無制限のスループットでストリームを並行処理する必要がある場合や、24時間を超えるデータ保持が必要な場合に、バージョニングと一意のIDを組み合わせて処理の重複を防ぐことができます。

DynamoDB Streamsは、時系列の変更ストリームをキャプチャし、この情報を最大24時間ログに保持します。その後、アプリケーション内からDynamoDB Streams Kinesis AdapterとDynamoDB Streams APIを使用して、専用のエンドポイントからデータレコードを読み取ることができます。また、Lambdaを自動スケーリングで使用してDynamoDB Streamsのデータを処理することもできます。

DynamoDB Streamsを使用する場合、ストリーミングデータを利用するには Kinesis Adapterが推奨されます。DynamoDB Streams Kinesis Adapterは、アプリケーションに代わってシャード管理（シャードの有効期限と分割）を自動化します。また、「DynamoDB Streams Kinesis Adapter を使用したストリームレコードの処理」に記載されている、その他の利点もあります。Lambdaを使用してDynamoDBの追加、更新、削除イベントを開始できます。Azure Cosmos DBトリガーの代わりに DynamoDB StreamsとLambdaトリガーを使用することを検討してください。

DynamoDB Streamsの使用方法の詳細については、「DynamoDB Streams Use Cases and Design Patterns」を、Kinesis Data Streamsと DynamoDB Streamsの詳細な比較については DynamoDB ドキュメントを参照してください。

400 KB を超える項目の処理

DynamoDB の最大項目サイズは400KB で、これには属性名のバイナリ長 (UTF-8の長さ) と属性値の長さ (バイナリの長さ) の両方が含まれます。DynamoDBでは、400KBを超える項目に対して、GZIPなどの圧縮アルゴリズムを使ってから項目を挿入したり、大きな項目を複数の小さな項目に分割したりすることができます。また、これらの大きなオブジェクトをS3バケットに保存し、S3オブジェクトのURLを属性としてDynamoDBテーブルに保存することもできます。このアプローチでは、DynamoDBのインデックスを使用して高速な検索を行い、S3を耐久性が高く費用対効果の高いオブジェクトストアとして使用できます。

例として、あるアプリケーションが従業員の記録（名前、住所、その他の情報）を管理し、各従業員の600×400ピクセルの画像も保存する必要があるとします。この場合、1人の従業員の項目サイズが 400 KB の制限を超えています。さらに、ユーザーは従業員の項目がDynamoDBに追加されたら、すぐに人事アプリケーションを更新する必要があります。画像のURLを従業員の項目の属性として保存し、イメージを S3 バケットに保存できます。DynamoDB Streamsを使用してLambda関数を起動し、人事アプリケーションを更新できます。以下の図 1 は、このアプローチを示しています。

図１：大きなアイテムサイズを扱うためのアーキテクチャ

この記事に記載されているソリューションオプションの詳細については、「Large object storage strategies for Amazon DynamoDB」と「Use vertical partitioning to scale data efficiently in Amazon DynamoDB 」を参照してください。

グローバルテーブルとリージョナルテーブル

DynamoDBグローバルテーブルは、独自のクロスリージョンレプリケーションソリューションを構築、維持することなく、マルチリージョン、アクティブーアクティブデータベースを展開するためのフルマネージドソリューションです。テーブルを利用したいリージョンを指定することができ、DynamoDBはそれらのリージョンを介して継続的なデータ変更をテーブルに伝搬します。これにより、ユーザーがどこにいても、低レイテンシーのデータアクセスが可能になります。Azure Cosmos DBのグローバルデータレプリケーションの代わりに DynamoDBグローバルテーブルを簡単に使用することができます。

DynamoDB はレプリカと同期するための非同期レプリケーションを提供し、通常1秒未満でリージョン間のレプリケーションを行います。レプリカの競合が発生した場合、DynamoDBグローバルテーブルでは、ベストエフォートで最終書き込み者優先が使用されます。DynamoDBグローバルテーブルは、グローバルに分散したユーザを持つ地理的に分散したアプリケーションに最適です。

Amazon DynamoDBのバックアップとリストア機能

DynamoDB には、データをバックアップおよびリストアするためのオプションがいくつかあります。ポイントインタイムリカバリ（PITR）を使用すると、偶発的なDynamoDBテーブルへの書き込みや削除から保護することができます。PITRは継続的にデータをバックアップするので、AWS マネジメントコンソール、AWS コマンドラインインターフェイス（AWS CLI）、または DynamoDB API を使用して、過去35日間の任意の時点にテーブルをリストアできます。PITRを使用することで、オンデマンドバックアップの作成、管理、スケジュールについて心配する必要はありません。また、DynamoDB のオンデマンドバックアップ機能を使用して、テーブルのフルバックアップを作成し、長期保存したり、コンプライアンスの対応に合わせてアーカイブを作成することができます。PITRとオンデマンドバックアップはどちらも、テーブルのパフォーマンスや APIレイテンシーには影響を与えません。

Azure Cosmos DB データを DynamoDB に移行

Azure Cosmos DBからDynamoDBへのデータ移行は以下の手順で行います。

1. Azure Azure データエクスプローラーを使用して CSV形式でデータをエクスポートします。
2. データがCSV形式になったら、AWS Database Migration Service (AWS DMS)を使用して DynamoDB に移行します。AWS DMS に関するチュートリアルについては、「Migrate Delimited Files from Amazon S3 to an Amazon DynamoDB NoSQL Table Using AWS Database Migration Service and AWS CloudFormation」を参照してください。
3. DMSを利用してデータを同期させます。

AWS Glueを使用してCosmos DBを移行できます。詳細については、「Migrate from Azure Cosmos DB to Amazon DynamoDB using AWS Glue 」を参照してください。

Amazon S3 からテーブルデータをインポートすることもできます。詳細については、「Amazon DynamoDB can now import Amazon S3 data into a new table」を参照してください。

まとめ

この記事では、Azure Cosmos DBとDynamoDBの関連する機能の違いと、移行時に考慮すべきアーキテクチャパターンについて説明しました。相違点はあるものの、それに適応するための方法があります。グローバルセカンダリインデックスのシャーディングとインデックスの過負荷への戦略、マテリアライズドクエリを使用したスケーラブルなグラフ処理、複合キーを使用したリレーショナルモデリング、そして、DynamoDBでのトランザクションワークフローの実行に関する詳細情報は「DynamoDB Deep Dive: Advanced Design Patterns」を参照してください。

質問や提案がある場合は、コメントを残してください。

著者について

Utsav Joshi はAWSのプリンシパルテクニカルアカウントマネージャーです。ニュージャージー州在住で、AWSのお客様と協力してアーキテクチャ、運用、およびコスト最適化の課題を解決することを楽しんでいます。余暇には、旅行、ロードトリップ、子供たちとの遊びを楽しんでいます。

Joydeep Dutta はAWSのシニアソリューションアーキテクトです。Joydeepは、AWSのお客様と協力してワークロードを AWS クラウドに移行し、コストを最適化し、アーキテクチャのベストプラクティスを支援することを楽しんでいます。彼は、企業のコストと複雑さを軽減するのに役立つエンタープライズアーキテクチャに情熱を注いでいます。彼はニュージャージー州に住んでおり、余暇には音楽を聴いたり、屋外で過ごしたりしています