【AWSコスト最適化】ひょんなことからAWSコストの最適化に取り組んだら、どえらいコスト削減できた話（削減率: 37%）

この記事は、Ateam LifeDesign Advent Calendar 2024 の 13日目 の記事になります。

はじめに

こんにちは！エイチームライフデザインの後藤です。
私は基盤技術グループという組織横断型チームに所属しており、

• ストリームアラインドチームに対するインフラ、システム監視における技術支援
• オブザーバビリティ向上のための環境整備
  • 参考: New Relicを活用したシステム監視の強化とオブザーバビリティ向上 - Speaker Deck

等々に日々取り組んでいます。

本記事では、今年ひょんなことから取り組むことになった、弊社のとある事業におけるAWSコストの最適化についてご紹介させていただきます。

「これだけのコストを最適化するために、こういうことをやりました！」という具体にフォーカスした内容ではなく、

• 様々な要因によって高コストな状態が続いてしまった失敗事例の紹介
• そうなってしまった原因の分析
• 今後同じことを起こさないようにするための対策

以上についての紹介が主な内容となっております。🙏

きっかけ

そう、それは唐突に...。
「事業Aのインフラ費用がn年でx倍になっている！」
という話を耳にしました。

特にAWS費用の肥大化に関しては以前から指摘されており、都度調査されていたようですが、効果的な対策を打てていない状況でした。

そんなところで私に声が掛かり、いざ調査＆対応の旅へ出ることになりました。✊

現状調査

過去に当該事業を担当していたことから、AWS上の構成については大体把握しており、ドメイン知識も多少ではありますが記憶に残っていました。
調査に与えられた時間は多くなかったため、頭の中にシステム構成図を描きつつ、Cost Explorerと請求書を確認していきます。

確認していく中で感じた「違和感」を頼りに、

• 問題点であろう箇所の洗い出し
• 現状の費用を確認
• 問題を解決したらどれくらい削減できそうかを算出
• 対応難易度、対応工数の設定

を進めていきました。

あれよあれよと、改善できそうなポイントが洗い出されていきます。
あまりの多さに、ちょっとテンションが上がってきて楽しくなってしまったのは内緒です。

対応方針

一通り洗い出したところで、工数の掛かるアーキテクチャレベルの最適化をやらずとも、クイックウィン最適化により短期間で相当な効果を出せる見込みが立ちました。

いい機会なので抜本的に見直しを行いたかったところではありますが、今回は クイックウィン最適化 によって解決できる問題にフォーカスして対応を進める方針としました。

「クイックウィン最適化」とは、即効性のあるコスト最適化手法のことです。

引用元: AWS でのコスト最適化の進め方 第 3 回 ~ 短期的なコスト削減施策と中長期的なコスト最適化施策 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

Point!
結局のところ、AWSのコストが高ければ高いほど、事業の利益を食い潰してしまいます。
その状況が続けば続くだけ、事業的にももったいない状況が続いてしまうのです。

「抜本的に見直したい...」という気持ちは抑えつつ、短期集中で大きな効果を得るため、クイックウィン最適化を主とする方針に舵を切りました。

実際に行った対応

サマリーレベルの内容ですが以下に取り組み、対応項目としては100程度に上りました。
ガッツリ系からチリツモ系まで、様々です。

Point!
特にポイントだ！と思ったものには をつけています

• 不要なリソースの削除
• 過剰な冗長構成の見直し
  • ELBのAZ数見直し
    • パブリックサブネットに配置されているELBにおいては、AZ数を見直すだけでPublic IPv4 Addressの課金を減らすことが可能
  • ECSのタスク数見直し
• 過剰なリソース割り当ての見直し
  • EC2, RDS, ECS等
• インスタンスタイプ等の最新化
  • マネージドサービスは基本Graviton化
  • EBSをgp3に徹底
• 監視系の機能の設定見直し
  • 不要なContainer Insights等を無効化
• 開発環境、Staging環境の夜間、休日停止運用
  • 仮に「平日10時間起動、土日は起動しない」とするだけで、コストは 30% まで程度に抑えられます
• バックアップポリシーの見直し
  • 特にRDSのスナップショット
    • ストレージサイズが大きいほどスナップショットの課金も嵩む
    • さらに保持世代数が多いほどコストは非常に大きくなる

対応による効果

具体的な金額はお伝えできませんが、最終的な削減率は　37%　となりました！
万$単位の費用が発生しているAWSアカウントだったため、削減金額としては非常な大きなものでした🎊
（※ドルベースでの削減率です。）

また本取り組みは調査から対応までで、30営業日ほどで完了しています。
工数対効果も良かったのではないでしょうか。

めでたし、めでたし！

問題の分析

...とはならず。

同じことを繰り返さないためにも対策を打つべく、なぜこのような状況に陥ってしまったのかを分析していきます。
ここからが重要です。👆

