SREとソフトウェア開発者を集めた専門チームによる、開発組織全体を巻き込んだコスト削減の取り組み

こんにちは。SREチームの吉澤です。

SREはインフラの専門性を持つため、SREチームのミッションに「インフラコスト削減」も含まれている会社は多いと思います。アンドパッドでも、主にSREチームがインフラコスト削減に取り組んできました。しかし、この取り組みだけでは削減できないコストが見えてきました。

そこでアンドパッドでは、2024年6月から、SREとソフトウェア開発者を集めた専門チームによるインフラコストマネジメントプロジェクトを開始しました。私は、SREチームとの兼務でこのプロジェクトに参加しています。プロジェクト開始から約1年が経過し、すでに大きな成果が出ています。

今回の記事では、このプロジェクトの背景や進め方、そして約1年の経験から学んだことをご紹介します。私と同じように、コスト削減に取り組む方の参考になれば幸いです。

背景
- マルチプロダクト開発とコスト把握の難しさ
- コスト削減に関する過去の施策
インフラコストマネジメントプロジェクト
インフラコストマネジメントプロジェクトの成果
- コスト削減目標の達成
- FinOpsに向けた土台作り
コスト削減の専門チームを1年やってみた感想
今後の展望、FinOpsに向けた取り組み
SRE NEXT 2025のアンドパッドブースのご紹介
We are hiring!

背景

最初に、このプロジェクトを開始することになった背景を説明します。

マルチプロダクト開発とコスト把握の難しさ

アンドパッドでは、マルチプロダクト戦略を迅速に進めるため、多数の開発チームがストリームアラインドチームとして自律した状態を目指しています。横断的な関心事を扱うチーム（SREチームなど）は開発チームと独立し、自律の支援やプラットフォームの提供を行っています。

アンドパッドのプロダクトはAmazon EKS上に構築されており、一部のプロダクトはマイクロサービス化されています。しかし、複数のプロダクトが共有するリソースはまだ多数あり、リソースへのタグ付け（例えばAWSのコスト配分タグ）だけでは、プロダクトとコストの関係を正確に把握できないのが現状です。

コスト削減に関する過去の施策

サービスを構成するプロダクトの増加に伴い、売上とともにインフラコスト（クラウドコスト）も増加しがちです。マルチプロダクト戦略で収益性を高めるためには、サービスを構成するプロダクトが増加しても、売上に対するインフラコストの比率は一定以下に抑えることが望ましいです。

これまでは、主にSREチームがインフラコスト削減に取り組んできました。例えば、以下のような施策を行ってきました。

すでに使わなくなったリソースの棚卸し（例：RDSのインスタンスなど）
利用しているサービスのボリュームディスカウント契約（例：AWSのリザーブドインスタンスやSavings Plansなど）
VPCエンドポイントの設定などの、ネットワーク構成の見直し
アプリケーションが出力するログ量の抑制

上記は、ほとんどがインフラで完結する施策です。しかし、複数のプロダクトの深い知識を必要としたり、大規模なプロダクトの修正を必要とする施策は、SREチームではなかなか実施できていませんでした。

インフラコストマネジメントプロジェクト

このような背景をもとに、アンドパッドでは、2024年6月にインフラコストマネジメントプロジェクト（以下、プロジェクト）を開始しました。

プロジェクト開始当初は困難もありましたが、最終的には、SREチームだけでインフラコスト削減に取り組むよりも、広範囲なコスト削減を実現できました。

プロジェクトの目的、メンバー、期間

プロジェクトの目的は「インフラコスト削減」にフォーカスし、その目標は「売上に対するインフラコストの比率を目標値以下に減らすこと」と明確に定義されました。開発チーム自身がコスト削減に取り組むための仕組み（コスト可視化など）についても議論されましたが、最終的には今回の目的には含まないことになりました。

プロジェクトのメンバーには、インフラに詳しいSREと、プロダクトに詳しいソフトウェア開発者の両方が集められました。これは、プロジェクトの背景に「SREチームだけで出来るコスト削減はかなり進んでおり、これ以上はプロダクトの修正が必要」という課題意識があったためです。

SREチームからは私が参加し、ソフトウェア開発者は1〜2名（時期によって変動あり）が専任で参加しました。特に、ソフトウェア開発者のうち1名は、社内でプロダクト開発を約5年経験している、社歴の長いエンジニアである川原に参加してもらいました。もう一名は、Rubyのスペシャリストである大崎に、主にS3上の大量のオブジェクトを処理するプログラムの開発で参加してもらいました。

