AWSコスト削減ってこんなにも楽しいんだよ

はじめに

2024年の年始あたりから、機能開発の傍らAWSのコスト削減に取り組んでいました。
ここ1年間で円安がかなり進む時勢となりましたが、 円ベースでも昨年比で年間コストの削減割合が50%となる見通しとなり、単月の最高削減割合は約70% というところまでようやく来ました。

自分自身、これまでほとんどがプロダクトの機能開発・エンハンスなどを中心にしていたのでインフラの扱いにおいて強い専門性を獲得できている訳ではありません。プロダクトのインフラでAWSを利用しているので、機能開発のアーキテクチャリングという文脈で様々サービスを利用しているくらいです。

ただ取り組みの中で毎日CostExplorerを開いて睨めっこするくらいに楽しさを覚えてしまい、数値としてもここまで変えられるのか、という段階まで一旦来たと思うので、区切りとして何を意識して実行していたかというのを残しておこうと思います。

まず、どうしても伝えたいこと

あの、恐らくここが本編です。
AWSのコスト削減めちゃんこ楽しいですってことをどうしても伝えたいのです。それはもう毎晩CostExplorerの更新を楽しみに就寝し、 希望を持って目覚めた朝まず最初にやることが「CostExplorerを開くことになる」 くらいには。

なぜここまで楽しみを感じるのか。
恐らく僕は疲弊してしまっていたのだと思います。まだこの業界でエンジニアとして働いて8年しか経たない若輩者でありますが、それでも身の回りを流れゆく時代の速さと、それ故に認識の統一がなされない業界独自の言語、曖昧模糊たるナントカカントカエンジニア、組織という半透明な生きているかの如く振る舞う存在、そしてそれに振り回される自らのあてどなさ。
だからそれ故にエンジニアリングを確かなものにしようと新たな言語・基準というものが生み出されたりする。開発生産性という不確かなものに対してFour KeysやSPACEというものを掲げて立ち向かっていってみたりする。それらはとても素晴らしい取り組みであり、変化し続けるこの業界の楽しさでもあると同時に、やはりどこかで疲弊を感じる瞬間があります。

アウトカムという表現が適切か微妙だが、開発をしているプロダクトが提供しているサクセスを測定して追っかけていくだけでも簡単ではない。その積み上がりの上に実現されるビジョンのようなものはより一層、日々の業務の中で「どれだけ近づいているのか」と考え始めるとその難しさに頭を抱えたくなる。茫洋としたものを目指すために不確かなものを積み上げて、暗闇の中を「それでも」と一歩一歩進んでいる感覚が付き纏うのです。

ここで一応、保身のために注釈を入れておきたいのですが、これは現在属している組織やプロダクトを想起して記載している訳ではありません。むしろ明確である方なのではないかなと思います。あくまで業界全体に対して感じているという話で、ただ単に「確かなものって結構少ないよね」ということを話しています。

一方、AWSのコスト削減に取り組んでみてどのように感じたか。
対峙しているのは国家のインフラであり、絶対的な基準として君臨する通貨である。
その追いかけるべき数値の確からしさたるや大和国の富本銭にまで遡る。制度としては明治4年5月に公布された新貨条例等これまでの歴史の中で仕組みの変更はなされるものの、基本的に本質は変わっておらず通貨という概念として長い時間存在し続けている。

コスト削減というのは、 エンジニアとしてこの業界で数少ない圧倒的に確かなものを追いかける ということなのだと感じました。
想像してみてください。不確かなぬかるみの上よりコンクリート舗装された道の上ではスキップがし易いでしょう。ワクワク、ウキウキです。これを追いかけていくことに果たして意味はあるのだろうか？などと変に疑いを持つことなくその道を胸張って歩けるのです。
事業との接続性に思い悩む余白もありません。PLもBSも単位は何がしかの通貨なのです。

だらだらと書き殴っていましたが、結局伝えたいことをまとめると3つです。

• 明確な数値を追っかけるのって楽しいよ！それが信じられるものであればある程に
• もしあなたの所属している組織でAWSのコスト管理ができてなかったら事業数値に直結する大きな成果に繋がるかもしれません
• AWSに強い専門性がなくても成果を挙げられるものも多くあるよ！

3点目に関してはここから実際に何を意識しながら取り組んでいたか記載してみようと思います。

実際に取り組んだこと

ここから先は実際に取り組んだことです。
本編は終わり、付録となりますのでサラッといきます。
正直、技術的に優れた何かを実行した訳ではなく、当たり前のことを少しずつ進めていったという内容なので、真新しい何かを得られる可能性はほとんどないと思いますがご容赦ください。

まずは現状を知ることから始め、対応の優先順位を自分の中でつけていくことから始めました。
少し気になる部分があっても効果が少なく工数がかかってしまうのであれば目を瞑り、上半期内で年間換算50%減という目標を掲げて色付けをしていきました。

どこにどのようなコストが発生しているかしっかりとCostExplorerでサービス単位ではなく、請求画面で詳細まで見れるので、最低限のスタートラインとしてはここを確認するところからになるのかなと考えています。

また、優先順位において「やる」/「やらない」の切り分け方は様々あると思いますが、ケーキのように大きな切り分けからしていきました。

• アーキテクチャ・環境
• サービス
• インスタンス
• コストタイプ

少しずつ、かい摘んで実際に対応した例を挙げていきます。

アーキテクチャ・環境レベルの取り組み

