🧑💻自己紹介
初めまして。私は都内でwebエンジニアをしています。
今の会社はインターンを経て、新卒入社しました。早いもので社会人2年目になりました。
今は担当プロジェクトの開発チームリーダーとして日々プロダクトの改善を行なっています。
今回初めてQiitaに投稿を行うことにしました。励みになりますのでぜひ意見やコメントを頂けますと幸いです。
💻背景
担当プロダクトはAWSを利用していたのですが、プロダクトの成長とともに、サーバ費が増加してきたことに加え、昨今の円安によりサーバ費用の増加が顕著になってきました。
ユーザー数が増えてきたのは嬉しい一方で、ユーザー数の増加と共に運用費用がかさんでしまってはビジネス観点からもよろしくないと考え、今回利用しているAWSのコスト削減へ踏み切りました。
📝前提
利用しているAWSのサービス
今回のプロダクトで利用していたAWSのサービスの一例です。
- Amazon EC2
- Amazon Elastic Container Registry (ECR)
- Amazon Elastic Container Service (ECS)
- Amazon Elastic Kubernetes Service (EKS)
- Amazon ElastiCache
- Amazon OpenSearch Service
- Amazon RDS
- AWS CodeBuild
- AWS CodePipeline
- Amazon CloudWatch
- その他...
⚙️改善策
SQLスロークエリ改善
まず、ボトルネックになっていたのがスロークエリの存在でした。
複数テーブルで複雑なクエリを実行している部分があり、処理時間が必要以上にかかってしまうのですが、サービスとしてリクエストからレスポンスまでの時間が長いのはユーザーにとってストレスでもあります。今までは、負荷が高くなった場合は都度ReaderのRDSをスケールアウトさせ、負荷分散を行うことで暫定対応していました。
この運用に着目し、まずはスロークエリ改善を行うことを決定しました。
ここを改善することで、常設のRDSを削減できランニングコストが削減できる、またレスポンス速度改善によるUXの改善が期待できると考えたためです。
DBのテーブルのindexの確認
Amazon CloudWatchを利用し、クエリごとのレスポンス時間を集計、時間がかかっているクエリを洗い出しました。
その後、該当のクエリの実行計画を確認しました。
実行計画について触れていない方は以下の記事が参考になるかと思います。
ということで、該当のクエリの実行計画を確認したところ、costの大きなSeq Scanが大量に走っており、これはcolumnにindexが設定されていないのでは？と思って確認したところこれが当たりでした。
すでに存在するテーブルにindexを設定するCREATE INDEXコマンドは、テーブルロックがかかると言われていたので、実行時間によってはサービス影響が大きくなる可能性があったため、検証環境でも実行時間をしっかりと確認しながら検証しました。結果今回対象のテーブルのレコード数は40万件以上はありましたが、5秒かからないくらいでそこまで時間はかかりませんでした。
このindexの設置によって、実行計画の中の無駄なSeq ScanはIndex Scanに変更され、総costも減少しました。
クエリ自体の見直し
当時同チームの@genta-kawabataさんにご尽力いただき、処理時間を98%カットすることができました。ありがとうございました。
こちらの内容は以下の記事にまとまっていますのでこちらをご覧ください。
リザーブドインスタンスの利用
今回の費用削減のキモはここになります。
AWSにはリザーブドインスタンス(以下RI)と呼ばれる仕組みがあります。一定期間分のインスタンスタイプとインスタンス数の枠を事前に購入しておくことで、割引を受けることができます。
プランや購入期間などによって割引率は前後するようで、基本的には長期間分買うほど割引率は高くなるようですが、長期間分買いすぎて逆に困ったなどの話も聞いたので、今回は現用のインスタンスタイプのRIを一年分事前購入することにしました。
今回は、費用の多くの割合を占めていたAmazon EC2、Amazon ElastiCache、Amazon OpenSearch Service、Amazon RDSに 対してRIの導入を行いました。
前述のクエリの見直しにより、必要な常設のread replicaのDB数がかなり減ったため(対応前の半分ほど)、相乗効果もかなりあったと思います。
見積もりの段階で20~40%弱程の費用削減を見込めたのと、長期購入によるインスタンスを、利用せずとも費用が発生するリスク以外に、特段これといったリスクがなさそうだったため、実行に踏み切りました。
💰結果
前月で多くの割合を占めていたRDSが約半分程度の費用になりました。その他のサービスでもRDS程までではないですが効果が見られました。
具体的な金額はお伝えできませんが、全体の費用としては年換算で数百万の費用圧縮を実現することができました。これは前期比で20%以上の割合でした。
会社全体における金額としては微々たるものかもしれませんが、サービスレベルを下げず無駄なコストを削減したことは前向きに捉えてて良いことだと思います。
そして何より、エンジニアが主体となり技術的アプローチによって課題を解決できたことは私の経験として大きなプラスになりました。
👤今後について
普段より事業サイドと密に連携をとりながらプロダクト開発を進めていますが、今回のケースのようなエンジニアからしか提案ができない部分も多くあると思います。
開発サイドが主体的に動くことで直接事業にプラスになる可能性はありますし、怯むことなく前のめりにプロダクトをより良くする意識を開発チームが持てるよう、これからも施策を進めていきたいと思います。