DynamoDBのバックアップとポイントインタイムリカバリ

DynamoDBは2通りの方法でデータを保護します。オンデマンドバックアップは自分で取得し、無期限に保持できるフルスナップショットです。ポイントインタイムリカバリ(PITR)は継続的かつ自動のバックアップで、ローリングウィンドウ内の任意の秒へテーブルをリストアできます。どちらも新しいテーブルへリストアします — これらはリカバリツールであり、取り消しボタンではありません。

監査ログにとってこれは譲れません。監査ログは改ざん不可能なコンプライアンス記録であり、イベントを書き換える不正なマイグレーションや誤った一括削除は、ミスの直前の瞬間までリカバリできなければなりません。

DynamoDBのバックアップとポイントインタイムリカバリの仕組みは?

DynamoDBには2種類のバックアップがあります。ポイントインタイムリカバリ(PITR)は継続的な自動バックアップを取得し、設定可能な1〜35日のウィンドウ内の任意の秒へリストアできます。オンデマンドバックアップは手動で取得するフルスナップショットで、無期限に保持できます。どちらも元のテーブルに上書きするのではなく新しいテーブルへリストアするため、その場で取り消すツールではなく、リカバリのためのツールです。

• PITR = 継続的バックアップで任意の秒へリストア。ウィンドウは1〜35日で設定可能です(以前は35日固定でした)。
• オンデマンドバックアップ = 手動のフルスナップショット。PITRのウィンドウとは独立して、好きなだけ保持できます。
• リストアは新しいテーブルを作成します。 新しい名前へリストアしてから切り替えます — 元のテーブルは手つかずのままです。
• PITRの料金はテーブルサイズに基づきます。リストアポイントの数ではありません — DynamoDB料金計算ツールで見積もってください。

問題:その場で取り消せないミス

DynamoDBにはロールバックできるトランザクションログがなく、書き込みに対する「取り消し」もありません。マイグレーションスクリプトがすべてのイベントのactionフィールドを書き換えたり、誰かが意図より広範囲の削除を実行したりすると、テーブルは単純に誤った状態になります。バックアップがなければ、データは失われます。

監査ログ — その価値のすべては信頼できる記録であることにあります — にとって、「先週火曜日のイベントを取り戻せない」というのは単なる不便ではなく、コンプライアンス上の失敗です。

バックアップとPITRの仕組み

ポイントインタイムリカバリは、有効にすると継続的な自動バックアップを取得します。AWSドキュメントによれば、PITRは「最大35日間のリカバリポイントを秒単位の粒度で持つ、フルマネージドかつ自動の継続的なテーブルデータバックアップを提供」します。ウィンドウはRecoveryPeriodInDaysで1〜35日に設定でき、その範囲内の任意の秒へ — 別のリージョンを含めて — リストアできます。

重要なエッジケースが1つあります。リカバリ期間を短縮すると、即座に最も古いリストアポイントが減少し、PITRを無効化してから再度有効化すると、リカバリ可能な開始時刻がリセットされます — それまでの継続的な履歴は失われます。

オンデマンドバックアップは別物です。明示的に作成し無期限に保持する、手動のフルテーブルスナップショットで、マイグレーション前のチェックポイントや、35日のPITRウィンドウを超える長期的なコンプライアンスアーカイブに役立ちます。

どちらも既存のテーブルに上書きするのではなく、新しいテーブルへリストアします:

実例:不正なマイグレーションからのリカバリ

expiresAt属性を追加するはずだったマイグレーションが、代わりにすべてのイベントのactionを空文字列で上書きしてしまいました。PITRは35日のウィンドウで有効になっているので、マイグレーションが実行された直前の秒へリストアします:

リストアを検証する間、破損したテーブルは手つかずのまま残ります — リストアしたイベントをライブのものと比較し、actionの値が戻っていることを確認してから、アプリを向け直します。リカバリそのものでは何も破壊されません。

損失がテーブル全体の破損ではなく数件のアイテムだけであれば、代わりにライブデータとリストアしたコピーを調べて、影響を受けた行だけをコピーすることもできます — DynamoDBテーブルのコピーを参照してください。

DynoTableでの実践

リストアはその検証の質によってのみ価値が決まります。audit-log-restoredへリストアした後は、実際にリカバリされたイベントを確認し、ミスの前にあるべきだった状態と一致することを確かめる必要があります。

DynoTableは他のテーブルと同様にリストアされたテーブルへ接続するので、影響を受けたテナントのイベントをクエリし、actionの値が正しいことを確認し、切り替え前にライブテーブルと比較できます — リストアを信頼の飛躍から検証済みのリカバリへと変えます。

オフラインのコンプライアンス記録のためにリカバリされたイベントをエクスポートすることもできます — DynamoDBをCSVにエクスポートを参照してください。

落とし穴と次のステップ

• PITRは必要になる前に有効化してください。 有効化した瞬間からしか保護されません — さかのぼってのリカバリはできません。失っては困るデータを持つテーブルでは有効にしておきましょう。
• PITRを無効化するとウィンドウがリセットされます。 オフにしてから再度オンにすると継続的な履歴が消去され、リカバリ可能な開始時刻は再有効化の時点から再び始まります。
• リストアは即時でも無料でもありません。 リストアはまったく新しいテーブルをプロビジョニングし、サイズに比例した時間がかかります。所要時間と追加のテーブルを見込んでおきましょう。
• 35日はアーカイブではありません。 PITRウィンドウを超える保持には、オンデマンドバックアップを取得するかS3へエクスポートしてください — PITRはリカバリウィンドウであり、長期ストレージではありません。

これで監査ログの運用ループが完結します。整合性のためのトランザクション、反応のためのStreams、有効期限のためのTTL、コストのための適切なキャパシティモード、リージョン耐障害性のためのglobal tables、そしてデータリカバリのためのPITR。それらがどう組み合わさるかは運用とコストの概要で再確認してください。

リストアされたテーブルに接続し、信頼する前にリカバリを検証するには、DynoTableをダウンロードしてください。