Amazon Aurora の dynamic resizing について

SRE部佐竹です。
本日は Amazon Aurora のちょっとした更新について記載します。

はじめに
dynamic resizing
Managing performance and scaling for Aurora DB clusters
- Storage scaling
まとめ
- 2021年3月5日更新

はじめに

以下の Backtrack の動作検証ブログでも記載しているのですが、Amazon Aurora の仕様は クラスターからデータを削除しても、クラスターボリュームのストレージは縮小しません。 でした。

blog.serverworks.co.jp

今回の更新により上記仕様が変更となっています。

つまり、クラスターからデータを削除した結果、クラスターボリュームのストレージが縮小されるようになります。

dynamic resizing

「Auroraのユーザガイド」の更新に、2020年10月13日 Amazon Aurora supports dynamic resizing for the cluster volume という表記が追加されました。

英文だけ読むと「Amazon Auroraは、クラスターボリュームの動的なサイズ変更をサポートするようになりました」であり、今まで通りのように見えます。

この更新の内容は、Description に Aurora reduces the size of the cluster volume after you remove data through operations such as DROP TABLE. と記載がある通りで「DROP TABLE 等の操作でデータ削除を実行した場合、その後 Aurora はクラスターボリュームのサイズを縮小します」と、縮小の機能が追加されました。詳細は以下のドキュメントに記載があります。

docs.aws.amazon.com

Managing performance and scaling for Aurora DB clusters

Storage scaling

先に紹介したドキュメントがまだ日本語化されておりませんため、一部翻訳してお知らせします。なお、以下で記載されているクラスターボリュームとは、CloudWatch で示される VolumeBytesUsed に相当します。

Aurora のデータがクラスターボリュームから削除されると、全体の請求対象となる範囲（billed space）は同等量減少します。この動的なサイズ変更（dynamic resizing）の動作は、基になるデータベースファイルが削除または再編成され必要なスペースが以前より少なくなると発生します。そのため、不要になったテーブル、インデックス、データベース等を削除することでストレージ料金を削減することができます。dynamic resizing は、特定のAuroraバージョンに適用されます。以下は、データを削除するとクラスターボリュームが動的にサイズ変更されるAuroraの最低バージョンです（この機能を利用したい場合は、記載されているバージョン以上である必要があります）。

Aurora MySQL 2.09 (compatible with MySQL 5.7)

Aurora MySQL 1.23 (compatible with MySQL 5.6)

Aurora PostgreSQL 3.3.0 (compatible with PostgreSQL 11.8)

Aurora PostgreSQL 2.6.0 (compatible with PostgreSQL 10.13)

上記リストよりも低いAuroraバージョンでは、クラスターボリュームは、データの削除時に解放されたスペースを再利用できますが、ボリュームそれ自体のサイズが減少することはありません。

この機能は、Auroraが利用可能なAWSリージョンに段階的にデプロイされています。クラスターが存在する地域によっては、この機能がまだ利用できない場合があります。

動的サイズ変更（dynamic resizing）は、クラスターボリューム内のデータファイルを物理的に削除またはサイズ変更する操作に適用されます。したがって、DROP TABLE、DROP DATABASE、TRUNCATETABLE などのSQLステートメントに適用されます。 DELETE ステートメントを使用した行削除には適用されません。テーブルから多数の行を削除したい場合は、Aurora MySQL OPTIMIZE TABLE ステートメントもしくは Aurora PostgreSQL VACUUM ステートメントを実行して、テーブルを再編成し、クラスターボリュームのサイズを動的に変更できます。

翻訳はここまでです。

まとめ

f:id:swx-satake:20200922003617p:plain:w150

本機能は、オンプレや on EC2 で利用されている MySQL でいうところの「Truncate だとデータベースファイルの物理ファイルの総量は減る」けども「Delete だと物理ファイルの総量は減らないので後から OPTIMIZE TABLE を実行する必要がある」という仕様が適切に Aurora の料金（VolumeBytesUsed の総量）にも反映されることになった、ということです。

データの削除で総量が元に戻らないため、代わりの機能として Backtrack が有効活用できるのではと考えて以前のブログを記載したのですが、この dynamic resizing が利用可能であれば料金にケアした Aurora の利用がよりお手軽にできるようになります。

注意点：上記翻訳にもありますが「段階的にデプロイ」と記載がある通り、この機能が有効なリージョンとそうではないリージョンがまだあるようです。この点は利用においてご留意ください。2020年10月26日現在、東京リージョンは未対応です。また対応スケジュールは現在公開されておりません。