AB180開発チームのAWSコスト管理の歩み:請求書確認からFinOps文化まで
(engineering.ab180.co)Geminiで要約しました。
--
膨大なデータを処理するマーケティング成果測定ソリューション「Airbridge」を運営しながら、体系的なAWSコスト管理(FinOps)文化を築いてきました。その過程で得た経験とノウハウを共有します。
AB180のコスト管理運用方式:
私たちはコストを「管理」するために、次のようなプロセスを運用しています。
- Googleスプレッドシートベースのダッシュボード: データを簡単に加工・共有できるGoogleスプレッドシートを活用してダッシュボードを構築しました。タグ別のコスト状況はもちろん、コストに直接影響するデータ収集量まであわせて表示し、変動の原因を直感的に把握できます。また、Savings Planのカバレッジ状況を可視化し、契約変更時の結果を事前にシミュレーションして、合理的な意思決定を支援します。
- 定期的かつ自動化されたコスト点検: 2週間に1回、30分前後の短いミーティングでコストの変動事項を点検します。ミーティング資料の作成、Slack通知、議事録作成などの反復業務は可能な限り自動化して効率を高めました。コスト変動が大きい場合は担当者がGoogleスプレッドシートのコメントで原因を分析・共有し、透明性を確保します。
- 開発前の想定コスト算出: 新機能の開発やアーキテクチャ変更時には、「Tech Spec」文書に想定コストを算出することを必須にしました。これにより、開発段階からコストを考慮したより良い技術的意思決定が可能になります。
コスト管理システムの高度化プロセス:
現在のシステムは一朝一夕で作られたものではありません。次のような段階を経て発展しました。
- Phase 0(請求書確認): 当初は毎月請求書を確認するレベルにとどまっていました。
- Phase 1(最低限の分類): Nameタグを活用してリソースを最低限分類し始めました。
- Phase 2(タグ戦略の高度化): Team、Serviceなど明確なポリシーに基づくタグ戦略を策定しました。ガイドの配布だけでは不十分だったため、IAMポリシーと連動してタグ設定を強制し、タグのないリソースにはSlackボットで自動通知を送るメカニズムを構築しました。その結果、タグのないリソースのコストを全体の1%未満に抑えられるようになりました。
これまでの歩みで得た5つの教訓:
- 状況に合ったエンジニアリングが重要です。コスト統制のための完璧なシステムを目指すよりも、会社の規模や状況に合った「適切な」レベルの管理体制を段階的に構築する方が賢明です。
- コストの「統制」と「最適化」は別物です。コストの予測可能性を高める「統制」と、コスト自体を削減する「最適化」は明確に異なります。状況の優先順位に応じて、何に集中するかを決める必要があります。
- 思い切って自動化すべきです。単純な反復業務を自動化するだけでなく、同僚が自らデータを参照して問題を把握できる「セルフサービス(Self-serve)」環境を構築すれば、生産性を最大化できます。
- 「メカニズム」を作るべきです。"タグをきちんと付けよう"と言う代わりに、タグがなければリソース権限が付与されないように、ポリシーに従わざるを得ない「仕組み(メカニズム)」を設計することが効果的です。
- FinOpsは結局「文化」です。コスト管理が特定担当者の仕事ではなく、プロダクトを作る全員の責任だという認識が根付くよう、継続的に取り組み、文化を作っていくことが最も重要です。
5件のコメント
おお…まずは最も基本的なTagだけでも付けておけば、ある程度は何とかなりそうですね… :)
ただ、RIやSPのようなものを使って削減するのは、基本として入ってくるものなのでしょうか……
どの程度のサイズを自分たちのインフラで使うべきかは、かなり悩む部分ではありますね…
本文でも触れられている内容ですが、私は別途 SP シミュレーターを作って、直近 n 日間のワークロードをもとに、ここでどれだけ SP を追加購入すれば「既存コスト + カバーされて削減されるコスト + Recurring になって無駄になるコスト」が最も小さくなるかを計算し、それをもとに意思決定していました。
現職の AWS Korea 在職者です。
入社後に最も重要だと聞かされる研修の一つに、顧客がクラウド費用をより少なく使える方法を考えるというものがありますが、最も効果的な方法の一つとして RI と SP を案内しています。
料金を下げてください..
RIはともかく、SPの場合はいくつかのワークロードに適用できるので、固定で出ていくコストがあるなら十分に検討する価値があります。実際、私たちは想定される最適化の時期まで見越して購入したこともありました……(笑) たとえば9か月後には最適化が完了してサーバー費が半分に減りそうだとしても、それでも1年分を買っておくほうが得なら買う、という感じです。