こんにちは。メルカリ Infrastructure & Procurement Management Teamの＠bungoです。約1年ちょっと前の2021年夏からメルカリにJoinして、エンジニア組織のお金の問題に取り組んでいます。
この記事は、Mercari Advent Calendar 2022 の6日目の記事です。
2022年は円安の影響で、クラウドコストの上昇が想定を大きく上回って大変な一年でした。
この記事では、メルカリグループではどのようにクラウドコストの可視化を行い最適化に取り組んでいるかを、実際に手探りで苦労したポイントを含めながら紹介します。
2022年を振り返ると、現場の担当者がもくもくと手を動かしながら準備を進めてきた地道な活動が、為替等の外部環境の追い風もあって陽が当たり始め、エンジニア組織全体に伝搬していき大きな成果となる、メルカリらしいダイナミックな経験をすることができました。
メルカリのEngineering組織の「風通しの良さ」と「ダイナミズム」を、問題解決の渦に飛び込んだ一人の新入りエンジニアの視点からお伝えしたいと思います。
プロローグ クラウドコストの危険信号を察知したmtsuka氏の悩み
2021年春のことです。
筆者がフリーの技術コンサルタントをしていたとき、”Robust Foundation For Speed”をリードするmtsuka氏より誘いをうけ、会って話しをすることにしました。
彼はお疲れ気味で、乗る電車をまちがえたようでした。あさっての方向の新幹線に乗ってしまい、待ち合わせに大遅刻をして申し訳なさそうにしている彼の話を聞いていると、一つ気になる課題がありました。
「毎月のクラウドコストが想定以上に急増している」という問題点です。
筆者は思いきってメルカリにJoinして、この問題にデータ分析のスキルを生かして取り組むことになりました。筆者の考えがちょっと甘かったのは、見た目以上に問題が強敵揃いだったことです。安請け合いしすぎたかと少し反省しています。
またこの記事のメインテーマになっているFinOpsという言葉は、聞き慣れない方も多いと思いますので軽く紹介させていただきます。
FinOpsについての簡単な説明
前提として、メルカリで利用しているインフラをざっくり2種類に分類します。「パブリッククラウド」「オンプレミス」の二つです。メルカリでは両方を使いながら、パブリッククラウドを利用の軸に据えています。
二つの種類の一番大きな違いは、パブリッククラウドは「使った分だけ翌月に請求書が来る仕組み」ということです。
従来のITコスト管理例を先に紹介します。ビジネス側チームのサービス成長予測に基づき、サーバリソースの必要量を見積し（キャパシティプラニングと言います）購入と設置を行うという数ヶ月単位のリードタイムでサーバ費用が変化していました。サーバ増設に時間がかかるもどかしさがありましたが、追加したサーバ費用は、減価償却という形で5年くらいにわたって費用インパクトが小さい形になっていました。
それに対し現在大部分のシステムがパブリッククラウド上で動いている現在のメルカリにおいては、担当者が新たなキャパシティプラニングに応じサーバリソース設定を変更すると、ほぼリアルタイムでリソース増強が完了する素晴らしい環境が整えられています。
ただ、そのエンジニアにとって理想的な構成の副作用は、オペレーションミスによる過大なリソース設定やキャパシティプラニングの安全率のゆらぎまで、思ったよりずっと高い金額になって翌月頭に届く請求に反映されます。
この悩ましい「お高い費用」問題について、パブリッククラウドへの投資の最適化を企業のカルチャー的な取組として定義し「FinOps」と呼ぶ流れが起きています。
では従来のITコスト管理とFinOpsの違いは何でしょうか？FinOpsはEngineering部門に閉じた活動ではなく、プロダクト・経営・会計部門などの他事業部門との横断型の活動と定義していることだと筆者は理解しています。
以下にFinOps Foundationのサイトに掲載されている「FinOpsを成功させるための原則」＊原文へのリンクを紹介します。
FinOpsを成功させるための原則
Teams need to collaborate (チーム間で協力する)
Everyone takes ownership for their cloud usage (すべての人がクラウド利用にオーナーシップを持つ)
A centralized team drives FinOps (集中チームがFinOpsを先導する)
Reports should be accessible and timely (レポートを見える形でタイミングよく知らせる)
Decisions are driven by business value of cloud (クラウドのビジネス価値で意思決定を行う)
Take advantage of the variable cost model of the cloud (クラウドのコストモデルを有利に活用する)
原則を軽く頭にいれたところで、筆者のFinOps実践の2021年後半から2022年前半あたりの軌跡を思い出して書いていきます。
原則をもとに、実践する
FinOpsを始める上で最初に解決すべき課題として、責任者の設定があります。マクロ・ミクロの両面でシステムの費用面での最終的なオーナーシップとアカウンタビリティ（最終的な説明責任）を誰が持つかということです。
メルカリにおいては、クラウドプラットフォーム系費用の請求書送付先担当者名は、言い出しっぺの筆者になりました。プラットフォームの費用系責任者として毎月、精神的に具合がわるくなる金額の請求書を受け取っています。
なぜ具合がわるくなるかというと、請求書に書かれた費用が事前の想像を遙かに超えていたからです。
ちりも積もれば山となるように、知らず知らずのうちにシステムを作った我々が想定しなかったような大きな費用が毎月発生する状態になっていました。
たとえばメルカリで使っているGoogle Cloudの費用は、オートスケーラー（負荷に応じて自動的にリソース増強される、課金額も増える仕組み）によって発生したインスタンスの課金や、その処理の下流で発生する蓄積されたログの保管費用、通信コストなどが合算された請求となります。
ただ、メルカリのような大規模な環境下であれば、それぞれのサブシステムのエンジニアは明細を見るチャンスがないため、改善余地があるのに見過ごされる費用が長きにわたり各所で発生します。
この文章を読まれている皆様もご経験があるでしょう。我が家のクレジットカードの請求額が非常に多くなったときに、一体だれがこんなに無駄遣いしたのか、まさか不正利用？と明細を見ます。小さい請求がいっぱいありますが、全件たしかに使ったのは自分の顔以外浮かんでこないのです。
定石通りに請求明細の分析から開始
筆者のメルカリ入社後すぐに手をつけたい対象は数多くありました。しかしぐっとこらえて、まずは手近な毎月処理の課金データから①現状分析 ②最適化 ③運用を行い、①現状分析に戻る方法をとることにしました。
GCPやAWSからは、毎月billing reportという形でCSV形式の確定明細データが提供されています。
この請求明細について、いままでメルカリでは最終的に数行にまとめる会計処理データに使うのみで、それ以上の有効活用が十分に行えていませんでした。本来であれば、システム担当者それぞれがオーナーシップを以て担当分の費用を確認すべきです。
なにしろグループ全体で毎月万単位の行数があるデータです。同一契約に紐付くグループ会社ごとの費用負担額をGoogle Sheetで計算することすら、支払担当者の手計算によるチェック含め丸一日をかける大変な作業になっていました。
まずは支払担当者の負担を減らすべく費用処理手計算のリファクタリング作業の中で、このデータにある「とある」未利用の特徴に気づきました。
未利用だったのは、月またぎのプロジェクト・サービス毎の費用増減です。
「前月から今月にかけて、どのサービスでいくら増加したのか？」「その増加は投資として正しい理由があるとアカウンタビリティをもって説明できるか？」など、前任担当者の時間リソースでは月またぎの詳細分析まで手がまわっていませんでした。
「どこの費用が増えたのか？」「なぜ費用が増えたのか？」説明責任を果たすために必要なプロジェクトごとの金額増減は、この毎月の明細データに答えがあるはずです。費用の増減比較を一括で行うためにこのデータを一ヶ月単位のCSVではなく、毎月の変化が見える年単位で連結し時系列で整理し比較提供することにしました。
こんな初歩的なことから初めて1年間、FinOpsの実践に向けた現状分析の取組をした結果としては、費用の動きについてほぼ即座に説明ができるようになりました。経営側から求められる部門コスト管理の説明責任についても果たせていると考えています。
毎月の変化が見える形で整理し、比較提供するという部分では、レポート用のコスト分析ダッシュボードを作成しました。
「レポートを見える形でタイミングよく知らせる」工夫
先の「FinOpsを成功させるための原則」でご紹介した「レポートを見える形でタイミングよく知らせる」部分についての工夫を紹介します。
筆者は「ビジュアライゼーションとは、データに生命の躍動感を吹き込むこと」だと考えています。このビジュアライゼーションを行うにあたり、データストーリーテリング型のダッシュボードを作って読み手が直感的に問題を理解しやすいように工夫してみました。
データストーリーテリング型のダッシュボードの利点は、上から順番に見ていくことで事前に定義したビジネス課題が解決されるように作ることができる部分にあります。
筆者がメルカリにおいて最初に取り組んだビジネス課題は、直近請求額の急増でした。「どうして利用料金が増えたのか? 」経験を積んだマネージャー陣でも明細数字の裏付けがないため会議中は推測に終始し、次の突っ込んだ分析ができず、問題発生ポイント特定と対策に遅れが発生しました。
この課題を解決するために、以下2つのポイントが一目で見えるようにしました。
どこのプロジェクトで前月比の利用額がいくら増えていたか？
費用が急増したプロジェクトは誰が管理者なのか？
筆者は、費用の現状（直近金額・費用構成）を知ることに加え、変化のシグナルを算出しダッシュボードに表示することにしました。最初に開発した実際のコストダッシュボードのデザインは以下です。
一番上のトップレベルKPIに気になる変化があったときに、画面下へ読み進めていきます。
クリックで絞り込みをしながら変化を確認していくと、KPIに影響した原因を見つけることが出来ます。結果と、その変化の傾向、原因が上から下へのストーリー仕立てで説明できるようにダッシュボードを作ってみました。
ダッシュボード化はいろいろなBIツールを比較検討した上で、現在はDomoを利用しています。カラフル、なおかつスライサーを操作するとインタラクティブに絞り込み表示がされる仕組みになっています。
コストダッシュボードで得られた効果
先に問題となったコスト急増の原因は、ダッシュボードを作った直後に原因の絞り込み作業を行ったことで、すみやかに特定することができました。その原因とは、ある担当者が一時的に有効化した設定が利用が終わっても停止されないまま忘れられてしまい、予定外の費用だけが発生していたのです。
すぐに担当チームに連絡して原因となった設定を修正してもらい、不要に発生していたコストを止めることができました。
またこのダッシュボードでは、担当者の努力により費用が減ったプロジェクトをランキング化しています。
大きく費用削減に成功したチームにヒアリングを行い、毎月のエンジニア全体のミーティングにおいて効率化の取組のコツを話してもらったり、成果を賞賛することにしています。
いまは取組開始から1年たって、メルカリグループ各社横断の正式な活動としてFinOps-PJとして成果が出始めたところです。
メルカリグループではFinOpsを含め先進的なチャレンジにいちはやく取り組みたいエンジニアを広く求めています。ご興味ある方は以下のリンク先をご覧ください。
次回の記事では、可視化の部分をもう一段掘り下げて、クラウド課金データやエンジニア予算データを扱う上でのコツを紹介しようと思います。