大きな切り口ということもあり、ここが一番規模の大きな取り組みとなりました。
対象のプロダクトでは過去に意思決定した事業戦略上の都合で、基本的にはマルチテナントで稼働していたものの、業務ドメインの違いから切り出されてシングルテナントととして稼働していた部分が複数ありました。
アーキテクチャ・環境レベルの取り組みだと、その改善には事業戦略上の背景があったり、意図してコストをかけているだけの根拠があったりします。構造としては事業戦略を実現するためのアーキテクチャとなっているべきと考えますが、今回の場合は既にシングルテナントとして稼働させていた目的は達成した状態にあったので、良い契機として完全なマルチテナント化に向けて改修を進めました。アプリケーション・DBとゴリゴリの改修を泥臭く進めていきました。（移行大変だった＞＜）

マルチテナント側ではリソースに十分余裕がある状態でしたので、ここは追加のAWSコストが発生せず、シンプルにシングルテナントとして稼働させていた分のリソースが一式削除となり、かなり大幅な改善に繋がっています。

サービスレベルの取り組み

こちらはサービス別にどこにコストがかかっているのかを見ていきました。
実際の場合だとRDSにかけているコストが異様に高く、ここをどうにかしない限りインパクトのある削減には繋がらないと考え、優先的に改善を図る計画としました。
コストを見ていく切り口としてはサービス別に見ていき判断をしましたが、結果として一番効果が出る見込みとなった案はアーキテクチャの改善となりました。
アーキテクチャの改善となるので、こちらもこれまでのアーキテクチャの背景には事業レベルでの意思決定が介在しています。過去このプロダクトはマイクロサービス化を目指し、1アプリケーションに1DBを構築した複数のサービスから構築されており、それぞれのサービスでRDSのリソースを十分に利用している訳ではなかったのでRDSの費用が嵩んでいました。むやみに大きなインスタンスタイプが採用されていた訳ではありませんが、本番環境はマルチAZであり、プロビジョンドとして用意されているリソースもあり、それに加えてそれぞれの検証用環境を稼働させていると、、、といった形でそこそこのボリュームとなっていました。

こちらはマイクロサービス化に向かうような方向性も今は状況が異なる形となっており、DBの統合という形で進みました。

インスタンスレベルの取り組み

ここも至極当たり前のこと、凡事徹底、凡事が万事です。
どのくらい稼働しているインスタンスなのか、リザーブドインスタンスは購入した方のが良いのかスポットでの起動なのか？
それともSavings Plansなのか？そもそもこのインスタンスって何？（汗）
みたいなところを徹底的に棚卸しして整理していきました。
そうです。もともとAWSリソースが十分に管理できておらず、荒れ野のように半放置気味でした。
これは泥臭く仕分けして対応していった次第です。（様々なメンバーに協力いただき、情報をかき集めていきました、、、）

コストタイプレベルの取り組み

あとは最初に確認していたコストタイプ別の金額を確認していき、目くじらを立てるように無駄遣いしてしまっている部分を洗い出していきました。従量課金といってもRDSのプロビジョンド系に関しては利用せずとも用意されたリソース分のコストが発生する形となってしまうので、不要なコストがかかってしまっていないか確認していき、少しずつ積み上げで改善をしていきました。

振り返ってみて

改めて書いていて、特段インフラ・AWSにおける強い専門性はなくてもエンジニアであればキャッチアップしながら誰もができる内容で、数値としては十分に意味のある成果が挙がる部分なんだと感じます。（半野晒し状態で改善幅が大きくあったということもありますが、、、）
ここを担ってやっていこう！という人がたまたま周りに少ないので全体的にはどうなのか分かりませんが、ぜひ専門性に関わらず課題を抱えていそうであれば目を向けてみるのもありなんじゃないかなと思います。

獲得した付随効果

今回の対応はアーキテクチャ改善を伴いリソース自体の削除も多くしたので、各サービスの管理画面がかなりスッキリしました。棚卸をしていく中で気付いたのですが、整理整頓されていると管理における認知の負荷が減り、状態を維持しやすくなると感じています。
最初は見落としていた不要なインスタンスも、棚卸し後にパッと管理画面を見直していたら不要なものとしてすぐ見つかったということがありました。

これから考えていること

モニタリングと、継続をしていくこと

コスト改善をしていく最中、以下のようなAWS側のサポートや料金体系の変更により部分的にコストが上がってしまった部分もあるので、まだまだ事前に対応するという流れを組織に作れていない状態になります。

• パブリック IPv4 アドレスの利用に対する新しい料金体系を発表
• MySQL 5.7 および PostgreSQL 1.1 データベースが Amazon RDS 延長サポートに自動登録されます
• Kubernetes バージョンに対する Amazon EKS の延長サポートの料金

今回は個人的に対応を進めた部分もありますが、組織としてモニタリングとコストの継続が自然となされるような形を作っていこうと考えています。

容易な管理を目指すこと

現在は棚卸しをした後で、各インスタンスの設定やリソースの予約状態が適切に保たれています。
かなり管理コストも削減できたと感じていますが、まだまだ設定の状態に左右されてしまう部分もあるので容易な管理とは遠いと思っています。
そこを認識の外にして組織が機能開発に注力できる状態を目指していきたいと検討中です。
各サービス選定における要件を満たせば、別のマネージドサービスに載せ替えることも視野に入れて向かっていこうと思います。