なぜ、コストが肥大化してしまったのか

結論としては 「基本的なシステム運用業務の滞り」 が主な原因でした。

調査前は、

「当該事業のシステムの規模やAWSのリソース数的にも、アーキテクチャ変更を伴う抜本的な見直しが必要かな〜」

と、ぼんやり思っていましたが...。
もちろんそのレベルの問題はありつつも、多くは基本的なシステム運用業務の滞りに起因する問題ばかりでした。

補足: 「基本的なシステム運用業務」とは

一例として、

• 不要なリソースの削除
  • 既に使用されていない開発環境が残り続けている
  • 用途不明のバックアップ、スナップショットが残り続けている
• コンピューティングリソースの割り当て見直し
  • システムの負荷やコンピューティングリソースの利用状況に応じたサイジングが実施されていない
  • コスト最適化ハブの推奨事項をベースとした改善アクションが実施されていない
• コストを意識した構成、運用変更
  • 開発環境やStaging環境は平日夜間や休日は利用されていないものの、起動し続けている
  • 古いインスタンスタイプのまま使用され続けている

といった、 クラウドサービスを利用する上で意識しておきたい「コスト観点での運用業務」 を指します。

なぜ、基本的なシステム運用業務が出来ていなかったのか

「基本的なシステム運用業務が出来ていなかったことが、コストの肥大化に繋がっている」を、もう少し掘り下げていきます。

「出来ていなかった」を分解

以下のように、時間面とスキル面から来る二軸で掘り下げていきます。

• そもそも、対策を打つための時間がなかった？（時間的要因）
• そもそも、何が問題なのかを認識できていなかった？（スキル的要因）

そもそも、対策を打つための時間がなかった？

当該事業を担当するチームは、弊社の他事業を担当するチームよりも持ち物（インフラの規模やリポジトリ数）が多いという背景があります。

インフラ業務を担当していた方々の入れ替わりも相次いでいたことから、単純にマンパワーが減り、「時間がない」状況になっていることは明白でした。
特にインフラ業務は属人化しがちな傾向にあり、属人化解消が思い通りに進んでいない状況も、より拍車をかけていました。

また弊社では、基本的に全エンジニアがフルスタックエンジニアであり、インフラ専任ではなく開発業務との兼任で担当しています。
事業の開発業務や不具合対応に多くの時間を割かれており、インフラ業務に、特に改善業務に時間を割けていない状況でした。

状況はわかりました。💡
ただ！

• 「基本的なシステム運用業務を行うための工数」が確保されていたのか？
• 「基本的なシステム運用業務を行うための役割設計、体制構築」がされていたのか？

という観点では、大いに改善の余地があると思ったので、そこに対する対策を打つことにしました。

工数が確保されていない業務を遂行することは困難ですし、役割設計や体制構築といった 「チームで業務を回すための土壌が構築されていない状況下」 では、理想的な運用を行うことは困難です。

属人化問題を解消できていなかったとはいえ、　業務が個人に紐付いてしまっている状況は好ましくありません。

Point!
とはいえ、属人化していた "特定の個人" が責められてしまう状況は、何より回避したかったですし、回避できるようにしました。

そもそも、何が問題なのかを認識できていなかった？

チームではAWSのコストが徐々に増加し続けていたことは把握できており、調査も行われていました。
しかし、実際に対応を行うエンジニア（※）のリソースを考慮すると、対応難易度や投入工数から「コスパの悪さ」を感じ、結果チーム内に "腰の重さ" が出てしまい、対応が見送られてしまいました。

※ とあるエンジニアへのインフラ業務の依存度が高い状況でした

しかし！
実際に最適化を行ったところ、コスパは悪いどころかめっちゃいい...。
むしろ、当初の目論見を大きく上回る結果となりました。

調査時のログを確認すると、最大限の削減効果を出すための（最適化対応を行うための） "真因" に辿り着けていなかったのでは？とも受け取れました。
「時間がなく、真因に辿り着くまで調査しきれなかった」という複合的な要因もあるかもしれません。

対策の方針

今後同様の事態に陥らないよう、

• 「時間があれば真因に辿り着けており、効果的なアクションを設定し、対応まで実施できていたのか？」
• 「非効率/過剰な構成や、アーキテクチャの考慮不足、システムのライフサイクルに応じた運用管理（リソースの削除等）を実施する必要がある、という認識はどこまで、どのくらいの重さであったのか？」
• 「上記を実施、認識するためにスキルを伸ばせていたのか？」

について深掘りをしつつ、対策を打つことにしました。

また、「本当に、とあるエンジニアしか実施できなかったのか？」も疑わしいポイントです。
工数対効果も関係するかもしれませんが、とあるエンジニアが実施する前提で話が進んでしまっているのは、 属人化問題が根本にあるから だと見ています。

得られた教訓をもとに、

