トップ > Amazon RDS > Amazon Aurora のストレージに関連するメトリクスを理解する

Amazon Aurora のストレージに関連するメトリクスを理解する

Amazon RDS
記事タイトルとURLをコピーする

CI部 佐竹です。
本日は Aurora のストレージについて、特に運用目線で知っておく必要がある CloudWatch メトリクスを解説します。

はじめに

Amazon RDS、Amazon Aurora におけるコンピュートリソースの利用状況は、特に何も設定をしなくとも CloudWatch に連携されており、メトリクスとして表示が可能です。例えば CPUUtilization などもその1つです。

今回は、その中でも特に運用上確認しておくことが重要なストレージに関するメトリクスについて解説を行います。

Aurora のストレージの種類について

本内容を理解頂くために、予め説明させて頂きたいのが Aurora の持つ2種類のストレージについてです。

  1. ローカルストレージ
  2. クラスターボリューム

ローカルストレージ

EC2 インスタンスで例えるところのインスタンスストアボリューム（Ephemeral Disk）に相当します。本ストレージのサイズは DB インスタンスクラスに依存します。つまり、ストレージサイズを任意に増加させることはできず DB インスタンスクラス をスケールアップさせることで容量の変更が可能となっています。Aurora MySQL においては、本ストレージはエラーログ、一般ログ、スロークエリログ、監査ログ、や InnoDB 以外の一時テーブルの保存に使用されます。なお、本ストレージは「一時ストレージ（Temporary storage）」と記載されている場合もあります。

DB インスタンスクラス別のローカルストレージサイズは以下の通りです。

DB Instance Class Local Storage Size(GiB)
db.r6g.16xlarge 1008
db.r6g.12xlarge 756
db.r6g.8xlarge 504
db.r6g.4xlarge 252
db.r6g.2xlarge 126
db.r6g.xlarge 63
db.r6g.large 32
db.r5.24xlarge 1500
db.r5.12xlarge 748
db.r5.4xlarge 249
db.r5.2xlarge 124
db.r5.xlarge 62
db.r5.large 31
db.r4.16xlarge 960
db.r4.8xlarge 480
db.r4.4xlarge 240
db.r4.2xlarge 120
db.r4.xlarge 60
db.r4.large 30
db.t3.large 16
db.t3.medium 7.5

クラスターボリューム

永続的にデータを保存するためのストレージです。このストレージは自動的に増加するのが Aurora の特徴です。増加は最大 128TiB までとなっています。元々は 64TiB までの提供でしたが、2020年9月のアップデートにより 128TiB へと拡張されました。ただし、古い Aurora バージョンの DB インスタンスでは最大が 64TiB のままとなります。

128TB のサポートは、MySQL 5.6 と互換性のある Aurora MySQL エンジンバージョン 1.23、MySQL 5.7 と互換性のあるエンジンバージョン 2.09、および Aurora PostgreSQL 9.6.17、10.12、11.7 でご使用いただけます。

CloudWatch メトリクス

今回解説するのは3つのメトリクスになります。

  1. FreeLocalStorage
  2. VolumeBytesUsed
  3. AuroraVolumeBytesLeftTotal

なお、全般的な注意事項なのですが CloudWatch メトリクスは表示が Byte 表示になっています。例えば、31 GiB は 2^30*31 = 33285996544 Byte になりますので、表示が 33 GB となります。そのため表示にズレがあるように見えるのですが、これは GiB (ギビバイト) と GB (ギガバイト) の差になります。

FreeLocalStorage

ローカルストレージの空き容量を示すメトリクスです。本ストレージは先に記載した通り、自動的に拡張されません。よって、監視が必要な場合があります。もし、ローカルストレージが不足した場合は、以下の公式ドキュメントに記載がある通りのエラーが発生し、処理が継続できない状態に陥る可能性があります。

docs.aws.amazon.com

  • Amazon Aurora MySQL:

ERROR 3 (HY000): Error writing file '/rdsdbdata/tmp/XXXXXXXX' (Errcode: 28 - No space left on device)

  • Amazon Aurora PostgreSQL:

