RDS（Aurora MySQL）のCloudFormation管理とデータリカバリについて整理する

概要

クラウドのインフラを構築する際、AWSならCloudFormation、GCPならCloud Deployment Manager、AzureならAzure Reource Manager、もしくはTerraformなど、インフラをコード化（IaC: Infrastructure as Code）することが今や一般的だと思う。

どこまでIaC管理にするか、という議論については「可能な限りすべき」というのが個人的な見解だが（実際私の働くFastLabelという会社ではほぼ全てIaC化している）、AWSでのAurora MySQLデータベースの構築について、「IaC管理 × データリカバリ」を考えた際にかなり複雑だという印象を受けたので整理することにした。

結論

まずは結論から。データリカバリのユースケースは下記とする。

1. 過去の特定時点にデータ全体を戻す
2. 特定のデータのみを過去の特定時点に戻す

手段	ユースケース1への対応方法	ユースケース2への対応方法
スナップショット	CloudFormationでSnapshotIdentifierプロパティを変更してスタック更新する	AWS ConsoleまたはCLIで複製して元のDBにデータを移行する
ポイントインタイムリカバリ	おすすめしない（AWS ConsoleまたはCLIで複製して切り替えると元のスタックの管理対象から外れるため）	AWS ConsoleまたはCLIで複製して元のDBにデータを移行する
バックトラック	AWS ConsoleまたはCLIから巻き戻す	不可

太字が各ユースケースへのおすすめの対応方法だ。

データリカバリの方法とユースケース

結論だけだとなんのこっちゃという感じなので、まずはAurora MySQLにおけるリカバリの言葉の意味とAWSが提供する手段、ユースケースについて整理する。

リカバリとは
リカバリとは、正常に稼働できる状態にデータを復旧させること。似たような言葉にリストア（復元ともいう）があるが、スナップショットからDBクラスターを複製して別に構築することを指す。リストアのみでリカバリするケースもあるため、ここでは便宜上必要な時以外はリカバリという言葉にまとめる。

厳密な違いはこちらの記事で確認して欲しい。
RDSのバックアップ・スナップショット・リストア・リカバリを理解する

リカバリ方法
Aurora MySQLのデータリカバリ方法には以下の3種類が用意されている。

1. スナップショット
2. ポイントインタイムリカバリ（最大35日間）
3. バックトラック（最大72時間）

これらの違いについてはこちらの記事がわかりやすい。

リカバリのユースケース
結論に既に挙げたが、データのリカバリのユースケースは2つある。

1. 過去の特定時点にデータ全体を戻す
2. 特定のデータのみを過去の特定時点に戻す

「1.」をめちゃくちゃ簡単にできるようにしたのがバックトラックという機能で、最大72時間で設定でき、設定の範囲内ならリストア不要で迅速にデータを巻き戻せる。スナップショット、ポイントインタイムリカバリでも可能（最大35日間分巻き戻せる）だが、「特定時点のDBクラスターを複製し、新しいDBクラスターをまるっと作ってそちらに切り替える」というリストアの手順が必要で時間がかかる。

だがほとんどのユースケースは、「2.」の特定のデータのみを元のデータに戻したいというものだろう。こちらに関しては、バックトラックでは対応できず、スナップショット、またはポイントインタイムリカバリを用いることになる。

因みに「2.」の実現方法としては、「以前のデータ状態を複製し、必要なデータをSQLなどで抽出して今動いているDBのデータを更新する」といったやり方がある。

CloudFormation管理時の各ユースケースへの対応方法

CloudFormationを使うとデータベースをスタックで管理できて再構築や別環境で新たに構築する際に楽になるというのは言わずもがなであるが、リカバリを考えた時に手段に種類が多く複雑化するので整理する。

1. 過去の特定時点にデータ全体を戻す

スナップショットによるリカバリ
最初のデータベースをCloudFormationで作った場合にスナップショットでどのようにデータ全体を巻き戻すかを考える。ありがたいことに、CloudFormationにはスナップショットID（SnapshotIdentifierプロパティ）を指定してスタックを更新する機能が備わっている。

内部的な処理としては、現状のDBクラスターが削除され、指定したスナップショットIDのDBクラスターが新しく生成される。スナップショットなので、最大35日間巻き戻せるのもメリットの1つとなる。

ポイントインタイムリカバリによるリカバリ
残念ながら、 2021/03/27時点でCloudFormationはポイントインタイムリカバリをサポートしていない。ポイントインタイムリカバリを使いたい場合は、AWS ConsoleやCLIでDBクラスターを複製し、そちらに向き先を切り替える必要があるが、これもスタック管理の点からおすすめできない。

スタックで管理しているのはあくまで元々あったDBクラスターであり、新しく作られたものに関しては管理対象から外れてしまうため、IaCの恩恵を自ら手放してしまうことになる。

バックトラックによるリカバリ
こちらはとても簡単で、AWS ConsoleでぽちぽちするかCLIでシュッと対応できる。こちらの記事にバックトラックをやってみた手順が書かれている。簡単なのでこちらの方法が最もおすすめだ。

2. 特定のデータのみを過去の特定時点に戻す

スナップショットによるリカバリ
AWS ConsoleまたはCLIでDBクラスターを複製し、元のDBに複製したテーブルのデータを移行する。元々スタック管理されていたDBをそのまま使うのでIaCの観点からも問題ない。

ポイントインタイムリカバリによるリカバリ
スナップショットによる復元とほぼ同じだが、自動バックアップを設定しておくことでスナップショットを自分で取らなくて良い上に、時間もより細かい単位で指定できるので、上記のやり方の上位互換と言える。

バックトラックによるリカバリ
データベース全体を巻き戻す処理なのでこのユースケースには対応できない。

因みに

2021/04/02時点で、AWS CDKはバックトラックをサポートしていない。CDK大好き人間としては残念でならないが、ここだけCloudFormation化するのも嫌だったので一旦CLIで対応している。

AWS CDKがver2などで対応したら上のやり方に変更するつもりだ。

まとめ

最後にもう一度まとめておく。太字がおすすめのリカバリ方法。

ユースケース

1. 過去の特定時点にデータ全体を戻す
2. 特定のデータのみを過去の特定時点に戻す

手段	ユースケース1への対応方法	ユースケース2への対応方法
スナップショット	CloudFormationでSnapshotIdentifierプロパティを変更してスタック更新する	AWS ConsoleまたはCLIで複製して元のDBにデータを移行する
ポイントインタイムリカバリ	おすすめしない（AWS ConsoleまたはCLIで複製して切り替えると元のスタックの管理対象から外れるため）	AWS ConsoleまたはCLIで複製して元のDBにデータを移行する
バックトラック	AWS ConsoleまたはCLIから巻き戻す	不可