Aurora のクラスタで、30分毎にスナップショットを取っていました。今はやめています。
きっかけは障害でも請求でもありません。運用しながらバックアップの仕様を読み直したことです。読んで分かったのは、その30分毎が守っているつもりだったものを Aurora はすでに別の仕組みで持っていて、しかも私が取っていたスナップショットは、RDS 時代のつもりでいたものと課金も挙動も違うということでした。
そのとき読んだ箇所を、以下に並べます。数字と仕様はすべて AWS の公式ドキュメントから引いています。同じ運用をしている方は、リンク先で自分の目で確認してください。
30分毎が自然に見えていた理由
RDS (Aurora ではない通常の RDS) のスナップショットは、2回目以降が増分です。公式ドキュメントにこう書かれています。
The first snapshot of a DB instance contains the data for the full database. Subsequent snapshots of the same database are incremental, which means that only the data that has changed after your most recent snapshot is saved.
最初の1回だけが全量で、以降は前回からの変更分だけが保存されます。この前提なら、頻度を上げても保存量は変更量に比例して増えるだけです。30分毎に取るという判断は、それほど贅沢な設定ではありません。
私はこの感覚のまま Aurora を使っていました。移行してからも設定を見直さず、同じ頻度を持ち込んでいたわけです。設定画面の項目名が同じだったので、疑う入口がありませんでした。
Aurora では前提が2つ変わっています
自動バックアップが継続的に動いている
Aurora のバックアップ概要には、こう書かれています。
Aurora automated backups are continuous and incremental, so you can quickly restore to any point within the backup retention period. No performance impact or interruption of database service occurs as backup data is being written.
継続的かつ増分で、書き込み中の性能影響もありません。そして押さえておきたいのが、この自動バックアップを無効化できないことです。
You can't disable automated backups on Aurora. The backup retention period for Aurora is managed by the DB cluster.
保持期間は 1〜35日の範囲で指定します。既定値は1日です。
復元できる最新の時点は latest restorable time と呼ばれ、稼働中のクラスタでは現在時刻からおよそ5分前です。
The latest restorable time for a DB cluster is the most recent point to which you can restore your DB cluster. This is typically within 5 minutes of the current time for an active DB cluster.
自分のクラスタの値は CLI で確認できます。
aws rds describe-db-clusters \
--db-cluster-identifier my-cluster \
--query 'DBClusters[0].[LatestRestorableTime,EarliestRestorableTime,BackupRetentionPeriod]'
この3つの値が、そのクラスタで「いつからいつまで、どこにでも戻れるか」を表しています。
手動スナップショットが毎回フルバックアップになる
ここが私の誤解の中心でした。バックアップストレージの解説にこうあります。
DB cluster snapshots are always full backups that capture the size of the cluster volume when you create them.
CloudWatch メトリクスの説明では、さらに短く書かれています。
Snapshots are full backups, not incremental.
RDS のスナップショットは増分でした。Aurora のクラスタスナップショットは、取るたびにクラスタボリューム全量です。同じ「スナップショット」という名前で、課金の計算がまったく違います。
そして期限がありません。
Manual snapshots don't expire until you delete them.
30分毎を当てはめると、3つの数字が出てきます
1日48個、上限100に約2日
Aurora のクォータ表で、手動 DB クラスタスナップショットの既定上限は1リージョンあたり100個です (調整可能)。
30分毎なら1日48個です。2日ちょっとで既定の上限に届きます。古いものを消す運用が同時に回っていなければ、スナップショット作成が失敗し始めます。私の場合は世代数を決めて消していたので上限には当たりませんでしたが、当たらなかったのは消していたからであって、頻度が妥当だったからではありませんでした。
なお AWS Backup が取ったスナップショットは手動扱いですが、このクォータには数えられません。
保持期間を超えた瞬間から、フルサイズで課金が始まる
保持期間の内側にあるスナップショットは無料です。
Aurora provides unlimited free storage for snapshots within the automated backup retention period. After a manual snapshot is outside this period, it incurs charges per GB-month.
既定の保持期間は1日です。設定を触っていなければ、30分毎に取ったスナップショットは翌日から順に課金対象に入ります。しかも増分ではないので、1個あたり取得時点のクラスタボリューム全量として数えられます。
クラスタを消したときの記述も、読んでおく価値があります。
When you delete your DB cluster, the manual snapshots that you previously took continue to exist. If these snapshots previously weren't being billed because they were within the automated backup retention period, now they're not covered anymore and all start to be billed at their full size for their usage.
クラスタを削除すると、保持期間に守られていた分がまとめて課金対象になります。クラスタを消したのに請求が残る経路がここにあります。
復元点としては、PITR より6倍粗い
30分毎のスナップショットで戻れるのは、最悪の場合で30分前の状態です。同じクラスタの PITR は、公式が typically と断ったうえでおよそ5分前としています。しかも保持期間の中であれば任意の時点を指定できます。ここで比べているのは、どこまで細かく戻れるかです。復元にかかる時間の話ではありません。
公式が名指しで書いています
冒頭で引いたバックアップ概要のページに、この一文があります。
Because Aurora backups are continuous and incremental during the backup retention period, you don't need to take frequent snapshots of your data to improve restore times.
復元時間を短くする目的で頻繁にスナップショットを取る必要はない、と AWS 自身が書いています。私が30分毎に取っていた理由は、まさにこの「早く戻せるように」でした。早く戻すために増やしていたものが、戻れる時点をかえって粗くしていたわけです。
では、いつ取るのか
ここで「スナップショットは要らない」と結論するのは行き過ぎでした。手動スナップショットのほうが向いている場面が残っています。ドキュメントから読み取れる用途は4つです。
| 用途 | なぜスナップショットが要るか |
|---|---|
| 保持期間を超える長期保存 | 自動バックアップは最長35日で期限が来る。手動スナップショットは消すまで残る |
| アップグレードや大きな変更の前 | 保持期間内なら PITR でも戻せる。期限に縛られない固定点がほしいときは手動 |
| 別リージョンへの複製 | Aurora は自動バックアップのクロスリージョン自動複製に対応していない。手動でスナップショットをコピーする |
| クラスタ削除後に長く残したい場合 | 削除時に自動バックアップを保持する設定はあるが、それも保持期間で期限が来る。期限が来ないのは手動スナップショットと最終スナップショットだけ |
並べて気づいたのは、どれも頻度で決まっていないことでした。長期保存の間隔は、どこまで戻れれば足りるかと保持の要件から決まります。アップグレード前のロールバックポイントは、出来事が起きたときに取るものです。時計に合わせて30分毎に刻む理由は、この4つのどこからも出てきません。
Aurora では、頻度側の役割を自動バックアップと PITR がすでに引き受けています。手動スナップショットに残っているのは、時間の細かさでは代えられない用途のほうでした。
まとめ
- RDS のスナップショットは2回目以降が増分。Aurora のクラスタスナップショットは毎回フルバックアップになる
- Aurora の自動バックアップは継続的・増分で、無効化できない。保持期間の既定は1日
- PITR では、稼働中のクラスタでおよそ5分前まで戻れる
- 手動スナップショットの既定上限は1リージョン100個。30分毎なら2日ちょっとで届く
- 保持期間の外に出たスナップショットは、フルサイズで GB-month 課金される
- クラスタを削除すると、保持期間に守られていた分がまとめて課金対象になる
- 手動スナップショットが向く用途は4つあるが、どれも頻度では決まらない
私が30分毎を設定したとき、Aurora のドキュメントは1行も読んでいませんでした。RDS で覚えた手つきがそのまま指に残っていて、移行のときに設定画面だけを見て同じ数字を入れています。
Aurora は RDS より高い金額を払って使うものです。そのぶんの性能と機能があるのに、私は中身を確かめないまま RDS の管理をそのまま延長していました。払っているぶんの性能は使えていませんでした。運用のほうが足を引っ張っていたからです。
まずは自分のクラスタで、保持期間と LatestRestorableTime と手動スナップショットの数を見るところからです。移行して終わりにせず、機能の追加と性能の確認を定期的に入れて、そのたびに運用を見直していきます。