はじめに

こんにちは、koizumiです。去年はSREチームに在籍しておりましたが、今年からサーバーサイドチームでAPI開発やクラウドインフラの運用改善などを担当しています。

弊社ではAWSをはじめとしたクラウドインフラのコスト最適化に取り組んでおり、その一環としてAurora I/O-Optimizedを用いてRDSのコスト削減を行いました。本記事では、Aurora I/O-Optimizedの概要と、移行後のコスト削減結果、移行の際に気を付けるべきポイントについてご紹介します。

移行後のコスト削減結果

まずは、Aurora I/O-Optimizedに移行してどれくらいのコスト削減効果があったかをご紹介したいと思います。

以下は、RI購入料金を除いたRDSの直近6ヶ月の費用のグラフになります。

Aurora I/O-Optimizedへの移行とRIの追加購入により、8月まで右肩上がりであったRDSのコストをおよそ半額以上削減することができました。

また、移行対象に限って見てみると、90%超のコストを削減することができました。

Aurora I/O-Optimizedとは

Aurora I/O-Optimizedは、Amazon Auroraの新しいストレージオプションで、高いI/O集中型のワークロードにおいてコストパフォーマンスを向上させることができます。このストレージオプションにすることで、Aurora DBクラスターへのI/O操作に対する追加料金が発生しないようになります。（料金体系の詳細については後述しています）

aws.amazon.com

以前は、Amazon AuroraのストレージオプションはAurora Standardのみの提供となっていたため、Auroraを使用する際はI/Oのコストが一定かかってしまうのは許容しなければいけないという状況でした。

Aurora Standardの課金体系について

Aurora I/O-Optimizedの詳細に入る前に、従来のストレージオプションであるAurora Standardの課金体系についておさらいしておきましょう。

Aurora Standardでは、毎月GBあたり$0.12のストレージ料金に加えて、I/O費用は100万リクエストあたり$0.24が請求されます。

aws.amazon.com

そのため、前述のように以前まではI/Oリクエストが多いワークロードに関しては一定のコストがストレージ料金に上乗せされてしまう状況となっていました。

Aurora I/O-Optimizedによるコスト最適化

Auroraにおいては、前述のようにI/Oリクエストによるコストの増加が大きな課題点としてありましたが、それがAurora I/O-Optimizedによってコスト最適化ができるようになりました。

以下の料金表は、Auroraの料金ページから引用してきています。

表から分かるように、Aurora I/O-Optimizedではストレージ料金が毎月のGBあたり$0.27（Aurora Standardと比較して約2.25倍）に増加する代わりに、その利用料金にI/O料金が含まれる形となります。（I/O料金が実質無料になると考えて良いでしょう）

また、Aurora I/O-Optimizedでは時間あたりのインスタンス料金についても、以下の表のようにAurora Standardのインスタンス料金と比較して約1.3倍となります。

インスタンス料金は、RIも含めて1.3倍となる点に注意してください。そのため、RIをすでに購入済みの場合でRIを追加購入しない場合は、その差額が請求される形となります。RIを追加購入した方がお得な場合は、購入数を30%増やしましょう。

例えば、db.t3.mediumのRIを2台購入している場合は、実際にかかるインスタンス料金は 2 * 1.3 = 2.6台分 で、RIは1台からしか購入できないため、追加購入はしない方が良いということになります。一方で、db.t3.mediumのRIを4台購入している場合は、実際にかかるインスタンス料金は 4 * 1.3 = 5.2台分 で、RIを1台追加購入した方が良いということになります。

まとめると、Aurora I/O-Optimizedは以下のようなコスト体系となります。

下記の2点と引き換えに、I/O費用が実質無料*1になる
- ストレージ費用（Aurora:StorageUsage）が約2.25倍に増加する
- インスタンスのランニング費用がRI含めて約30％増加する

移行をする際には、概算した移行後のコストと現状のコストとを比較して、どれくらいのコスト効果があるかを見るようにしましよう。

Cost ExplorerでI/O費用（コンソール上の表記はAurora:StorageIOUsage）が極端に高くなっているDBインスタンスを調べ、それらの現状のコストをスプレッドシートにまとめ、それらから移行後のコストを概算し、どれくらい安くなるかを調査すると良いでしょう。

切り替え方法

切り替えの方法は非常に簡単です。

マネジメントコンソールにて、移行対象のクラスターを選択し、「変更」を選択します。

その後、設定の編集画面に遷移し、スクロールしていくと以下のような「クラスターストレージ設定」という項目の「Aurora I/O 最適化」で設定変更が可能です。設定変更によるダウンタイムは発生しません。

移行の際の注意点

ここからは、移行の際に注意していただきたいポイントをいくつか取り上げたいと思います。

本番環境でそこまで安くならない場合がある

弊社のDBクラスター環境において、開発環境と検証環境においては大幅なコスト効果があるものの、本番環境では移行しても安くならないというケースがありました。これは、本番環境のインスタンスタイプで db.r5.large を使用しており、バッファキャッシュのヒット率を高く保てていたため、I/O処理の発生を抑制することができ、結果的にI/Oリクエストによる課金を抑えられていました。

このバッファキャッシュのヒット率とは、I/O処理を増やす要因のひとつであり、これが低いとI/O処理のリクエスト数が多くなります。 CloudWatchメトリクスでは Buffer Cache Hit Ratio で確認できます。

このバッファキャッシュのヒット率は shared_buffers に割り当てられているメモリ量に依存しており、そのメモリ量はインスタンスサイズに依存しています。そのため、インスタンスサイズが小さい開発環境/検証環境ではI/Oリクエストが多いが、インスタンスサイズが大きい本番環境ではI/Oリクエストを抑えられているという状況が発生する可能性があります。

詳細につきましては、以下のドキュメントが非常に参考になりました。

aws.amazon.com

移行に際してのコスト調査を行う際は、上記に注意して本番環境で思ったより安くならない可能性がある、ということを頭に入れておくと良いと思います。