プロジェクト開始時点で、おそらくこうすればコスト削減できるだろうという大まかなアイディアはいくつか挙がっていたのですが、その実現可能性や妥当性は未検証でした。そこで、プロジェクトの期間は、まず半年やってみて、その時点の成果を見て継続するかどうか判断する。そして、その後も半年ごとに判断する、ということになりました。

プロジェクトの立ち上げ

最初の1〜2ヶ月は、プロジェクトの立ち上げのために、以下の活動を行いました。

問題の理解
コストの高いサービスの発見
課題発見のためのコスト分析と議論

問題の理解

まず、問題の理解のために、経営層から見えている売上とインフラコストに関する情報の共有を受けました。そして、この情報についての理解を深めながら、上長およびチームメンバーとプロジェクトの目標について話し合いました。このなかで、このプロジェクトでは「インフラコスト削減」にフォーカスすることが、チーム内で合意されました。

経営層から見ると、AWSやGoogle Cloudの費用が大きい一方、その費用をプロダクトごとに仕分けするのは難しく、削減余地がわかりにくい状態でした。そのため、この削減余地を明確化することも私たちの課題でした。

コストに占める割合の高いサービスの発見

削減余地の大きな箇所を特定するために、私たちは次に、コストに占める割合の高いサービスの発見に取り組みました。

アンドパッドは主にAWSを利用しているため、Cost Explorerを用いて、サービス（Cost Explorer上の選択できるサービス。"S3" や "Relational Database Service (RDS)" など）ごとのコストを確認しました。ただし、過去のデータには特別な理由（インフラ増強や大口顧客のデータインポートなど）による増加も含まれるため、それらを考慮して、各サービスの割合を集計しました。

課題発見のためのコスト分析と議論

そして、この集計で上位に挙がったサービスについて使用タイプ単位のデータを分析し、コストに占める割合が高い理由と、プロダクトの変更を含むコスト削減施策をマッピングしました。その後、それぞれの施策のコスト削減効果（金額）を見積もりました。

当時は、S3に最もコスト削減余地があると予想し、Miroで以下のグラフを描きながら詳しく分析しました。「特定の使用タイプのコストが高い理由」と「コスト削減施策」の関係は必ずしも一対一対応ではないため、このグラフを使って議論して、わからないところが出てきたら追加調査してまた話し合う、ということを繰り返しました。

プロジェクトメンバーのなかにプロダクトの仕様の理解が深いソフトウェア開発者がいたことで、コスト分析の結果からコストが上がっている原因を推測する際や、その原因に対する対策の実現可能性を評価する際に、大きな助けになりました。その結果、コスト分析〜対策立案のサイクルが加速しました。

このような活動を通して、コスト削減施策の優先度が明確になっていきました。

プロジェクトの立ち上げ当初の困難

プロジェクトの立ち上げ時には、SREとソフトウェア開発者の間での、知識や常識の差によるコミュニケーションの齟齬や衝突がよくありました。

現在のインフラ構成や、クラウドサービスおよびそのコストについては、通常SREのほうが詳しい立場にあります。SREは日常的にクラウドサービスを触っているため、例えばAWSのCost Explorerやリザーブドインスタンスなどの知識をあらかじめ持っています。しかし、専任のSREがいる会社では、ソフトウェア開発者はこれらの知識を持たないほうが普通です。立ち上げ当初は、この知識差を埋めるためのコミュニケーションに多くの時間が必要でした。

また、私のプロダクト理解が不足しているために、お互いの意見が合わずに衝突した場面もありました。例えば、私からすれば簡単そうに見えるプロダクトの修正が、プロダクトに詳しいソフトウェア開発者から見ると影響範囲が広かったり、過去の歴史的経緯から考えて簡単ではないといったことがありました。

対策として、立ち上げ時期には「お互い納得できるまでコミュニケーションの時間を十分取ること」と「口頭での説明が難しい場合は資料を用意してから改めて話すこと」を心がけました。その結果、最初の1〜2ヶ月で、そのような齟齬や衝突は徐々に減っていったように思います。

プロジェクトの進め方

最初の1〜2ヶ月の立ち上げ期間が終わってからは、「コスト削減施策の推進」と「日常的なコスト確認」の2本柱でプロジェクトを進めました。

コスト削減施策については、基本的には、立ち上げ時期に決めた優先度に基づいて進めました。ただし、プロジェクトを進めながら知識が深まった結果、新たな課題が見つかったり、よりよい方法が思いつくこともありました。その際は、目標であるコスト削減を最優先し、優先度を柔軟に見直しました。

日常的なコスト確認については、月単位および週単位で確認しました。

