バックアップ、ポイントインタイム復元、ミスからの復旧
DSQLの復旧機能・時間・作業量は既存サービスとどう異なるか?
結果の要約
この実験では、運用者がデータを誤って変更した後、ミス以前の状態のデータを復元してアプリケーションが再び読めるようになるまでの手順と時間を、DSQL と Aurora Serverless v2(A2)で比較しました。最小範囲(MVP)として、約 100 MB のデータの上に1秒間隔のマーカー30個を書き、その後すべてのマーカーを -1 で上書きして新しい行を1つ挿入する「ミス」を起こし、各サービスの方法で復旧しました。
DSQL は任意の時刻に戻すポイントインタイム復元(PITR)をサポートしておらず、AWS Backup のフルバックアップから新しいクラスターに復元する方法しかありません。そのため、マーカーを書いた後、ミスの前にオンデマンドバックアップを取得しました。バックアップ(約 102 MB)に481秒かかり、このバックアップから新しいクラスターを作る復元ジョブは129秒でした。A2 はミス直前の時刻を指定してポイントインタイム復元し、復元されたクラスターの準備に223秒、インスタンスを追加して接続できるようになるまで587秒かかりました。
両方の復元先で、正常なマーカー30個とその合計が元と同じで、上書きされた行とミス後に挿入した行は0行でした。復元先への最初の接続には D1 343 ms、A2 291 ms かかりました。DSQL の復元は速かったものの、戻せる時点は「最後にバックアップを取得した時刻」に限られるため、バックアップ周期の間に生じた変更は失われます。
本番利用の観点
DSQL でもミスからの復旧は可能ですが、従来の Aurora のように「ミスの1秒前」に戻すポイントインタイム復元がないことが最大の違いです。復旧できる最新の状態は最後の AWS Backup 復旧ポイントなので、許容できるデータ損失時間(RPO)に合わせてバックアップ周期を決め、その費用を受け入れる必要があります。今回の小規模データではバックアップ8分、復元2分でしたが、バックアップは毎回フルバックアップのため、データが増えると時間と費用が増える可能性があります。復元は常に新しいクラスターに行われるため、アプリケーションの接続先と IAM 権限を新しいクラスターに切り替える手順も用意しておく必要があります。
確認する問い
DSQLの復旧機能・時間・作業量は既存サービスとどう異なるか?
実行条件
- リージョンと日時: ソウル(ap-northeast-2)、2026-09-29 09:24–09:47 UTC。
- 構成: D1 Aurora DSQL 単一リージョン、A2 Aurora PostgreSQL 16.15 Serverless v2(writer+reader、4–32 ACU)。データは E002 規模の2%(D1 のバックアップサイズ 101,940,777 bytes)。
- マーカーとミス: マーカーテーブル
mvp_markerに1秒間隔で30行を書き(09:24:12–09:24:42 UTC)、09:32:54 にすべての行をv = -1に変更し、id 100000 の行を挿入しました。 - D1 の手順: 専用のバックアップボールトと AWS Backup サービスロール(
AWSBackupServiceRolePolicyForBackup、...ForRestores)を作成し、マーカー後のオンデマンドバックアップ → ミス → 復旧ポイントからのstart-restore-job(削除保護を解除) → 新しいクラスターが ACTIVE → ランナーに新しいクラスターへの接続権限を付与 → 検証、の順に進めました。アカウントでは AWS Backup の DSQL 利用設定がすでに有効になっていました。 - A2 の手順: 復元可能な最新時刻が目標時刻を超えるまで待った後(0.2秒)、最後の正常なマーカーとミスの間の中間時刻で
restore-db-cluster-to-point-in-time→ クラスター available →db.serverlessインスタンス作成 → available → 検証。 - 検証: ランナーから復元先に新たに接続し、マーカー数、上書きされた行数、ミス後の行数、マーカーの合計、注文数を確認しました。
- 計画から変わった点： 方式・サイズごとの3回の繰り返し、7日間の保持ポリシー、通常負荷中の復元と SLO 回復の測定、スナップショット復元との比較、R1・A1 は実行しませんでした。
性能結果
| 構成 | 復旧方式 | バックアップ | 復元(要求→準備完了) | 最初の接続 | マーカー | 上書きされた行 | ミス後の行 |
|---|---|---|---|---|---|---|---|
| D1 | オンデマンドのフルバックアップ → 新しいクラスター | 481秒 | 129秒 | 343 ms | 30/30 | 0 | 0 |
| A2 | ポイントインタイム復元 → 新しいクラスター + インスタンス | 不要(継続的バックアップ) | 587秒(クラスター223秒) | 291 ms | 30/30 | 0 | 0 |
- 両方の復元先のマーカー合計(435)は元と同じでした。注文数は D1 282,772、A2 282,773 で、それぞれの元データで先行する試験が累積した分を反映した値です。
- D1 の復元時間にはバックアップ時間は含まれません。実際の事故ではバックアップがすでに存在している必要があるため、復旧可能な最新時点は最後のバックアップ時刻です。
開発・運用のしやすさ
- DSQL のバックアップ準備: AWS Backup のボールトとサービスロールが必要です。CLI ではデフォルトのボールトは自動では作成されません。存在しないボールトを照会すると
ResourceNotFoundではなくAccessDeniedExceptionが返るため、自動化コードでこれを「ボールトなし」として扱う必要がありました。 - DSQL の復元結果: 復元はデフォルトで削除保護が有効な新しいクラスターを作成します。メタデータ
regionalConfigで削除保護を無効にし、元のタグをコピーしました。新しいクラスターは識別子とエンドポイントが異なるため、IAM の接続権限を付与し直す必要がありました。 - Aurora のポイントインタイム復元: 復元 API は新しい管理パスワードのオプションを受け付けず、元のマスターパスワードをそのまま使います。クラスター復元後にインスタンスを別途作成しないと接続できません。
- 後片付け: バックアップジョブが終わる前にはボールトを削除できないため、実行中のバックアップジョブの完了を待ってから復旧ポイントとボールトを削除しました。
費用
実行 B 全体の費用は E009 レポートの費用の節にまとめています。この試験で追加で発生したリソースは、AWS Backup の復旧ポイント2つ(約 102 MB、数分間保管)、復元した D1 クラスター(約10分)、復元した A2 クラスターとインスタンス(約15分)です。
結論と限界
- 両サービスともミス以前のデータを正確に復元しました。DSQL は復元が速かったものの、ポイントインタイム復元がないため復旧時点がバックアップ周期に縛られます。
- 限界: 1回の実行、約 100 MB のデータです。バックアップ・復元の時間はデータサイズやサービスの状態によって変わる可能性があります。負荷中の復元とアプリケーションの切り替えまでを含めた全体の復旧時間は測定していません。
後片付けの記録
- 実行 B で作成したリソース: BATCH(VPC、サブネット2つ、IGW、セキュリティグループ2つ、DB サブネットグループ、ランナーの IAM ロール・インスタンスプロファイル)、D1 DSQL クラスター、A2 クラスターと writer・reader、RDS 管理シークレット、Spot ランナー2台(D1
c6g.4xlarge、A2m7g.4xlarge)。E007 で AWS Backup ボールト、バックアップサービスロール、復旧ポイント2つ、復元した DSQL クラスター1つ、ポイントインタイム復元した A2 クラスターとインスタンスを追加で作成しました。 - 削除: バックアップボールトと復旧ポイント2つは 09:35 UTC に、復元した DSQL クラスターと A2 の復元先は 09:48 UTC から約 10:05 UTC にかけて、所有タグを確認したうえで削除しました。残りは
e002.py batch-downで 10:04–10:20 UTC に削除しました。削除に失敗したリソースはありません。 - 検証(10:20:27 UTC):
e002.py verifyの結果はremaining_count=0です。手動のクロスチェックで AWS Backup ボールト0個、この実行の接頭辞を持つ RDS クラスター・IAM ロール0個、未処理の Spot リクエスト0件を確認しました。この時点で残っていた DSQL クラスター1つは、同時に実行中だった実行 A(E002・E003・E008・E012)のものです。