FinOpsのナレッジ：RDS編
みなさん、こんにちは
ＳＯＭＰＯシステムズのクラウドエンジニアです。
FinOpsのナレッジ第2弾について、紹介します。
前回、「FinOpsのナレッジ：EC2編」を公開しましたが、その続編です。
1．はじめに
今回は、とあるクラウド(AWS)の構成において「RDS」観点で注意が必要なポイントを紹介します。特にRDSのランニングコストは高いため、要注意です。
2．構成
2.1 利用サービス
Amazon EC2
Amazon RDS
Elastic Load Balancer
CloudFront
Route53
Amazon S3
2.2 構成図（インターネット公開のWebシステム）
2.3 構成概要
マルチAZ構成
通常時zone aのEC2を利用
ELBでヘルスチェックし、失敗した場合zone bのEC2に切り替え
障害時は自動的に別AZのRDSにフェイルオーバー
開発、本番環境ともにリソースのスペック同等
24/365 稼働システム
3．FinOps観点でチェックすべきポイント
3.1 本番・開発環境の稼働時間
本番、開発環境のRDSインスタンスの稼働時間を確認する。
RDSに関しても、前回の「FinOpsのナレッジ：EC2編」と同様、起動しているだけでランニングコストが発生してしまうリソースです。そのため、開発環境に関しては、必要時のみ起動する運用とすることがコスト最適化のポイントとなります。また、RDSは接続元となるEC2が起動していなければ、サービスとしての利用用途は少ないため、EC2と合わせて必要時に起動し、不要時は停止することを推奨します。
注意点として、RDSの連続停止時間は7日間となっており、7日後に起動状態になってしまうため、Lambda関数で7日以上停止できるようにしておくと手動作業が削減されます。
本番環境においても、提供するサービスレベルに応じて必要最低限の稼働にすることが望ましいです。
3.2 本番・開発環境のインスタンスサイズ
開発環境のRDSインスタンスサイズを確認する。
サービスのリリース前・リリース後どちらにおいても、開発環境のインスタンスサイズが本番同等になっていてもよいか検討する必要があります。リリース後であれば、3.1で述べたように、開発環境は必要時以外使用しない環境となるため、機能追加など本番環境と同等のテストが求められる場合を除き、スケールダウンしておくことを推奨します。また、EC2と同様にRDSにおいてもインスタンスサイズの変更は容易に行えるため、柔軟にインスタンスをサイジングしていくことが重要です。
本番環境のRDSインスタンスサイズを確認する。
本番環境でも、開発環境と同様、定期的にRDSの利用状況（メトリック情報）を確認することで、適切なインスタンスサイズに変更することが重要です。ただ、インスタンスサイズの変更にはRDSの再起動が伴います。そのため、本番環境においては、サービス影響の少ない時間帯に行うことなど、注意すべき点は多いです。特に、サービスのリリース前に決定したインスタンスサイズで突き進む必要はなく、リリース後に実際にサービスの利用状況からインスタンスサイズを最適化していくことが大切です。
3.3 開発環境のマルチAZ構成
開発環境のマルチAZの要否を確認する。
開発環境では、障害テスト時などにマルチAZ構成である必要があります。ただ、それ以外のときにRDSをマルチAZ構成にしておく必要はありません。通常時もマルチAZ構成にしておくことでRDSのコストは2倍となるため、注意が必要です。なお、RDSのマルチAZの変更は有効化/無効化をAWSコンソールで選択するのみで、プライマリDBに対する影響は発生しないため、必要に応じて容易にマルチAZ構成にすることができます。
4．総括
ここまでRDSのコスト最適化観点について説明しました。RDSの利用にあたっては、EC2よりもコストが高くなることが多いため、特に注意が必要です。その分、コストの最適化を行うと、大きな効果が得られるのも事実です。
特に、開発環境に関しては本番環境よりも容易に対応できるため、ぜひ実践してみてほしいです！
参考までに、RDSインスタンスの料金をAWSが公開しているので、確認してみてください。