概要
- 減らせるコストは1円でも減らしたほうがよい（スタートアップだとなおさら）
- けれども日常的にコストを意識して、アクションを継続することは非常に難しい
- クラウドFinOps 第2版にも書かれているが、それが自分の仕事である、自分の優先すべきミッションの一部である、ということに違和感を覚えるケースも多いためだと思う（すごくよくわかる）
- 今のコスト状況の良し悪しを、どう構造化して判断していくか、という難しさもある
- ピボット中でかつ正社員エンジニアが7名しかいなかった弊社で、どう取り組んで少しづつレベルアップしたか、参考になる事例もあると思い記載する
成果の概要
- 取組期間：2024年04月～2025年06月の15ヶ月（継続中）
- 人数：6-7名。CTO 1名、EM 2名、Engineer 3-4名
- 削減額：24/04➝25/04でインフラコストを維持 ※APIリクエスト数は370%増加したが維持
ステップアップの流れ
以下のように進行した。
- 精査
- 初期アクション
- 実額可視化と、着地予想の週次トラッキング運用
- 単価の可視化と、日次トラッキング運用
なかなか時間をとりにくいなかで、効果が大きい部分から少しづつ進めていき、実践方法がレベルアップしていった。取り組み順に記載する。
各ステップの詳細
精査
2024/04頃実施。専任者はいない中で以下のように精査を進めた。
- Google Cloudなどの特に費用が大きいものについて、その中の個別の費目をみていった
- 見る目的は、現状認識と削減候補の分類
- どうやって、何をみたか
- Google Cloudについては、プロジェクトごと、サービスごと(BigQeury, Spannerなど）のコストをコンソールのBillingから様々な切り口でみれるので、それを見ていった
-
日付 > サービスと月 > サービスをよく見た - 具体的には以下を見ていった
- 不要だと分かるものを見つけていく
- 必要か不要かわからないもの（どこで使っているのか分からない、必要なのか自信がない）を見つけていく（1円でもかかっていたらリストアップ）
- コスト増加が日時や月次で急すぎるもの（事業成長より明らかに急なもの）を見つけていく
- 月単位で大きいものベスト5を見つけていく
- Google Cloudについては、プロジェクトごと、サービスごと(BigQeury, Spannerなど）のコストをコンソールのBillingから様々な切り口でみれるので、それを見ていった
- やらなくて良いこと
- コンソールではSKUごとのコストも見れるが、初期の精査ではSKUごとはあまり深くみなくても良かったと思っている
- 情報過多で見ても処理しきれなかったため
- TIPS
- 金額が大きいサービスなのに利用箇所が分からない、なども意外とでてくる
- LLMに、何で使われる可能性があるサービスか聞くと、意外とわかったりする
初期アクション
精査したうえで、アクションをどう定めたか。
不要だと分かるものに対して。
- 「止めたい、terraform書いて…！」をお願いしていく
- 初期は、不要かつしかもすぐ止められるものが意外と多い
- しかもチリツモで意外と大きな削減効果になるので、これはすぐにやりきった方が良い
必要か不要かわからないものに対して。
- 色々でてくると思う
- 謎のストレージ費用、謎のインスタンス費用、謎のネットワーク費用、謎の個人開発プロジェクトっぽいもの、開発環境利用のはずだから多分止めて平気な気がするけど少し不安なDBインスタンス、etc
- 聞いてみると不要と判断できるものも意外とでてくるので、費目が大きいものに対しては以下を優先してアクションする
- 確認可能なメンバーがいる場合は聞いて、不要なら「止めたい、terraform書いて…！」をお願いしていく
- 聞けるメンバーがいないが、リスクが著しく低いと想定されるものは、とりあえず止めてみる
- 止めて騒ぎ出せば戻す、何もおこならければそのまま、という方式
- 判断が難しいものは、数カ月間など継続ウォッチしていく
- ウォッチしていく中でわかることがかなりあるため
- この費用は昨日変化した、あれやったからか、ということはあの費目なんだ！などは意外と多く起こる
- 不明で費目が小さいものについては、緊急度は下げつつ、上記のようにして全て潰した方が良い
- 不明なものが残っていると、それは管理不能領域になってしまうため
- そしていつか、そのコストが徐々に大きくなっていくため
- 不要か否かの判断に迷う場合
- コスト削減が急務なら、できれば残したい、のようなものは、一旦消す、と判断していくのが良い
コスト増加が月次、日次で急なものに対して。
- もし事業が成長していて、それよりも非線形に増加していて、かつ費目が事業規模に対して大きくなりそうなら、緊急で対応していく必要あり
- その費目は何が原因で非線形になっているのか、どうすれば対応できるのか、調査する人をアサインする
- カウシェの場合はFirestore、CDN、BigQeuryがこれに該当し、これにどう対応したかの概要は後述で少し触れる
大きな費目ベスト5に対して。
- 大きいだけに削減余地もあることが多く、深ぼる
- 費目の具体どこにコストかかっているのか、SKU単位、プロジェクト単位で見ていく
- 意外と、不要なプロジェクトでの利用があったり、ストレージやインスタンスのスペック変更余地、バックアップ期間の短縮余地、不要データ削除してストレージ空ける余地、ライフサイクルの設定余地などがあったりする
- それはひとまず見つかり次第なるはやで変更等を行う
- そのうえで、日次などでSKUやプロジェクト単位で金額の上がり下がりの動向を見ておくと良い
- ある日変化したときに、その変化理由に検討がついて、思わぬ削減余地が見つかったりする
実額可視化と、着地予想の週次トラッキング運用
2024/6頃から実施。
- 毎週月曜に、その月のその日までの実額と、月末にいくらになる予想か、を出すようにした
- また予想は、予算に対してどの程度乖離するのか、を出すようにした
- これは非常に強力だった
- 着地予想が変わる、ということが頻繁にあった
- なぜ変化したのか、を探っていく動きが定着した
- スプレッドシートで、いくつか入力すると月末予想がでてくるものを作って運用した
- 予測といってもただのオリジナル関数だし、費目別ではなく総額しか予測しないのだが、それでも非常に強力だった
- というのも、なんとなくコスト増えたな、ではなく、着地大きくオーバーしてやばい増え方だ、というのが手前で分かり、調査アクションの必要性を明確に判断できる、というのが強力だったため
- シートを改善して予測精度を上げる調整をしていった（といってもパラメタの微調整だが）
- 毎週、毎日見ていく中で、不明だったコストが明らかになったり、費目ベスト5の削減余地が見つかることも多かった
- 一番最初期に作って運用していたシートは以下のようなものだった
単価の可視化と日次トラッキング
2024/11頃から実施。それまでの週次での総額トラッキングと着地予測だと、課題があった
- 課題は2つ
- 週次トラッキングだと検知と対応が遅れる
- 今週で着地予想変わったけど、どの日に変わったんだ？今週コスト影響あること何かしたっけ？覚えてない… などが起こる
- 総額だと、増えた本当の要因を見逃しやすい
- トラフィックが常に増えていたので「ああ今日もコスト少し増えたんだね」と思っていたら、本当の理由はインフラリソースの利用方法が意図しないものに変わっていた、などが度々あった
- 週次トラッキングだと検知と対応が遅れる
- なので単価での日次トラッキングを開始した
- これは革命的だった
- 単価の定義は詳細を控えるが、イメージとしては「その日のインフラコスト総額 / その日のトラフィック総数」のようなものを単価としていた
- つまり
トラフィックあたりのインフラコストのようなものを単価としていた- 単価は「流入UUあたりのインフラコスト」など、事業構造、コスト構造によって適したものがあるはずで、どう選ぶかは重要
- インフラ費用に相関しやすいもの、かつ、事業成長に相関しやすいものを選ぶと良いはず
- 適切と思われるものを一旦定めて運用開始してみる、というのが良いと思う
- 単価はFirestore、Spanner、BigQuery、Cloud Runなどのサービスごとに、スプレッドシートに出すようにした
- かつ、日次で出すようにした
- CTOやEMは毎日このシートを見るようになった
- また、CTO、EM、リード陣の週次定例でも確認するようにした
- 「トラフィックは変わってないけど、昨日、明らかにこの単価増えているぞ、何やったっけ？」など、原因究明を非常に的確に、かつ即できるようになった
- 副次的な効果として、単価が明らかに変わったものの原因を調査したらユーザー影響のあるバグを見つけられたなどもあった（意図しない環境を参照していて、CDN経由してない環境だったため、コスト増していた、など）
- 月の着地予測シートのフォーマット例（それぞれ総額、単価）
- 日次で見ているシートのフォーマット例（それぞれ総額、単価）
非線形に増加する費目への対応
初期アクションで見つかった非線形に増加する費目に対しては、以下のように対応していた。緊急度は高いが根本解決は容易ではないケースもでてくる。基本は専任者をアサインして調査・対応をしていく、という形になる。
Firestore
- 弊社の場合だと、Readがとにかく激増していた
-
トラフィック伸びて嬉しい悲鳴だねなどとは言ってられない状態になっていた - 施策リリースのたびにFirestoreのコストがべースアップしていた
- 圧倒的 No1費目となっていた
- MobileからのAPI呼び出し方法を変える、Firestoreへのクエリ発行方法を変える、メモリレイヤでのキャッシュを行うなど、比較的簡易対応できる実装を足元で続けていた
- それはそれでかなり効果があったが、嫌な開発工数の取られ方だった
- Firestoreの開発者体験が悪くなってきたという課題が以前からあったのと（これは弊社における使い方、設計の問題が大きい）、コストが重いという課題も顕在化したため、FirestoreからSpannerへのDB移行を決めた（1年間かけてほぼ完了した）
- DB移行のような、抜本的な対応を取るのは難しいケースが多いと思う
- そこまでしなくとも、調査と深堀りで見つかる解消可能なボトルネックも多かった
CDN
- CDNやクライアントの設定の見直し、不要なリクエストの削減などの足元活動を行った
- それに加えて、従量課金から定額課金へのプラン変更を行った
BigQeury
- BigQueryは主に分析用途で使っていたので、基本的には社員数に応じて増えるもの、と解釈していた
- しかし、社員数が大きく変わっていないのに、BigQeuryコストの増えが明らかにベースアップを繰り返し始めていた
- レコメンデーションによる商品フィード機能がリリースされ、ユーザーの増加、つまりデータの増加に対してBigQueryコストが増え始めていた
- 線形ではなく非線形な増え方をしていた
- クエリ改修、ストレージタイプの変更など足元実施しつつ、BigQuery Editionsへの課金体系の変更を行った
- これは専任者をアサインした
- BigQuery Editionsは設定自体は簡単だが、どのプロジェクトにどの容量で設定を行うか、などは最適化を含めて多少の期間が必要だった
- なんだかんだ1-2ヶ月くらいの期間がかかった
- 毎時間定常的にクエリが実行されるようなプロジェクトだと、Editionsの効果は非常に大きいので、おすすめ
その他エピソード
なぜFinOps注力が始まったのか
- きっかけは、事業成長に対して明らかにインフラコストの増加が激しくなり、必要に迫られて、というのが正直なところ
- 継続的なステップアップがされていったのは、インフラコストは管理していくのが当然、という前提がありつつ、以下2つが大きい
- 可視化していくうちに、見るのが習慣化し、改善も習慣化していった
- 毎日みることですぐ異変に気付けるので、毎日みたほうが管理が逆に楽になるし、改善しやすいことに気づいた
- 利益増加にわかりやすくつながるので、結果が出ると楽しい
CUDなど
- 最低でも1年間のコミットが発生するので、事業や財務状況を踏まえて実施している
- コミット額の決め方が難しいが、コンソール上で表示されるシミュレーションだけでなく、個別のシミュレーションを実施して、コミット額を決めたりしている
ちりつもの重要性
- 数千円、数万円レベルの削減もものすごくたくさん出てくる
- コスパが悪く感じてしまうが、意外とチリツモで大きな効果になったりする
- なので小さい費用でも対応していくのが非常に重要だった
推進にあたって
- トップや推進者の必死さは重要
- 数値を毎日、全部見たりして、解像度を一番高く持っておきつつ、具体削減アクションを取っていくのも重要
- その前提があったうえで、日次の可視化、予測値の可視化、週次定例等での確認とアクションの習慣化、などが重要
参考になった考え方
- 良い製品をできる限り安価に供給する、そのために知恵を絞る、という趣旨を、稲盛和夫さんなど、ものづくり領域において伝説的となっている経営者が発言している
- 「お金を払っていただけるようなものを、できるだけ小さい支出で作りあげる」それを考えると、インフラコストを抑える努力ってとても重要だよな、と思えた
まとめ
少しずつでも可視化、予測などを繰り返して改善し、管理方法をレベルアップしていくのが大事だったと思っています。
スプレッドシートの日次での可視化などは、準備も一定必要になるので少し面倒ですが、そこまでやらずとも、週次で総額の可視化と着地予想は比較的すぐ開始できたりします。
管理できる費目、つまり予測ができて変え方がわかる領域を少しづつ増やしていくのが大事だったのだと思います。
クラウドFinOps 第2版に、より体系的な考え方が書かれていますが、以上、カウシェ事例でした！
お知らせ
7/7にイベントも行います、よろしければぜひ！
7/30、8/18にも行いますので、上記同様にこちらもぜひ！
株式会社カウシェのProduct開発チームによる技術ブログです。 「日常に楽しさを」「新しい生活圏のカタチを作る」をミッション・ビジョンに掲げ「誰かと一緒に」を楽しむソーシャルEC、カウシェを開発しています。 enjoy-working.kauche.com
Discussion