2025.04.08
AWSのランニングコスト改善
結論
- CloudWatch Logsへの不要なログ転送を削減して、CloudWatch Logsのランニングコストを削減した
- ECSに適切なタスク数とオートスケールを設定することで、ECSのランニングコストを削減した
- VPCエンドポイントを開発環境とSTG環境で共有することで、VPCエンドポイントのランニングコストを削減出来る見込み
- ElastiCache Serverless for Valkeyに移行することでElastiCacheのランニングコストを削減出来る見込み
はじめに
こんにちは。次世代システム研究室のT.Tです。
前回の記事では、昨年12月に現在開発運用に携わっているWebサービスのAWSへの移行時の検証で発生したパフォーマンスの問題についてご紹介しました。現在はAWSでの運用を開始してしばらく経っていますが、運用開始後にAWS環境でのランニングコストが見積を大きく超過する問題が発生したため、その改善に取り組みました。本記事では、AWS移行のランニングコストで発生した問題について、その内容と改善策についてご紹介します。
1.AWS移行のプロジェクト概要
AWS移行の目的としては、元々Webサービスが稼働しているオンプレ環境で利用していたCentOS 7のEOLに伴うシステム移行です。加えてオンプレ環境でセキュリティ対策を継続するのも困難になってきており、AWSを利用した継続的なセキュリティ対策とセキュリティ向上が主な目的になっています。一方、元々稼働していたシステムでのランニングコストがAWS環境での予算上の目標値になる事情があり、移行の初期段階ではランニングコストも同程度の規模になるようなシステム構成にしました。
Webサービスのフロントエンド/API部分だけAWS移行が完了しています。オンプレ環境では、Kubernetes/Dockerの環境を自前で構築して、NginxとPHPのWebアプリケーションをコンテナとして稼働させて、Oracle DBと連携して稼働していました。今回の移行では、Oracle DB以外の部分をAWS環境に移行しています。
AWS移行を担当したメンバーは、オンプレ環境の開発運用を担当しているメンバーと同じで、AWS環境での開発経験のあるメンバーは何人かいましたが、運用経験のあるメンバーがいない状況での移行プロジェクトとなりました。
2.移行後に発生したランニングコストの問題
2.1.ランニングコストの見積
元々のシステムの環境には開発環境とSTG環境、本番環境の3つの環境があり、それぞれのシステムの要件を満たすシステム構成のパターンをいくつか検討して、AWS Pricing Calculatorで見積もって、元々のシステムのランニングコストに近いシステム構成を選びました。詳細は省略しますが、AWSのシステム構成要素としては、ECS、ElastiCache Serverless for Redis、CloudWatch、S3、VPC、ELB、セキュリティツール等が挙げられます。
2.2.移行後に発生したランニングコストの問題
移行後1週間くらい経過したところで全AWSアカウント(全環境)のランニングコストを確認してみると、月額コストが見積額を大きく超過していました。コスト超過が発生した箇所はいくつかありましたが、本記事で紹介する部分だけ抜粋すると、CloudWatch、ECS、VPCエンドポイント、ElastiCache Serverless for Redisでした。この中で、CloudWatchとECSの問題については解決済みで、VPCエンドポイントとElastiCache Serverless Redisについては改善策を検討している段階です。この後の項目で改善策について見ていきたいと思います。
ChatGPTで改善策をイメージにまとめてみました。改善策の雰囲気だけは捉えられていますが、内容には間違いがあるので記事側をご参照ください。
3.解決済みの問題
3.1.CloudWatch Logsに出力するログの削減
Cost Explorerでコストの発生状況を確認してみると、本番環境の移行後にCloudWatch Logsのコストが大きく増加していることが分かりました。このタイミングである程度増加するのは予想していましたが、見積と比較して大きく超過しているので、詳細を調べてみました。
調べてみたところ、ログが重複して出力されている部分や移行元の環境では出力していなかったログが出力されていて、CloudWatch Logsのコストが大きく増加していました。移行元の環境では、ホスト側にログを出力してFluentdでログを転送する仕組みにしていたため、AWS移行に合わせてコンテナ内でログをCloudWatch Logsに転送するように変更しました。この変更の際にログの転送用のフィルタの設定とNginxのログの設定に誤りがあったのが原因でした。この設定を見直すことでCloudWatch Logsへのログの転送量が減り、CloudWatch Logsのコストを改善出来ました。
3.2.ECSのタスク数の最適化
開発環境とSTG環境でECSのコストが一定の割合で発生している状態になっていました。開発環境は利用していない状況になったら自動で停止して、STG環境は通常は1タスク起動してリクエストの増加に応じてオートスケールする設計にしていましたが、この設計がAWS環境の設定に反映されていないようでした。
調べてみたところ、開発環境では常時1タスク起動する設定になっていて、利用されなくなったら停止する設定になっていませんでした。STG環境では、常時3タスク起動する設定になっていて、1タスクからオートスケールする設定になっていませんでした。設定に齟齬があった原因としては、設計の担当者と設定の担当者が異なっていたので、両者間で伝達ミスがあったのと、レビュー時点で見落としていたことによるものでした。当初の設計内容を設定に反映することでECSのコストを改善出来ました。
4.解決策を検討している問題
4.1.VPCエンドポイントの改善
VPCのコストが見積を超過していることが確認出来たので、VPCのコストの内訳を調べてみました。すると、VPCエンドポイントのコストが大きいことが分かりました。VPCエンドポイントは、VPC内からSecretsManagerやCloudWatch Logsにプライベート接続するためにを利用しています。コストの内訳としては、VPCエンドポイントの固定利用料とネットワーク利用料の2つありました。見積の時点で固定利用料を見落としていて、その分がコスト超過の原因でした。インターフェース型は1VPCエンドポイント当たり、固定で約$10/月($0.014/時)掛かり、接続サービスごとにそれぞれのVPCエンドポイントが必要なので、利用数が多いと固定利用料だけでもコストが大きくなります。
VPCエンドポイントのコスト削減の対策案として2通り検討しています。一つ目は、開発環境とSTG環境でVPCエンドポイントを共有して固定利用料のコストを削減する案です。本番環境と他の環境のリソース共有はセキュリティ的に危険な側面もあるので、本番環境とは共有しない方針です。VPCエンドポイントを他アカウントのVPCに共有する手順の記事の内容で設定出来そうです。
この対策だけだとあまりコストが削減出来ないので、もう一つの案も検討しています。【AWSコスト最適化】VPC エンドポイントを消すだけでセキュリティそのままにコストが節約できたの記事によれば、VPCエンドポイントの用途がプライベート接続だけならVPCエンドポイントを使わず、代わりにインターネットゲートウェイやNATゲートウェイを使う方針でも良さそうです。この方針の場合でもネットワーク利用料は注意が必要で、CloudWatch Logs等で大量にネットワーク通信が発生する場合はVPCエンドポイントを利用する方が安くなる場合もありそうです。
4.2.ElastiCache Serverless for Redisの改善
開発環境とSTG環境で利用しているElastiCache Serverless for Redisのコストが見積を超過していました。開発環境とSTG環境ではキャッシュをほとんど利用しない見込みだったためElastiCache Serverless for Redisを利用しましたが、これを利用すると最低でも$108/月掛かるようで、この仕組みを見落としていたのが原因でした。
現在は、ElastiCache Serverless for Valkeyが提供されていて、こちらを利用すればコストは最低$6/月と大きく改善されるようです。Valkeyに移行する場合は動作検証が必要になるので、すぐには移行出来ませんがValkeyへの移行でコストを削減出来る見込みです。
5.まとめ
現在も移行元の残システムからAWSへの移行プロジェクトを進めていて、並行してAWS環境のランニングコストの削減を進めています。本記事でご紹介した改善策やそれ以外の改善策を進めて、20%程ランニングコストを削減出来ていますが、まだ目標のランニングコスト額には届いていない状況です。今後もコストの状況を確認しながらコスト削減を進めたいと思います。
次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。
グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。
Follow @GMO_RD