Amazon Web Services ブログ

Amazon DynamoDBにおけるバックアップ戦略

データベースについて話し合うときに最も重要な質問の 1 つは、「データをどのようにバックアップおよび復元するか」です。バックアップはあらゆるディザスタリカバリ戦略の中心的な要素であり、主に目標復旧時点 (RPO) と目標復旧時間 (RTO) によって管理されます。最小限の管理でニーズを満たし、ビジネスに支障をきたさず、費用対効果が高いバックアップ戦略が必要です。この記事では、 Amazon DynamoDB で使用できるさまざまなバックアップ戦略と、それぞれの最適なユースケースについて説明します。

DynamoDB のポイントインタイムリカバリ

DynamoDB ポイントインタイムリカバリ (PITR) は、DynamoDB に組み込まれているフルマネージド型の継続的なバックアップ機能です。PITR を有効にすると、過去 35 日間の任意の時点にテーブルを 1 秒単位の精度で復元できます。PITR バックアップはシステムレベルで、AWS 管理アカウントに保持されます。アカウントが不正アクセスされた場合でも、権限のないユーザーはこのバックアップを削除できません。次の例のように、AWS マネジメントコンソール、AWS SDK、または AWS コマンドラインインターフェイス (AWS CLI) から PITR を有効にできます。

aws dynamodb update-continuous-backups --table-name <SOURCE-TABLE> --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

PITR を有効にしても遡って適用されないことに注意してください。利用可能な最も早い復元ポイントは、PITR を有効にした時点です。

PITR では、DynamoDB コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用してテーブルをある時点に復元できますが、一部のソーステーブルレベルの設定は、新しく作成されたテーブルに自動的に適用されません。これには、自動スケーリング、ストリーム、有効期限 (TTL) などが含まれます。AWS CloudFormation テンプレートを使用して復元されたテーブルに Amazon DynamoDB テーブル設定を自動的に適用するイベント駆動型ソリューションについては、「Automate update of table settings on restored Amazon DynamoDB table」を参照してください。

PITR はデータを失うリスクを大幅に最小限に抑え、テーブルへの誤った削除や書き込みを防ぐため、データ損失の影響を受けやすいワークロードに役立ちます。1 秒単位の精度により、厳しい RPO（目標復旧時点）を簡単に達成できます。定期バックアップなどの代替案を検討する場合、最後のバックアップポイントまでしか回復できないため、何時間ものデータ損失が発生する可能性があります。PITR の概要については、「新機能 – Amazon DynamoDBに継続的バックアップとPoint-In-Time-Recovery(PITR)機能が追加されました」を参照してください。

DynamoDB オンデマンドバックアップ

オンデマンドバックアップを使用すると、テーブルのパフォーマンスに影響を与えずにテーブル全体をバックアップすることができます。サービス API またはコンソールを使用して、個々のバックアップを新しいテーブルに復元できます。新しいテーブルに復元する場合、DynamoDB では、グローバルセカンダリインデックス (GSI)、ローカルセカンダリインデックス (LSI)、暗号化設定などの設定を保持または変更できます。

オンデマンドバックアップを作成するには、コンソール、選択したプログラミング言語の AWS SDK、または AWS CLI を使用できます。以下は、オンデマンドバックアップを作成するための AWS CLI コマンドの基本的な例です。

aws dynamodb create-backup --table-name <SOURCE-TABLE> --backup-name <BACKUP-NAME>

多くのワークロードでは、毎週または毎日特定の時間にスケジュールされたバックアップを行う必要があります。このような定期バックアップは DynamoDB のオンデマンドバックアップの機能にはないと思われるかもしれません。DynamoDB のバックアップをスケジュールするには、フルマネージド型の一元管理型データ保護サービスである AWS Backup を使用できます。AWS Backup を使用して DynamoDB テーブルのバックアップスケジュールを作成および管理できます。AWS Backup ではクロスアカウントバックアップが可能で、バックアップを他の AWS アカウントにコピーできるようになり、保護が強化されます。さらに、コンプライアンス要件のために長期的に保存する必要があるバックアップがある場合は、コールドストレージを利用してコストを節約できます。

オンデマンドバックアップに適したシナリオを以下に示します。

  • 米国証券取引委員会の要件により 7 年間データを保持することが義務付けられているなど、規制コンプライアンス上データを 35 日以上保持することが義務付けられている場合
  • 開発アカウントやテストアカウントなどの AWS アカウント間でテーブルをコピーする必要がある場合
  • データを別の AWS リージョンにコピーまたは移行する必要がある場合

PITR バックアップとオンデマンドバックアップのどちらを選択するか

いくつかの異なる DynamoDB ワークロードを考えてみましょう。

  • ワークロード 1 — RPO が 45 分、データ保持期間が 30 日というウェブアプリケーションを実行させるための DynamoDB テーブル。
  • ワークロード 2 — 15 分の RPO と 7 年間のデータ保持というコンプライアンス要件を満たす金融サービスアプリケーションを実行させるための DynamoDB テーブル。
  • ワークロード 3 — 研究用アプリケーションを実行させるための DynamoDB テーブル。研究用アプリケーション内のシミュレーション実行時に使用されるルックアップテーブルであるため、テーブル内のデータは変更されません。データは不変であるため、RPO（目標復旧時点）はありませんが、データの再作成にはコストがかかるため、バックアップが必要です。

1 つ目のワークロードでは、PITR はバックアップ要件をすべて満たすことができます。PITR は秒単位の精度と 35 日間の保存期間を備えているため、 45 分の RPO と 30 日間の保存要件を簡単に満たすことができます。
2 つ目のワークロードはもう少し複雑です。PITRを有効にすると、RPO は満たされますが、 7 年間の保存要件は満たされません。ここでは、AWS Backup を PITR と組み合わせて使用することで、この要件を満たすことができます。AWS Backup を使用すると、オンデマンドバックアップをスケジュールして 7 年間保存し、コールドストレージを利用することでコストを節約できます。
3 つ目のワークロードは、データが変更されないため、オンデマンドバックアップを 1 回実行するだけで要件を満たすことができます。

これらの例から、いくつかの一般的なガイドラインがわかります。

  • ほとんどのテーブル、特に RPO 要件の低いテーブルでは、PITR の使用が推奨されます。
  • RPO は低くてもコピーを 35 日以上保持する必要がある場合は、PITR と併用して AWS Backup によるオンデマンドバックアップを使用してください。

まとめ

この記事では、バックアップとコンプライアンスの要件を満たすのに役立つ DynamoDB テーブルをバックアップするさまざまな方法について学びました。詳細については、「DynamoDB のオンデマンドバックアップおよび復元の使用」と「DynamoDB のポイントインタイムリカバリ」を参照してください。

この記事を DynamoDB バックアップ戦略を検討する上での第一歩としてご活用いただくことをお勧めします。また、質問やフィードバックがある場合はコメントをお願いします。

作者情報

Ted Zamborsky はワシントン州シアトルに拠点を置くアマゾンウェブサービスのソリューションアーキテクトです。彼は非営利の研究顧客と仕事をしています。彼はキャンドルが大好きです。

翻訳はソリューションアーキテクト河角が担当しました。原文はこちらです。