• 時間が確保されていない
• 特定個人の能力に依存してしまっている
• 特定個人に業務が紐付いている

といった状況を作らず、

• チームとして向き合えている
• 特定個人ではなくチームの持ち物にできている
• 向き合うための時間が確保されている

状況を目指すべく、対策を進めていきました。

実際に行った対策

「基本的なシステム運用業務を行う時間を確保できていなかったことの根底にあるものは何か？」を議論する

「なぜ、基本的なシステム運用業務が出来ていなかったのか」

の章では、あくまで私個人の見解を述べています。

ただこの問題に対して、チームとして向き合ってもらう必要があります。
チーム内で議論を行いつつ、問題を正しく認識してもらい、具体的な対策を開始する前に認識を揃えることにしました。

必要な運用業務を洗い出し、定常業務として組み込む

基本的なシステム運用業務を "毎月の定常業務" とし、月毎に定常運用者を設定して役割として与え、着実に遂行される状況を目指しました。
現時点では定常運用者の設定までは至れていないものの、後述の取り組みによってアクションに繋げられているため、一旦はヨシとしています。

コストへの解像度を上げるための取り組みを実施する

「コストへの解像度を上げるための場づくり」として、毎月1回コストモニタリングを行うことにしました。
「何にどのくらいの費用が発生していて、なぜそれだけかかっているのか」を説明できるように することを目的としています。
結局のところ、コストへの解像度が高ければ、今回の問題の大部分は解決できていたのでは？と思っていたためです。

Point!
なのでただ単にCost Explorerを眺める...ようなものではなく、
コストへの解像度を上げるためのトレーニングの一環として 「モブコスト分析」 という形式で実施しました。

また実施の際には、以下のように「目的」「モチベーション」「Working Agreement」を設定しています。

【実施する目的】

• (1) コストへの解像度を上げ、説明責任を果たせるようにする
  • 稼働するシステムにおいて「何に、どのくらいのコストが掛かっているのか？」
• (2) コスト面の改善に繋げる
  • メンバーの持つ様々な視点、バックグラウンドを活かして「もっとこうすれば、安くできるんじゃない？」といった改善アクションを起こす
• (3) 組織として向き合い、全うできるようにする
  • 参加者全員でコストに向き合うことで、コストの管理・改善を特定個人の役割とするのではなく、組織として向き合えるようにする

【モチベーション】

• (1) コストは事業利益に大きな影響を及ぼす、利益最大化に貢献しよう
  • コストが安くなればなるほど、直接的に利益は増える
  • 逆に、コストが高ければ高いほど、利益は減ってしまう
• (2) 事業開発・運用を担うエンジニアとして、コスト管理は重要な責務である
  • コストに向き合うための業務は開発業務に比べると地味ですし、積み重ねの連続で退屈かもしれない
  • しかし上記の関係性からも、健全な事業運営をしていく上で欠かせない、重要な業務と言える

【Working Agreement】
モブコスト分析をより有益な場にできるよう、Working Agreementを設定します。

• (1) モブコスト分析を通して、参加者全員がコストに対する説明責任を果たせる状態を目指す
  • すぐに、ではなく、何度も繰り返しつつで大丈夫です
• (2) 全員参加型
  • 「どうすれば改善できるか？」を全員で考えましょう
  • 集合知によって、成果に繋げましょう
  • 知識や役割に捉われず全員で向き合い、事業の利益率向上を目指しましょう
• (3) ドメイン と アーキテクチャ を紐付けて考える
  • コストに対して責務を持つのは、インフラエンジニアやSREだけではありません
  • ソフトウェアエンジニアの観点でも、コスト面での改善に大きく貢献できます
    • 非効率な処理や実装は、コンピューティングリソースを圧迫します
    • コンピューティングリソースの利用効率を上げられれば、コスト削減に繋がります
    • そういった視点を持ち、挑んでください
• (4) 「Elephant in the Room」に向き合う
  • （Elephant in the Roomとは、「見て見ぬふりをする」という慣用句です）
  • 分析をしていく上で手を入れにくい（であろう）部分]は出てくると思いますが、見て見ぬふりをせず向き合いましょう
  • 手を入れにくい部分こそ、コスト削減のポテンシャルを秘めています

（Special Thanks）
モブコスト分析に関しては、株式会社DELTA様の事例を大いに参考にさせていただきました。
コスト削減に全員が楽しく参加するための「モブコスト分析」　実践する上で大事な3つのこと | ログミーBusiness

さいごに

いかがでしたでしょうか。
書き終えてみればかなりポエミーな内容になってしまいましたが、私のチームが担当した「AWSコスト最適化」の取り組みを紹介させていただきました。

コスト面の問題を改善したいシーンは多々あると思います。
同様に、問題とその原因においても多々あると思っています。

どこかの現場で、ほんの少しでも参考になっていただければ幸いです。