爆速コスト削減！成功と失敗のリアル検証記録

この記事はウィルゲート Advent Calendar 2025 5日目の記事です。

弊社サービスのとあるプロダクトのインフラ環境は、サービス成長とともに複雑化・肥大化し、気づけば月額コストが想定以上に膨らんでいました。そこで「月額12万円削減」を目標に掲げ、インフラ最適化に着手。

バージョンアップ、スケールイン、リソース集約など、数々のトライを繰り返す中で、成功もあれば断念したものもありました。

本記事では、そのプロセスを振り返りながら、削減効果を共有します。

1. インフラ構成とコスト課題

サービスの裏側では18台を超えるサーバー群が稼働し、さらにRDSやElastiCacheも加わっていました。まずは現状と課題を整理します。

課題

気づけばMySQL 5.7の有償サポートが自動開始…。

本プロダクトのRDSですが、Auroraのバージョン2を使用していました。こちらの詳細に関しては以前記事にした

の通りですので今回のメインコンテンツとしてバージョンアップ対応を行いました。

バージョンアップの詳細な手法に関しては

の通りBlue/Green Deploymentsで行いました。

実はサブドメインごとに作られていたALBをまとめて削減に成功。

合計で10台あったロードバランサーを2台に集約しました。

これに関してはもっと早くに実施していればと思いました。

切り替え時もメンテナンス等はなしで作業的にも工数はかからず実施できた割に削減率が高く費用対効果が高い施策です。

検証等で移行にかかるコストが高いにもかかわらず削減できるコストはそこまで大きくなく、コスト削減効果が薄いと判断してCloudFront移行は断念。

セキュリティを維持しつつ、不要になったClamAVを削除。無駄なコストを削ぎ落とす「潔さ」の重要性を実感しました。

弊社ではウィルスチェックにClamAVを用いたシステムを使用していました。

このシステムですがEC2＆Lambdaの構成になっていたので昨年調査を実施したS3 Malware Protectionへウィルススキャンを移行することにしました。

調査はすでに終えていたので、移行自体はインフラエンジニア1年生の同僚に行ってもらいました。

無事1日もかからずに以降が完了し、各種EOL等に悩まされなくもなりコストも抑える事ができました。

本当にこれらのサーバは個別で必要なのか？

と言う観点で改めて構成を見直した結果、いくつかのサーバは負荷もほとんどなく個別のサーバにしておく必要がないのではないか？と言う結論に至りました。

毎日モニタリングをしていながら、この負荷状況であればこの構成でもいいのでは？と言う疑問を持たずに居る事で改善できなかった事なので、改めて何の為にモニタリングをしているのかを考えるきっかけになりました。

実際にテスト環境ではまとめて運用している機能でもあった為、本番環境でもまとめて運用しても問題ないとし4台分の機能を一つのサーバに統合しました。

最終的に目標のコスト削減を実現。

工数自体も予定より40%短縮して完遂しました。

試行錯誤をスピード感を持って進めたからこその成果でした。

次回は早くもアドベントカレンダー二回目の登場の清水さん「【続】CSRF token mismatch.の沼に再びハマりました」です！

一回目の記事はこちら