はじめに

株式会社ジャパン・インフラ・ウェイマークの川邉です。当社はNTT西日本の子会社で、ドローン×画像解析AIを活用したインフラ点検を主に行っています。

本稿では、Amazon RDS の Aurora Serverless v2 の利用料削減のために調査した内容について記載しています。

対象読者

本記事が想定する対象読者は以下の通りです。

Amazon RDS の Aurora Serverless v2 を利用している
最近、RDSのコストが想定よりちょっと高いなと思っている

背景

筆者は画像解析AIの開発や実行環境としてAWSを利用しています。DBには Amazon RDS の Aurora Serverless v2 を利用しているのですが、モニタリングで各種リソースの消費状況を確認している中で、ServerlessDatabaseCapacityの値が想定ほど下がっていないことに気付きました。

DBサーバの情報

インスタンスタイプ：Serverless v2
エンジンバージョン：8.0.mysql_aurora.3.09.0
最小容量：0.5 ACU
最大容量：256 ACU

モニタリング

以下は、ほぼ使用していない状態でのCPUUtilization、FreeableMemory、ServerlessDatabaseCapacityのモニタリング結果です。

値の説明

公式ドキュメントでは、それぞれの値について以下のように説明しています。

CPUUtilization

このメトリクスは Aurora Serverless v2 において、プロビジョン済みの DB インスタンスとは異なる解釈がされます。Aurora Serverless v2 の場合、この値は、現在の CPU の使用量を DB クラスターの最大 ACU 値で使用可能な CPU 容量で割った割合です。Aurora はこの値を自動的にモニタリングし、DB インスタンスが CPU 容量を使用している割合が常に大きい場合、Aurora Serverless v2 DB インスタンスをスケールアップします。

このメトリクスが 100.0 値に近づいた場合、DB インスタンスは最大 CPU 容量に達しています。クラスターの最大 ACU 設定を引き上げることを検討してください。このメトリクスがリーダー DB インスタンスで 100.0 値に近づいた場合、クラスターにリーダー DB インスタンスを追加することを検討してください。これにより、ワークロードの読み取り専用部分のワークロードをより多くの DB インスタンスに分散することで、各リーダー DB インスタンスのロードを軽減できます。

FreeableMemory

この値は、Aurora Serverless v2 DB インスタンスを最大容量にスケーリングしたときに利用できる未使用のメモリ量を表します。現在の容量が最大容量を下回る各 ACU では、この値は約 2 GiB 増加します。したがって、DB インスタンスが限りなく大きくスケールアップされるまで、このメトリクスはゼロに近づきません。

このメトリクスが 0 値に近づいた場合、DB インスタンスは可能な限りスケールアップし、使用可能なメモリの上限に近づいています。クラスターの最大 ACU 設定を引き上げることを検討してください。このメトリクスがリーダー DB インスタンスで 0 値に近づいた場合、クラスターにリーダー DB インスタンスを追加することを検討してください。これにより、ワークロードの読み取り専用部分のワークロードをより多くの DB インスタンスに分散することで、各リーダー DB インスタンスのメモリ使用量を軽減できます。

ServerlessDatabaseCapacity

インスタンスレベルのメトリクスとして、現在の DB インスタンスの容量で表される ACU 値を報告します。クラスターレベルのメトリクスとして、クラスター内のすべての Aurora Serverless v2 DB インスタンスの ServerlessDatabaseCapacity 値の平均を表しています。このメトリクスは、Aurora Serverless v1 ではクラスターレベルのメトリクスに限られます。Aurora Serverless v2 では、DB インスタンスレベルとクラスターレベルで利用できます。

引っかかりポイント

CPUUtilizationを見ると CPU は最大 ACU の 0.3 % 程度しか利用されていないにもかかわらず、ServerlessDatabaseCapacityは 2 ACU（≒4GiBのメモリ+対応するvCPU）が消費されている状態が続いている事が分かります。最大容量は 256 ACU ですから、その 0.3 % は 0.768 ACU のはずです
FreeableMemoryを見ると 512 GBytes 程度残っています。最大容量の 256 ACU までスケールアップした時のメモリが 256 * 2 GiB = 512 GiB ですから、メモリはほとんど利用されていない事が分かります

以上の理由から、ServerlessDatabaseCapacityは 0.7 ACU 程度の値を推移して欲しいのですが、どういう訳か、常に 2 ACU 程度が利用されており、無駄にコストがかかっていることになります。

公式ドキュメントの調査

公式ドキュメントによると、Aurora PostgreSQL の以下のパラメータについては最大 ACU 設定に基づくメモリサイズから算出したデフォルト値を使用しますと記載されています。

autovacuum_max_workers
autovacuum_vacuum_cost_limit
autovacuum_work_mem
effective_cache_size
maintenance_work_mem

上記はあくまで Aurora PostgreSQL についての記載であり、Aurora MySQL については同様の記載を見つけることはできなかったのですが、ひょっとすると、Aurora MySQL についても同様に最大 ACU 設定に応じて確保されるメモリがあるのかもしれません。

試してみた

ということで、最大 ACU 設定を 16 まで落としてみた結果が以下の通りです。設定を変更した 16:30 頃を境に、各グラフが変動しているのが分かります。最大 ACU 設定に対する比率で計算されるCPUUtilizationとFreeableMemoryの変化は想定内ですが、現在の利用状況に応じて計算されると想像していたServerlessDatabaseCapacityが最小 ACU 設定の 0.5 ACU 近くまで下がるという結果になりました。