毎月の確認
- アンドパッドはAWSのエンタープライズサポート契約を結んでいるため、TAM（Technical Account Manager）と毎月定例を行っている。この定例でTAMからコストレビューの結果を受け取り、そのなかに自分たちが把握していないコスト増があれば調査する
毎週の確認
- 毎週、チーム内で「コストダッシュボードを眺める会」を開催し、その中で全員がそれぞれの画面でCost Explorerを開き、直近のコスト変化を確認する。各自、気になるところが見つかったら自分の画面を共有し、その変化の理由について話し合う

プロジェクト開始当初は、コスト削減施策の推進を優先し、毎月の確認しかしていませんでした。しかし、日常的なコスト確認によって急激なコスト増を発見し、プロジェクトで早期解決する、ということを繰り返した結果、日常的なコスト確認の比重が高くなりました。このことは、後述する「コスト版ポストモーテム」の話にも繋がっています。

開発組織全体を巻き込むハブとしての役割

このプロジェクトが開発組織全体を巻き込むハブとして機能することで、施策のトライアンドエラーのサイクルを早めることができました。

前述の通り、このプロジェクトでは、プロダクトの修正を必要とするコスト削減施策に取り組みました。

プロダクトのコード修正はプロジェクト内のメンバーが実施して、PRを送ることができます。しかし、そのテストやリリースを考えると、そのプロダクトを担当する開発チームとの連携がどうしても必要になります。また、製品仕様の変更を伴う場合は、プロダクトオーナーやCREチームとの調整も必要です。加えて、1つのコスト削減施策のために、複数の開発チームにまたがった連携が必要になる場合もあります。

SREだけではこのような連携は難しかったと思います。しかし、プロジェクト内に、各開発チームのキーパーソンや開発の進め方、リリースプロセスなどを理解しているソフトウェア開発者がいることで、開発チームとの連携を迅速に行うことができました。

また、この記事のチーム内レビュー時に、ソフトウェア開発者の側が感じていたメリットも教えてもらえました。SREがいることでインフラに関する連携が容易だったことに加えて、サイト信頼性観点であらかじめインフラに関する懸念点が明らかになるため、SREと一緒にアーキテクチャを考えられるのは大きなメリットだった、とのことでした。

インフラコストマネジメントプロジェクトの成果

2024年6月のプロジェクト開始から約1年が経過しました。SREとソフトウェア開発者が協力することで、当初の予想よりも大きな成果が出ています。

コスト削減目標の達成

複数のコスト削減施策の積み重ねにより、売上に対するインフラコストの比率を目標値以下に削減できました。具体的な削減額はご紹介できませんが、この成果によりFY24の全社表彰で「Best Performance Team賞」（特に目覚ましい成果を上げたチームを称える賞）を受賞しました。まだコスト削減の余地は残っているため、目標達成後もさらなるコスト削減を進めています。

プロダクトの修正が必要な施策のうち、一番大きいものはS3に対する改善でした。アンドパッドは応答時間の短縮のため、顧客からアップロードされた写真に対して、複数のサイズのサムネイル画像を自動生成しています。以下の修正を行い、このコストを大幅に削減しました。

写真およびサムネイル画像の配布を、S3バケットから直接行う方式から、CloudFront経由で行う方式に変更
- この変更によるコスト増は、CloudFrontのボリュームディスカウント契約を締結することで解決
サムネイル画像のうち、現在はどこからも参照されていないサイズ2種類を特定して、生成を停止し、過去分を削除
サムネイル画像のうち、アクセス頻度が低い2種類を特定して、CloudFrontの機能（Lambda@Edge）でアドホックに生成する仕組みへと変更し、過去分を削除（現在進行中）

S3以外では、Google Cloud APIの呼び出し回数を減らすようにプロダクトを修正し、APIリクエスト料金を削減しました。

また、プロジェクトを進めるなかで、インフラだけでほぼ完結する施策のアイディアも多数生まれ、さらにコスト削減を実施できました。以下はその一例です。

ボリュームディスカウント契約の見直し（Savings Plansの最適化など）
S3バケット上の不要なファイルの削除、およびライフサイクルルールの設定
過去に付与された、不要なS3オブジェクトタグの削除
Aurora MySQLクラスタのI/O料金の削減（インスタンスタイプの見直し、またはI/O-Optimizedの導入）
Aurora MySQLクラスタの監査ログの取得量の調整

FinOpsに向けた土台作り

このプロジェクトでは、コスト面で問題のある実装がユーザーの増加に応じて顕在化し、多額の不必要なコストが発生するという問題に何度か対応しました。その経験から、類似の問題を未然に防ぐために、過去に起こった問題を分析して開発組織全体の学びにする必要がある、という課題意識を持ち始めました。

SREの分野には、過去のインシデントから学びを得るための「ポストモーテム（ポストインシデントレビュー）」というプラクティスがあります。アンドパッドでは、CREチームを主体としてポストモーテムを運用しています。以下は、CREチームによる過去のテックブログ記事です。

