[アップデート] Amazon Aurora でクラスターボリュームサイズの縮小が可能に！不要なデータ削除でコスト削減だ！

ドキュメントの更新情報からの共有ですが、Amazon Aurora でデータ削除によるクラスターボリューム（ストレージ）の縮小が可能になったようです！

以下、ドキュメント更新履歴からの情報です。

Amazon Aurora クラスターボリュームの縮小

ご存知のとおり Amazon Aurora のクラスターボリュームはデータ量に応じて動的に拡張されます。ボリュームサイズを指定する必要はありません。一方でボリュームサイズの縮小には対応していませんでした。（縮小は Aurora に限らず、他の RDS エンジンでも同じです）

例えば、一時的に大きなデータを格納するために 50 GB から 100 GB に拡張されたとします。その後、不要になったので 50 GB のデータを削除したとしても、拡張されたボリュームサイズは 50 GB に戻らず、100 GB のままになります。

具体的にいうと VolumeBytesUsed のメトリクス値は変わらないということです。VolumeBytesUsed の値は、Aurora のボリューム料金に影響します。つまりデータの利用量に関係なく、一度拡張された上限のボリュームサイズで課金が発生することになります。

どうしてもボリュームサイズを縮小したい場合、新規のクラスターを起動しデータを移行するなど非常に手間の掛かる作業となります。。

データ削除によるボリュームサイズの縮小

今回のアップデートで DROP TABLE、DROP DATABASE、TRUNCATE TABLEのような SQL ステートメントでデータ削除を行うことでボリュームサイズの縮小が可能になりました。

データ削除するだけでコスト削減効果がありますので、これは嬉しいアップデートですね！

注意点

ぬか喜びにならないよう、いくつかの注意点をお伝えしておきます。

• 以下のバージョン以降である必要があります。
  • Aurora MySQL 2.09
  • Aurora MySQL 1.23
  • Aurora PostgreSQL 3.3.0
  • Aurora PostgreSQL 2.6.0
• Aurora が使用可能なリージョンで段階的にデプロイされます。よって上記バージョンを利用しても、まだボリューム縮小されない場合があります。
• DELETE による行削除ではボリューム縮小されません。
  • 大量の行削除を行った場合は、MySQL 互換の場合は OPTIMIZE TABLE、PostgreSQL 互換の場合は VACUUM を実行し、テーブル再編成が必要です。
• テーブルがシステムテーブルスペースの一部である場合、テーブルを削除しても縮小されません。

やってみる

と、書きたいところでしたが東京リージョンおよびバージニアリージョンの Aurora MySQL 2.09 で DROP TABLE を試してみましたが執筆時点では、まだボリュームサイズは縮小されませんでした。。

「段階的にデプロイ」との記載がありますので、利用可能になり次第、更新します！

本日のところは、ひとまず「Amazon Aurora でボリュームサイズが縮小可能になるらしいよ！」という情報共有と、公式ガイド記載の実行例で御勘弁を！

実行例

以下の例は一時的なデータを含むテーブルを作成、削除した際の VolumeBytesUsed です。15 分間隔で最大値（2カラム目）と最小値（3カラム目）が表示されています。

$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id
  --output text | sort -k 4
VolumeBytesUsed
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T20:49:00+00:00	Bytes
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T21:19:00+00:00	Bytes
DATAPOINTS	22022176768.0 14545305600.0	2020-08-05T21:49:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:19:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:49:00+00:00	Bytes
DATAPOINTS	22022176768.0 15614263296.0	2020-08-05T23:19:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-05T23:49:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-06T00:19:00+00:00	Bytes

8行目に VolumeBytesUsed が 13.5 GB から 20.5 GB に拡張された後、11行目で 20.5 GB から 14.5 GB に縮小されているのが判りますね。

さいごに

一時的な利用によって拡張されたボリュームサイズに対して、データ削除後も料金を払い続けることは無駄なコストです。しかしながら、従来の仕組みでは容易に縮小は出来なかったため、作業の手間と無駄なコストを天秤にかけて判断されていたかと思います。

本日以降、対応エンジンバージョンにおいてはデータ削除によって簡単にボリューム縮小＝コスト削減が可能となりましたので、必要のないデータは積極的に削除いただくのが良さそうですね！

「非対応バージョンでデータ削除したものを、対応バージョンに引き上げたら縮小されるん？」

など、実機確認できるようになりましたら、いろいろ試してご紹介したいと思います！

以上！大阪オフィスの丸毛（@marumo1981）でした！