Amazon Aurora バックアップってややこしい

はじめに

概要

Amazon Auroraのバックアップからデータの復元までについて、色々と方法があるようでなんとなくの理解ではまずいと感じたのでまとめてみました。

全体像

バックアップの種類

バックアップ〜復元には3つの種類があります。

• バックトラック(Aurora MySQLのみ)
• ポイントインタイムリカバリ
• スナップショット

この3つをバックアップの要件に基づいて選んでいきます。
上から順にデータを保持しておく時間が短く、その分復元までの時間が早いです。
一旦、全体図を載せます。

Auroraの仕組み

各用語

バックアップの説明の前に簡単にAuroraの基本用語について理解していきます。

• クラスタボリューム
  データベースの中身。
  データを格納するところ。

• DBインスタンス
  データベースにデータと登録するやつ。
  データ読み書きをしてるやつ。

• DBクラスタ
  クラスタボリュームとDBインスタンスの集合体。
  DBクラスタの中にクラスタボリュームとDBインスタンスがある。

全体を図にするとこんな感じです。

なんとなくでもいいので、これを頭にいれておくと理解がしやすいです。

各バックアップ方法

バックトラック

まずはバックトラック機能です。
この機能はAurora MySQLのみで使用可能です、Aurora PostgreSQLでは使用できません。
この機能は、「復元」というよりは「巻き戻し」です。

データを巻き戻せるのは~72時間(3日間)までとなります。
マネジメントコンソールでデータベースを作成する場合は、バックトラックウィンドウという項目でデータの保持期間を入力します。
当然ですが、この保持期間が長くなるほどコストがかかります。

データと言いましたが、実際にバックトラックによる復元というのは変更レコードという変更の記録を元にデータベースの巻き戻しを行います。
そのため、データベースを新たに作り直す訳ではないため、復旧までが短時間で済みます。

アプリケーションの何かしらのプログラムのミス、トラブルによって
誤ってDROPやDELETEをしてしまった場合、アプリケーションに不具合が発生する可能性があります。
そんな時に、バックトラック機能を用いて、トラブルが発生する前の時点に巻き戻すことができます。

巻き戻しは、SQL文を逆から実行していくことで巻き戻すことができます。

Q.なんで逆から？
A.逆から戻していかないと、データの依存関係が壊れてデータベースの状態が不整合になる可能性があるから。

注意点

バックトラックが他の復元方法と大きく違うのは、バックトラックではデータベースを新たに生成するのではなく、既存のデータベースを「巻き戻す」点です。
これが意味するところは、既存のデータベースに操作を行うため、現在動作中のデータベースを一旦止める必要があります。
そのため、一時的にアプリケーションからの接続、読み書きを全て切る必要があります｡

ユースケース

• 開発者や管理者が誤ってデータを削除、更新した場合
• 新しいコードをデプロイまたはテストするときに問題が発生した場合
• アプリケーションのロジックによりデータベースに問題が発生した場合

などが一例として考えられます。
これらに共通するのは、現状のデータベースは問題があることがわかっているのでデータをすぐに元に戻したい！という点です

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

自動バックアップ

ポイントインタイムリカバリ(PITR)は使用条件としてAuroraの自動バックアップ機能をONにする必要があります。
そこで、まずは自動バックアップ機能についてみていきます。

自動バックアップはAuroraではデフォルトで有効になっており、無効にはできません。
バックアップは増分(変更された部分が増える)で取得されます。
保持期間は1~35日で35日以上のバックアップが必要な場合はスナップショットが必要です。
図にするとこんな感じです

PITR

PITRはこの自動バックアップを用いて任意の時点を復元することができる機能です。
最短で5分前~35日前まで遡ることができます。
PITRはバックアップデータの容量次第で復元の時間が変わります。
基本的にはバックトラックより速いということはありません。

注意点

PITRではバックアップされたDBクラスタを丸ごと復元するので、元のDBクラスタとは別に新しいDBクラスタが生成されます。
もちろんコストは新しいDBクラスターの分が追加で必要になります。

ユースケース

• 元のDBクラスタを残した状態で復元を行いたい場合
• 開発者や管理者が誤ってデータを削除、更新した場合
• 新しいコードをデプロイまたはテストするときに問題が発生した場合
• アプリケーションのロジックによりデータベースに問題が発生した場合

あれ？ほとんどバックトラックと一緒？と思いました。
色々と調べてみましたが、この辺はシステムの要件が影響するのであまり参考になる情報がありませんでした。
例えば早急な復旧が必要であれあバックトラックを使えばいいし
元のデータを残して復旧と同時にデータのバグ解析がしたいのであればPITR
といったような感じだと考察します。

スナップショット

自動バックアップとは異なり、スナップショットは手動で取ります。
特徴としては、スナップショットは保持期間に制限がないことです。
長期間のバックアップ等の場合はS3にエクスポートすることが推奨されています。
図にするとこんな感じです

スナップショットも自動バックアップと同様にDBクラスタを丸ごとバックアップするため
復元する際は新しいDBクラスタが生成されます。

ユースケース

• データベースのバージョン管理
• 長期のバックアップ
• 災害復旧
• データ移行

などがあげられます。

まとめ

最後にそれぞれの違いを簡単に表にまとめました

	バックトラック	ポイントインタイムリカバリ (PITR)	スナップショット
機能	特定の時間までデータベースを巻き戻す	特定の時点のデータベースを復元	データベースの全体的なバックアップ
復元速度	高速	中速	低速
ストレージコスト	高め	普通	低め
使用シーン	操作ミスの取り消し	大規模なデータ復旧	長期バックアップ

バックアップは色々な種類があってややこしいですが、データベースを使ったシステム構築では必ず必要になります。
システムにあったバックアップ戦略をとる必要があります。

所感

バックアップの種類を調べるにあたってDBクラスタの勉強にもなりました。
バックトラックとPITRのユースケースがいまいち分からなかったので、どこかで詳しい人に聞いてみようと思います。

参考資料
Aurora DB クラスターのバックトラック
Amazon Aurora DB クラスター
Aurora DB クラスターのバックアップと復元の概要
Amazon RDS のバックアップと復元
DB クラスタースナップショットの作成