私はSREとしての自然な発想から、コストについても同様の取り組みが有効かもしれないと考えました。そこで「コスト版ポストモーテム」というものを提案し、社内での導入を進めています。名前には悩んだのですが、アンドパッドはすでにポストモーテムを実践しているため、ポストモーテムを知っている人にとって理解しやすいように、このように名付けました。

パイロット版として、上記の「どこからも参照されていないサイズのサムネイルがあった」問題についてコスト版ポストモーテムを1件執筆し、開発本部全体に向けた説明と、アンケートの募集を行いました。その後、実際に発生した急激なコスト増に対応する際に、コスト版ポストモーテムを開発チームと共同で執筆してみて、問題の分析・共有に有効であるという手応えを得ました。

このコスト版ポストモーテムについては、もう少し社内での導入が進んだら、このテックブログにて詳細をご紹介します。ご期待ください。

コスト削減の専門チームを1年やってみた感想

このようなコスト削減の専門チームを1年やってみて、SREの立場から強く感じたのは、以下の3点でした。

プロダクトに詳しいソフトウェア開発者がコスト削減に協力する効果は大きい

インフラやコストの知識を持つSREが、プロダクトに詳しいソフトウェア開発者と一緒に働くことには、大きく2つのメリットがありました。

1つはコスト分析および対策立案のフェーズでのメリットです。プロダクトの仕様の理解が深いため、コスト分析の結果からコストが上がっている原因を推測する際や、その原因に対する対策の実現可能性を評価する際に、大きな助けになりました。その結果、コスト分析〜対策立案のサイクルが加速しました。

もう1つは対策実施のフェーズでのメリットです。各開発チームのキーパーソンや開発の進め方、リリースプロセスなどを理解しているため、開発チームへの修正依頼を迅速に行うことができ、場合によっては専門チームでリリースも担当できました。これにより、施策のトライアンドエラーのサイクルが加速しました。

コスト削減に専念できる時間と、深い議論のできる相手が必要

このプロジェクトは「SREチームだけで出来るコスト削減はかなり進んでおり、これ以上はプロダクトの修正が必要」という課題意識から始まりました。しかし、プロジェクトを始めてみると当初の予想に反して、インフラだけでほぼ完結する施策のアイディアが多数出てきました。

なぜでしょうか？振り返って考えてみると、理由は2つあるように思います。

その1つは、コスト削減に専念できる時間が増えたことです。SREチームにとってはコスト削減は数ある業務の1つのため、コスト削減のアイディアを思いついても、実現可能性の検討や、コスト削減効果の試算を十分に行えていませんでした。

もう1つは、コストについて深い議論のできる相手ができたことです。チームでコストを定期的に確認しているため、いまではチームメンバーは普段のコストが頭に入っている状態です。そのようなメンバー同士でコスト削減について話し合うことで、予想外な気づきが増えたと感じています。

クラウドサービスのコストや、コスト可視化ツールの正確な理解が必要

コスト削減施策を考え始めると、大小問わず、アイディアはたくさん思いつきます。しかし、そのなかからコスト削減効果の高いアイディアを正しく選ばないと、時間をかけても「事前の予想ほどコストが減っていない」という結果になってしまいます。

そして、コスト削減効果を正確に見積もるためには、クラウドサービスのコストや、コスト可視化ツール（AWSのCost Explorerなど）の使い方やクセについての正しい理解が必要です。また、理解が不足していると、コスト削減施策を実施してもその前後の変化を正しく評価できません。

私はSREなので、チームの中ではこれらの知識を持っているほうでしたが、このプロジェクトのなかでいろいろな知識不足に気付かされました。AWSについては、料金に関する大量の質問をAWSサポートに送りました（いつもお世話になっております）。AWSのコスト削減に取り組む際には、AWSサポートの力を借りることが重要と考えます。

今後の展望、FinOpsに向けた取り組み

このプロジェクトは、売上に対するインフラコストの比率を目標値以下に減らすという目標を達成し、一旦の区切りを迎えました。

このプロジェクトを開始した当初は、目標を達成したらプロジェクトを解散し、再びSREチームがインフラコスト削減に取り組むようになる予定でした。しかしこのプロジェクトが成功したことで、コスト削減に責任を持つチームの必要性が開発組織内で認識されました。また、コスト版ポストモーテムの活動を通して、開発チームもコストを意識する必要がある、という認識も広まりつつあります。

今後は、いわゆるFinOpsを徐々に開発組織に取り入れていきたいと考えています。これをどのように実現するか、組織づくりも含めた、面白いフェーズに入ろうとしています。その結果は、随時このテックブログでご報告できたらと思います。