ERROR: could not write block XXXXXXXX of temporary file: No space left on device.

このため、本メトリクスの監視（管理）は Aurora の活用において重要です。

VolumeBytesUsed

クラスターボリュームの容量を示すメトリクスです。本メトリクスには Aurora DB クラスターが実際に利用しているストレージ容量が表示されます。VolumeBytesUsed はストレージの利用料に直結します。

東京リージョンの場合、ストレージ料金は「0.12USD/1GB (月額)」となっています。例えば 100 GB の容量を確保している場合は月額が $12.00 の請求となります。本利用料は月額利用料で固定されており、その月の日数により変動しません。

また、AWS の公式 FAQ には以下の記載があります。

Q: Amazon Aurora データベースのストレージの下限と上限はどれくらいですか?

ストレージの下限は 10 GB です。データベースの使用量に応じて、Amazon Aurora ストレージは 10 GB 単位で最大 128 TB まで、データベースのパフォーマンスに影響を与えずに拡張されます。ストレージを事前にプロビジョニングする必要はありません。

これは、10 GB 単位で増加するため、Aurora のストレージ料金は最低 0.12 * 10 = $1.2 の支払いが発生するということではありません。Aurora の利用料は VolumeBytesUsed によって定められます。つまり、利用料が 10 MB のように 10 GB に満たない場合は $0.12 * 0.01 = $0.0012 のみの請求になります。

関連して、Dynamic Resizing についても記載します。2021年頃より、以下のブログ記事に記載した Dynamic Resizing が東京リージョンにも適用されています。どういうことかと申しますと、DROP TABLE、DROP DATABASE、TRUNCATETABLE などの SQL ステートメントを実行した場合に billed space つまり VolumeBytesUsed も減少します。

blog.serverworks.co.jp

Dynamic Resizing は対応している Aurora バージョンがありますため、バージョンに注意ください。加えて、DELETE ステートメントでは有効ではありません。DELETE の場合は追って OPTIMIZE TABLE を実行する必要があります。

AuroraVolumeBytesLeftTotal

クラスターボリュームの確保可能容量の残量を示すメトリクスです。現在 Aurora は最大 128 TiB までクラスターボリュームが自動的に増加するため、例えば 1 TiB の容量を（VolumeBytesUsed で）確保している Aurora DB クラスターでは、AuroraVolumeBytesLeftTotal が 127 TiB と表示されます。VolumeBytesUsed が増加するのに合わせて減少するメトリクスになります。

ただし、古いバージョン (128 TiB が確保できないバージョン) の Aurora では、AuroraVolumeBytesLeftTotal の最大は 64 TiB になる点には留意ください。

f:id:swx-satake:20210707194716p:plain
古いバージョンの Aurora は AuroraVolumeBytesLeftTotal の最大は 64 TiB

なお、注意点としては、本メトリクスは Aurora MySQL 専用です。現時点で Aurora PostgreSQL では確認できません。加えてこのメトリクスにもバージョンの制約があり、AuroraVolumeBytesLeftTotal メトリクスは、Aurora バージョン 1.19.5 以降、および Aurora バージョン 2.04.5 以降でのみ使用できるようになっています。

本メトリクスについては以下のドキュメントに記載があります。

aws.amazon.com

まとめ

今回のブログでは、Aurora の2種類のストレージの差について記載しながら、以下の3つの CloudWatch メトリクスについて深堀しました。

  1. FreeLocalStorage
  2. VolumeBytesUsed
  3. AuroraVolumeBytesLeftTotal

運用時のエラーや対応においては FreeLocalStorage の監視が重要であり、ストレージの利用料は VolumeBytesUsed が重要です。また AuroraVolumeBytesLeftTotal は最大 128 TiB と非常に大きなサイズではありますが、場合によっては監視すべき項目になります。

Aurora のストレージに関するメトリクスについて、詳しく知りたい方の参考になれば幸いです。

ではまたお会いしましょう。

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。