Amazon Web Services ブログ
Amazon DynamoDB の増分エクスポートを使用した継続的なデータ保持
本記事は 2024年6月12日に公開された “Use Amazon DynamoDB incremental exports to drive continuous data retention” を翻訳したものです。
Amazon DynamoDB は、Amazon Simple Storage Service (Amazon S3) への増分エクスポートに対応しており、さまざまなユースケースでの、ダウンストリームのデータ保持や利用を実現しています。
このブログでは、初期にフルエクスポートを行った後に、継続的な増分エクスポートを実行していくことで、エクスポートされたテーブルデータを継続的に更新していく方法を説明します。このソリューションはDynamoDB Continuous Incremental Exports (DCIE 、GitHub でオープンソースにて提供) と呼ばれ、データが最新の状態に保たれた DynamoDB データのエクスポートを実現します。
DCIE のユースケースの一つは、DynamoDB テーブルに対するオフライン分析です。テーブルサイズが大きくなると、繰り返しフルエクスポートを行うよりも、一度フルエクスポートした後に増分エクスポートを行う方がコスト効率が良くなります。この方法を使えば、例えばApache Iceberg テーブルを最新の状態に保つことができます。
DCIE の別のユースケースは、1 つの DynamoDB テーブルから別の DynamoDB テーブルへの変更を反映することです。
まず、新しいテーブルをフルエクスポートに基づいてブートストラップします。その後、新しいテーブルが最新になるまで、一連の増分エクスポートを進めていきます。新しいテーブルは、同じ AWS アカウント内の別のテーブル、別の AWS アカウント内のテーブル、さらには別の AWS リージョン内にあるテーブルでも構いません。
DCIE は一連のエクスポートを作成するのみであり、このブログではこれらのエクスポートを Iceberg テーブルに取り込んだり、別の DynamoDB テーブルに読み込むことには触れません。
継続的なエクスポート
この節では、ワークフローの動作方法について説明します。まず、Amazon S3 へのフルエクスポートを実行します。これにより、特定の時点でのテーブル内容をキャプチャすることができます。次の図は、最近の時点 (t = 0 と呼ばれる) で行われたフルエクスポートを示しています。
その後、デフォルトでは 15 分ごとに定期的な増分エクスポートを実行します。増分エクスポートごとに、2 つの時間の間(つまり、全エクスポートの終了から 15 分後まで)に発生した変更をキャプチャします。増分エクスポートは、コーディング時に差分表示されるdiffに似ています。その後、新しいエクスポートは、定期的に実行されます。
時間範囲が正確に一致していないと、期間にギャップが生じてしまいます。フルエクスポートの終了時刻は最初の増分エクスポートの開始時刻と一致している必要があります。また、最初の増分エクスポートの終了時刻は次の増分エクスポートの開始時刻でなければなりません。このようにすることで、テーブル全体の内容が一連のエクスポート結果に確実に反映されます。
次の図に示すように、t = 1で開始した増分エクスポートは完了までにしばらく時間がかかり、t = 2の後に完了する可能性があります。これは問題ありません。2 つの エクスポートは同時に実行できます。DynamoDB のエクスポートにはメタデータが含まれているため、エクスポートが正常に完了したかどうかを判断できます。また、エクスポートメタデータにより、ダウンストリームのコンシューマーは正常なエクスポートのみを正しい時系列順に処理できます。
ソリューションの概要
DCIE は Amazon EventBridge Scheduler を使用してワークフローを定期実行するスケジューリングを行い、ワークフロー内の調整を AWS Step Functions で管理しています。Step Functions を使用することで、このような分散アプリケーションを簡単にデザイン、カスタマイズ、実行、可視化、管理、再試行、そして視覚的にデバッグできます。
ワークフローのデプロイには、5 つのパラメータが必要です。複数のDynamoDB テーブルに複数回デプロイを行えるようにするためのスタック名、ソースとなる DynamoDB テーブル名、テーブルとインフラストラクチャの簡単なマッピングを可能にするデプロイエイリアス、エクスポート成功時の通知を受け取るメールアドレス、エクスポート失敗時の通知を受け取るメールアドレスです。Step Functions ステートマシンは、Parameter Store を使用して状態を維持します。これは AWS Systems Manager の機能の 1 つです。
DCIE をAWS Cloud Development Kit (AWS CDK) を使ってデプロイすることができ、カスタマイズに上記のパラメータを設定するだけで済みます。また、カスタム S3 バケット、S3 プレフィックス、増分エクスポートの時間間隔をデフォルトの 15 分よりも長くする、エクスポートが完了したかを確認する間隔をデフォルトの 10 秒より長くまたは短くするなどのオプション設定も行えます。
Step Functions のワークフローは、まず事前チェックを行い、指定されたテーブルが存在し、ポイントインタイムリカバリー (PITR) が有効になっているかを確認します。PITR は、S3 エクスポートに必須となります。
このワークフローには 2 つの主要なツリーがあります。最初にフルエクスポートを実行するツリーと、後続の増分エクスポートを実行するツリーです。それぞれのツリーは作業を開始し、定期的に完了やエラーを確認します。エラー時には状態の更新やメール送信を行います。特定のニーズがある場合は、ワークフローを自分で変更できます。次の図は、ワークフローの簡略化された論理的な表現です。
DCIE のデプロイの詳細については、GitHub リポジトリの README をご覧ください。
コストの管理
DCIE をデプロイするコストには以下が含まれます:
- PITR を有効にするための継続的な料金 (テーブルのサイズに基づきます)
- 初回 フルエクスポートの費用 (テーブルのサイズに基づきます)
- 各 増分エクスポートの費用 (処理するデータ量に応じ、また時間ウィンドウ内の変更数に比例します)
- Amazon S3 を使うために発生するコスト (オブジェクト書き込み、データストレージのコストは時間と共に増加します)
- AWS Lambda、Amazon Simple Notification Service (Amazon SNS)、Amazon CloudWatch Logs の利用コスト
まとめ
DynamoDB の新しい Amazon S3 への増分エクスポート機能により、DynamoDB テーブル内のデータをダウンストリームのデータ コンシューマへ簡単にエクスポートできます。
このブログでは、最初にフルエクスポートを行い、その後、継続的な増分エクスポートのシリーズを生成することで、S3 バケットを継続的に更新するためのオープンソースソリューションを紹介しました。
これを利用することで、ダウンストリームの Iceberg テーブルにデータを供給したり、別の DynamoDB テーブルにデータを供給したり、または、リモートの S3 バケットにコピーして、リモートリージョンでテーブルを再作成するためのディザスターリカバリープランの一部として使用したりできます。
DynamoDB から S3 へのエクスポートの詳細については、ドキュメントガイドを参照してください。
本ブログはソリューションアーキテクトの堤が翻訳しました。原文はこちら。