はじめに
みなさん、こんにちは。グローバルでは単なるクラウドの活用から先に進み、クラウドのビジネス価値を最大化するための取り組みである「FinOps」の実践が当たり前になりつつあります。
もちろんFinOpsの目指すべきゴールは、正しくはコスト削減ではないものの、今回はあえて削減の部分にフォーカス当てて紹介していきたいと思います。
よくあるコスト最適化のポイント
まず前段として、クラウドにおける一般的なコスト最適化のポイントとしては以下のような項目が挙げられます。
- コンピューティングの適正化
- 未使用リソースの棚卸
- 料金プランの適正化
- ストレージ/ネットワークの適正化
- ライセンスの適正化、など
もちろんこれらの項目はRDSにも当てはまってくる部分があります。今回はこちらに沿ってRDS（ただし、Aurora除く）の最適化ポイントを紹介していきたいと思います。
コンピューティングの適正化
過剰なサイジングの見直し
机上でサイジングした結果をもとにインスタンスファミリーやサイズを選択し、そのまま使い続けているといったケースも少なからずあると思います。しかし、机上のサイジングでは安全係数をかけていることが多く、実際に必要なサイズよりも過剰になっていることが多いです。
また、状況の変化によって当初想定していた業務量と実際の量に差が出てきてしまい、結果として過剰なサイジングとなってしまっているケースもあるかと思います。そのため、稼働統計データなどから過剰なサイジングになっていないかを定期的に見直すことで、過剰なリソース分に支払っている料金を節約できる可能性があります。
過剰なサイジングになっている可能性のあるRDSインスタンスを特定する簡単な方法としては、「AWS Compute Optimizer」と「Amazon RDS Performance Insights」を活用することです。
2024年12月現在ではRDS MySQLとRDS PosgreSQLのみが対象ですが、稼働統計データを基にCompute Optimizerからレコメンデーションを受けることがでできます。また、この際にRDS Performance Insightsを有効化しておくと追加のメトリクスにより、より深い洞察を基にしたレコメンデーションを可能となります。標準機能のみの利用であればいずれの機能も無料で活用できるため、無効化されている場合はぜひ有効化し、コスト最適化の機会特定に活用ください。
レコメンデーションを鵜呑みにしてはいけない
レコメンデーションはあくまでこんなところに最適化の機会がありそうだ、という気づきとして活用ください。パフォーマンス問題を起こさないためにも、すべてを鵜呑みにせず、本当に適用して大丈夫なのか事前に評価を行うことが重要です。
Armベースのインスタンスの活用
x86ベースのCPUを搭載したインスタンスタイプを採用している場合は、コスト効率や性能に優れるArmベースのインスタンスタイプに切り替えることでコストを10%ほど節約することができます。Armベースのインスタンスタイプが提供されているデータベースエンジンについては、動作に影響がないことを十分に評価した上でインスタンスタイプを切り替えられないか検討してみてください。
なお、EC2やECSとは異なり導入ソフトウェアの制約云々の話はありませんし、CPUアーキテクチャーの違いによってデータベースのアクセス方法が変わることもないため、切り替えのハードルは低い方かと思います。
ArmベースのCPUが使えるかはソフトウェア次第である
OracleやSQL Serverなどの一部のデータベースエンジンについては、2024年12月時点ではArmベースのインスタンスを選択することはできません。
過剰な冗長構成の見直し
高可用性の必要ないPoC/開発環境などでマルチAZ構成を組んでいるリソースは、過剰な冗長構成となっている可能性があります。過剰な冗長構成を適正化し、シングルAZ構成かつシングルインスタンスにすることでコストを節約することができます。
とくにPoC/開発環境などの場合は、試験のときに一時的にマルチインスタンス、マルチAZにすればいいだけのことも多いため、定常的に冗長構成にしておかなければいけない構成なのか、改めて見直してみてください。
未使用リソースの棚卸
アイドル状態のインスタンスの棚卸
DB接続が長期間にわたって確立されていない状態（アイドル状態）のインスタンスは、未使用リソースの可能性があるため、削除もしくは停止することによってコストを削減できる可能性があります。
RDSインスタンスは永続的に停止しておくことができない
一定期間（1週間）停止していると自動的にインスタンスが起動してきます。長期停止する場合は、定期的に自動停止するか、必要に応じてスナップショットから再構築してください。
不要なDBスナップショットの棚卸
定期的なバックアップではなく、最終スナップショットなどとして取得してから長期間経過しているバックアップデータについては、削除もしくはアーカイブすることによてコストを削減できる可能性があります。
料金プランの適正化
リザーブドインスタンスの適用
24時間365日の稼働ではなくとも長時間稼働するリソースは、リザーブドインスタンス（RI）を適用することによってオンデマンド料金よりもコストを削減できる可能性があります。
RI購入によるコスト最適化の機会の気づきとして、AWS Billing and Cost ManagementのRIレコメンデーション機能が活用できます。稼働統計データを基にRI購入に関するレコメンデーションが提供された場合は、詳細調査を行った上でRIを追加購入できないか検討してみてください。
スケーリングの調整
未使用の時間帯はインスタンスを自動停止
PoC/開発環境などの平日日中の業務時間帯のみに稼働するリソースは、スケジュールにあわせて確実にリソースの停止を実行することでリザーブドインスタンスを適用するよりもコストを抑えられる可能性があります。
ストレージ/ネットワークの適正化
過剰なストレージ性能の見直し
コンピューティングの適正化と同様に、稼働統計データなどから過剰なサイジングになっていないかを定期的に見直すことで、過剰なストレージ性能に支払っている料金を節約できる可能性があります。
過剰なサイジングになっている可能性のあるインスタンスストレージを特定する簡単な方法としては、コンピューティングと同様に「AWS Compute Optimizer」が活用できます。標準機能のみの利用であれば無料で活用できるため、無効化されている場合はぜひ有効化し、コスト最適化の機会特定に利用してみてください。
ライセンスの適正化
オープンソースデータベースの活用
商用データベースエンジンを採用している場合は、ライセンスの安いオープンソースデータベースエンジンに切り替えることでコストを節約することができます。
ただし、移行に伴うコストやそれ相応の労力が必要となるため、サービス利用料だけではなく移行に要するトータルコストも考慮した上での判断が必要となるためご留意ください。
最後に
もちろん今回紹介したもの以外にも最適化ポイントはあります。とはいえ、まずは今回紹介したような、よくある最適化ポイントから始めてみるのが良いのかなと思っています。
なお、一点注意していただきたいのですが、コスト削減に注力するがあまり、パフォーマンスを損なってしまうようでは本末転倒です。修正を加える際は、実際の環境への影響をしっかりと調査を行った上で実行するとともに仮に悪影響が出てしまった際には、すぐ切り戻せるようにしておくことも重要であることをご認識いただければと思います。
以上、Amazon RDS（ただし、Aurora除く）のよくあるコスト最適化ポイントのご紹介でした。今回の内容は基本的に使い古された情報ですが新たな気づきがひとつでもあったなら幸いです。
- AWS は、米国その他の諸国における Amazon.com, Inc. またはその関連会社の商標です。
- その他、本資料に記述してある会社名、製品名は、各社の登録商品または商標です。