🔙
DynamoDB のバックアップとリストアについて
はじめに
あらためて DynamoDB のバックアップとリストアについて調べる機会があったので、ざっくりだがこちらにまとめておく。
以下のページがよくまとまっていたため、参考にさせていただいた。
前提条件
今回の調査では、アプリケーションの変更を伴う方法は対象外とした。例えば、ポイントインタイムリカバリを使って別リージョンに既存のテーブル名でリストアするなど。
また、今回の調査では数日程度のデータがバックアップされていることが要件だったため、長期間のデータ保持が可能な方法は対象外とした。
方法
マイナーな方法を書くとキリがないため、メジャーな方法について以下に簡単に Pros/Cons をまとめる。
| 方法 | Pros | Cons |
|---|---|---|
| オンデマンドバックアップ | - 任意の時点で完全バックアップを作成できる - 長期間のデータを保持できる |
- バックアップの作成に時間がかかる場合がある - コストが高くなる可能性がある |
| AWS Backup | - バックアップのスケジュールを柔軟に設定できる - バックアップの保持期間を設定できるので、コストを抑えることができる |
- 大量のデータや長期間のバックアップすると、データのリストアに時間がかかる場合がある - 大量のデータや長期間のバックアップすると、コストが高くなる可能性がある |
| ポイントインタイムリカバリ (PITR) | - 過去35日間の任意の時点にデータをリストアできる - テーブルの誤操作からの保護に役立つ |
- 35日以上前のデータはリストアできない - 有効にすると、テーブルのストレージコストが増加する |
| Amazon S3 | - データの移行や分析に利用できる - S3 の安価なストレージを利用できる - PITR を利用するため同様の事象が発生する |
- 大量のデータや長期間のバックアップすると、エクスポートやインポートに時間がかかる可能性がある - インポートに制限がある - PITR を利用するため同様の事象が発生する |
リストア
今回の調査では数日程度のデータがバックアップされていることが要件なので、上記での中で
ポイントインタイムリカバリ(PITR) と Amazon S3 の2パターンを試してみた。
ポイントインタイムリカバリ(PITR)
リストアの流れとしては以下の通り。
- リストア対象のテーブルと別名でリストアを実施
- リストア対象のテーブルを削除
- リストアされたテーブルから再度リストアを実施
- 1で別名でリストアされたテーブルを削除
気になった点
- 既存のテーブルの削除するため、ダウンタイムが発生する
- リストアによって復元されない設定は手動または IaC などで設定し直す必要がある
- 2度リストアするため、作業に時間がかかる
- 1度リストア(リスト -> テーブル削除)してしまうと、その後リストアすることができなくなる
- 稼働させながらのリストアは難しい(リストア中に書き込まれるデータをどうするか考慮しなければならない)
Amazon S3
あらかじめバックアップ用の S3 バケットを作成し、リストア対象のテーブルを作成した S3 バケットにエクスポートしておく。
リストアの流れとしては以下の通り。
- リストア対象のテーブルを削除
- S3 へのインポートからリストア対象のテーブルと同名でインポートを実施
気になった点
- 既存のテーブルの削除するため、ダウンタイムが発生する
- リストアによって復元されない設定は手動または IaC などで設定し直す必要がある
- インポート機能には制限がある
- エクスポートとインポートの時間はデータ量に左右される(TTL をきちんと設定すればある程度は回避できそう)
- 何らかの方法で、S3 へのエクスポートを定期実行しなければならない
結論
参考にさせていただいたページにも書かれているとおり、2024年4月19日時点でもスマートなリストア方法はなさそうだった。
今回の調査では、数日程度のデータがバックアップされていることが要件であり、バックアップを必要とするテーブルも1つかつ多くても1日に数十件程度のデータ量であったため、PITR を有効にしつつ別名でのリストア後にシェルスクリプトで差分のデータをインポートするかたちで対処することにした。
Discussion