SRE部 佐竹です。
本日はAurora MySQL の Backtrack でストレージの総量も合わせて戻るのか検証してみます。
はじめに
Aurora MySQL の Backtrack は、データベースの時を巻き戻すことができる機能です。
Point-in-time recovery (PITR) はデータを巻き戻せるものの「新規の（別の） RDS DB.Instance」で復元される機能ですが、Aurora の Backtrack は同じ Aurora DB Cluster のままデータを巻き戻す機能であり、2020年9月現在は Aurora MySQL でのみ実装されています。
今回は、そのBacktrackの機能を利用して、データの総量も巻き戻ってくれるのか検証します。
Aurora の仕様について
まずは前提として Amazon Aurora の仕様について認識を合わせましょう。
Amazon Aurora は「Amazon Aurora ストレージと信頼性」で説明されている通り、以下の通りのストレージ特性を持っています。
Aurora クラスターボリュームは 128 TiB まで拡大できますが、Aurora クラスターボリュームで使用する領域に対してのみ料金が請求されます。テーブルまたはパーティションの削除などによって Aurora データが削除されても、全体の割り当て領域は同じままです。空き領域は、将来のデータボリューム増加時に自動的に再利用されます。
ストレージコストは「"高いウォーターマーク"」 (任意の時点で Aurora クラスター用に割り当てられた最大量) に基づいているため、大量の一時情報を作成したり、古い不要データの削除前に新規データを大量にロードする ETL 実行を避けることによってコストを管理できます。
また、合わせて以下のナレッジセンターの記事を確認します。
本記事には以下の点が言及されています。
重要: クラスターからデータを削除しても、クラスターボリュームのストレージは縮小しません。たとえば、テーブルまたはパーティションを削除しても、割り当てられた容量は同じままです。割り当てられたストレージの容量に対し、引き続き課金されます。クラスター内の未使用スペースを再利用するには、新しいクラスターを作成し、そのクラスターにデータをエクスポートしてから、元のクラスターを削除します。
つまり、Aurora には以下の特徴があります。
- ストレージサイズは使用容量に応じて自動的に増加し、最大128 TiBまで増加する
- 一度拡大されたストレージの最大容量（ウォーターマーク）をデータの削除によって下げることはできない
- ストレージの最大容量（ウォーターマーク）を下げたい場合は、新規の Aurora DB Cluster を作成してデータを移行する必要がある
2020年10月19日追記
本仕様ですが、2020年10月13日から仕様が変更されたため以下の記事で補足しております。合わせてご確認ください。
Backtrack の仕様について
合わせて Backtrack の仕様について確認します。「公式ドキュメント」より重要な点を抜粋します。
バックトラックは、バックトラック機能を有効にして作成した DB クラスターでのみ使用できます。バックトラック機能は、新しい DB クラスターの作成時または DB クラスターのスナップショットの復元時に有効化できます。
バックトトラックウィンドウの上限は 72 時間です。
Backtrack を実行するには、Aurora DB Cluster 作成時に「Backtrack Window」有効にする必要があり、また時を巻き戻せるのは72時間が最大です。
素朴な疑問
ここまでに確認した Aurora DB Cluster のストレージに関する仕様を前提に、Backtrack の機能についても考えてみますと、1つの疑問がわいてきます。それは「Backtrack を使うと、AWS利用料（ウォーターマーク）も元の額に戻ってくれるのだろうか？」という疑問です。
今回はこれを検証してみました。ただし、もう1つ先に説明が必要な事項があります。
Aurora のストレージ使用量を確認する方法
Aurora のストレージ使用量を確認方法は以下のナレッジセンターの通りになりますが、CloudWatch のメトリクスである VolumeBytesUsed がその値になります。これを CloudWatch のコンソールから確認することで、実際に Aurora の Backtrackの機能によってウォーターマークが下がったのか確認することが可能です。
検証作業
検証のために、Backtrack Window が有効になった Aurora DB Cluster を上図の通り1台用意します。この Aurora に対して、ひたすらデータをインポートしていきます。今回はストレージ容量を増やすためにサンプルデータを「こちら」から拝借しました。このサンプルデータは1回のインポートで157.5MBほどになります。
このデータを利用して、ひたすら Aurora にデータをインポートしていきます。
上図の通り、 VolumeBytesUsed によるとデータが 9 GB ほどインポートされました。Aurora の下限ストレージは以下で引用する「FAQ」にあるように 10 GB です。そのため、10 GBを超えるまでデータをインポートしてみます。
Q: Amazon Aurora データベースのストレージの下限と上限はどれくらいですか?
ストレージの下限は 10 GB です。データベースの使用量に応じて、Amazon Aurora ストレージは 10 GB 単位で最大 64 TB まで、データベースのパフォーマンスに影響を与えずに拡張されます。ストレージを事前にプロビジョニングする必要はありません。
以下の図の通り、10 GBを超えるデータのインポートが完了しました。
VolumeBytesUsed を確認すると、おおよそ 13 GB程度インポートされています。
この状態で、Aurora DB Cluster に対して Backtrack を実行します。
Backtrack の指定時間は、19:55 頃とします。
以下の図の通り、19:55 頃は13 GBまでウォーターマークが上昇していない時間帯です。
Backtrack の実行後、完了するまで待機します。
Backtrack でウォーターマークが引き下がる場合は、19:55頃の VolumeBytesUsed まで CloudWatch の値も合わせて戻ると想定されます。
結果
Backtrack が完了しますと、上図の VolumeBytesUsed の値の動き通り「ウォーターマークも引き下がる」ことがわかりました。
素晴らしいですね！私は実際に検証するまでは「ウォーターマークは戻らない」と思い込んでいましたが、実際はウォーターマークは Backtrack の機能によって指定時間の容量まで引き下げられました。
これは、実装の仕組みとして Backtrack の実行は「データの削除」にあたらないということになるのでしょう。
まとめ
本ブログでは Aurora MySQL の Backtrack でストレージの総量 VolumeBytesUsed も合わせて戻るのか検証してみました。結果的には最大容量は Backtrack の機能によって巻き戻ることがわかりました！Aurora は VolumeBytesUsed の容量で請求されるため利用料も同時に巻き戻ることになりますね。
- 要点
- ストレージの総量
VolumeBytesUsedで Aurora はストレージの利用料が請求される - 一度拡大されたストレージの最大容量（つまり
VolumeBytesUsed）をデータの削除によって下げることはできない - ただし、Backtrack でストレージの総量
VolumeBytesUsedは元の値に戻る
- ストレージの総量
機能検証では「大量のデータが存在する場合に、当該の機能に速度遅延が発生することがないか」等を検証する場合もあります。そのような場合、検証が完了した後はそのインポートしたデータを全て消したいところですが、検証したトランザクションを鑑みて削除するのは至難の業です。
本来であれば検証前のバックアップdumpからデータを全て巻き戻したいところですが、手間がかかります。そこで Backtrack が有効ではないかと考えたのですが懸念は「ストレージの総量が同時に戻ってくれるのか？」でした。もしストレージの総量が下がらないのであれば、一度拡張されたストレージの容量に対して都度課金がされてしまいます。今回はそのようなシーンにおいて VolumeBytesUsed が Backtrack によって問題なく解消されるのか検証してみました。
これで 72時間以内であれば Backtrack を有効的に利用して大量データのインポート機能検証ができますね。
なお、本検証作業においてdumpを活用して大量にデータをインポートしましたが、以下の通り39億も change record が発生してしまい、思ったよりも請求額が高くなってしまいました。Backtrack を利用される場合はこの change record の増加にはお気を付けください。
本記事が何かの参考になれば幸いです。
それではまたお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
