Aurora I/O 最適化にすべきかどうかを CloudWatch Metrics から確認する

こんにちは！クラウド事業本部コンサルティング部のたかくに（@takakuni_）です。

最近、仕事柄、クラウドのコストを意識することが多いです。今回は Aurora I/O 最適化オプションについて、CloudWatch から最適化可否を計算してみたいと思います。

Aurora I/O 最適化

Aurora I/O 最適化は、ストレージ IO に対する課金形態の1つです。

インスタンスタイプを 30 % 増、ストレージコストを 125 % 増にする代わりに、I/O に発生するコストを 0 にする課金形態です。

AWS Blogs によると、I/O に発生するコストが全体の 25 % を超えてくるとコストメリットが出てくるようです。

これにより、I/O 支出が現在の Aurora データベース支出の 25% を超えると、最大 40% のコスト削減が可能になり、I/O 集約型のワークロードのコストを自信を持って予測できるようになります。リザーブドインスタンスを使用している場合は、さらに大幅なコスト削減が受けられます。

https://aws.amazon.com/jp/blogs/news/new-amazon-aurora-i-o-optimized-cluster-configuration-with-up-to-40-cost-savings-for-i-o-intensive-applications/

I/O コストが高いケースでは、非常に魅力的ですね。

前提条件

利用している Aurora クラスターで I/O 最適化が必要かどうか、確認したくなってきましたよね？

その前に前提条件です。Aurora I/O 最適化を行う前には、次のバージョン以上が必要です。事前に確認しておきましょう。

Aurora I/O-Optimized is available in all AWS Regions for the following Amazon Aurora versions:

• Aurora MySQL version 3.03.1 and higher
• Aurora PostgreSQL versions 16.1 and higher, 15.2 and higher, 14.7 and higher, and 13.10 and higher

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html

CloudWatch Metrics で確認する

それでは、前提条件を満たしているということで、I/O、ストレージ、インスタンスタイプのバランスを比較します。

方法として Cost Explorer の Usage から見る方法、CloudWatch Metrics から見る方法、Cost Usage Report から見る方法の 3 パターンがあります。

今回は、あらかじめディメンションが設定されており、コスト配分タグなどの事前準備無しで可視化できる、 CloudWatch Metrics から確認する方法を利用します。

メトリクスの計算

メトリクスの計算には計算式および、発信元機能を利用してサクッと求めていきます。

まずは、CloudWatch のコンソールに遷移し、発信元 をクリックします。

開けたら以下の JSON を流し込みます。クラスターID 部分には Aurora のクラスター ID を入力してください。

{
    "sparkline": true,
    "metrics": [
        [ { "expression": "m1+m2", "label": "Total-IOPs", "id": "e1", "period": 2592000, "stat": "Sum" } ],
        [ { "expression": "(m3/1024/1024/1024)", "label": "Storage Volume in GB", "id": "e2", "period": 2592000, "stat": "Sum" } ],
        [ "AWS/RDS", "VolumeWriteIOPs", "DBClusterIdentifier", "クラスターID", { "id": "m1" } ],
        [ ".", "VolumeReadIOPs", ".", ".", { "id": "m2" } ],
        [ ".", "VolumeBytesUsed", ".", ".", { "id": "m3", "stat": "Average" } ]
    ],
    "view": "singleValue",
    "stacked": false,
    "stat": "Sum",
    "period": 2592000,
    "singleValueFullPrecision": true
}

貼り付けて 更新 をクリックすると、次のように Total-IOPs, Storage Volume in GB 諸々が表示されます。

今回の場合だと、次の値が取得できました。

• Total-IOPs：1,131,252,032 (Count)
• Storage Volume in GB：2,437.54391205 (GB)

料金の計算

料金の計算に移ります。仮にこの Aurora クラスターが東京リージョン、MySQL、2 つの DB インスタンス（db.r7g.large）で動いてたとします。

すると次の計算式が求まります。

Aurora のコンピュートコスト

Aurora のストレージコスト

Aurora の I/O コスト

合計

この結果から、わずかながら Aurora I/O 最適化にした場合、高くつくことがわかりました。

参考

https://aws.amazon.com/jp/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/

まとめ

以上、「Aurora I/O 最適化にすべきかどうかを CloudWatch Metrics から確認する」でした。

今回、はじめて CloudWatch の 発信元 機能を使ったのですが、広く配布するには非常に便利な機能だと思いました。

このブログがどなたかの参考になれば幸いです。クラウド事業本部コンサルティング部のたかくに（@takakuni_）でした！