FinOpsを実践するメルカリ、その道のりと気づき、今後の展望 - 後編

「FinOps(フィンオプス)」。数年前に概念が登場したもので、クラウドのビジネス価値の最大化、データ主導によるタイムリーな意思決定、部門横断の連携でクラウド支出に財務上の説明責任をもたらすためのフレームワークを実践することを指す。

今回は、前編から引き続きFinOpsを実践するメルカリついて、同社 Engineering Managerの風間勇志氏と、同 中田氏、そして現在、弊誌で連載「はじめてのFinOps」を執筆している、ネットアップの小原誠氏の3人による対談の後編となる。

• 

  左から小原氏、風間氏、中田氏

後編は、メルカリ社内におけるFinOpsの文化醸成の取り組みや、実際の成果・効果、今後の展望などをお伝えする。

社内のハッカソンで「FinOps Award」を創設

小原氏(以下、敬称略)：FinOpsの文化醸成はいかがですか？

風間氏(同)：FinOpsをスタートした時は、コストが上昇したプロジェクトに対して「これなんで上がったんですか？」という聞き方をしていたんですけど、トーンを1つ間違えると煩わしく捉えられてしまうため、最初は良いコミュニケーションではありませんでした。

しかし、活動を称賛することと併せることで、何か問題が起きたときでも「これは意図通りなんですか？どうなんですかね？」と遠回しに聞くことにより、コストカットをしたいわけではなく、“コストの状況をみんなが説明できるようにしたい”ということを目的に伝えていくことが重要だと思います。

• 

  風間氏

小原：確かに聞き方を間違えると、情報を出してくれなかったり、攻撃的な態度になってしまったり、ハレーションが起こる可能性があるため、いかに信頼できるパートナーとして関係を築くか、という点は大切なことだと感じます。

風間：そのよう中でFinOpsチームでは「いかにエンジニアリングのメンバーにコストを意識してもらうかってことは重要だよね」という話がありました。社内では定期的にハッカソンを開催し、普段はエンジニアができないような実験的な機能開発や性能改善を行っています。

これを良い機会ととらえ、昨年のハッカソンで「FinOps Award」を創設して、コスト改善の施策をした人に特別賞を用意できれば少しでも文化醸成に役立つのではと考え、スタートしました。

小原：FinOps Awardは、どのような形で実施していますか？

風間：ハッカソンは、3日間ほど集中して行います。さまざまななアワードがあり、その中の1つがFinOps Awardです。事前にコストに関する改善を実施する人がいれば、審査のうえ、受賞できることはアナウンスしました。FinOps Awardの初代受賞者が中田です。

• 

  ハッカソン内でFinOps Awardを創設した

Kubernetesの煩雑な作業の自動化ツールを開発した新卒2年目エンジニアの矜持

中田氏(以下、敬称略)：私は社内でプラットフォームとしてKubernetes全体のお世話をするチームにいます。Kubernetesの最適化は大きく2つあり、1つが全体的に横串で行える改善です。例えば、Cluster全体で使用するマシンのCPUを効率が良いものにしたり、コストパフォーマンスが良いものにしたりするような改善です。

もう1つは個々のチームが個々のサービスに行う改善となり、一例としてサービスに対するリソースを定義するパラメータなどを調整する手法です。

• 

  中田氏

私たちプラットフォームが行える改善は前者が多く、インパクトも大きいですが、やれることに限界があります。メルカリではプラットフォームとサービスの開発者で責務がきっちり分かれており、各サービスのリソースの管理はサービスの開発者が行っていました。

Kubernetesクラスター全体で十分に最適化された状態を目指すには、最終的にサービスの開発者それぞれのチームごとに個々のサービスを最適化してもらうしかありませんでした。そのため、例えば規模が大きいにもかかわらず十分に最適化されていないサービスに対しては、改善を検討してもらうお願いをしに行ってました。

サービスレベルの最適化にはKubernetesの深い知識が必要となっており、リソースに関係するパラメータは非常に多いです。

これを普段のリソース使用率など、さまざまなものを見て最適化しなければならず、プラットフォームとしては従来はガイドや推奨のパラメータ数値を算出するツールを提供して、可能な限り各チームがアクションを取りやすいような体制にしていました。

しかし、前述したようにKubernetesのDeploymentが1000以上(※)あり、各チームが常に最適化を手動で行うことは労力がかかりますし、最も難しいポイントとして最適化は1回で終わらないという点があります。

※編集部注：前編で言及しているメルカリのDeployment数

現状のリソースに対して最適化したとしても、1カ月後には膨大なトラフィック量になることもあり、当該サービスが使用しなければならないリソース量が増えているかもしれないですし、逆に減っているかもしれないということがあります。

仮に減っていた場合は、もう1度最適化しなければならず、手動では煩雑ですし、永遠に全チームに対してお願いしなければいけないという課題がありました。そのような中で、煩雑な作業を自動化するものとして「Tortoise(トータス)」と呼ぶツールを開発しました。

• 

  オーディンエンスを前にToetoiseの講演を行う中田氏

もし、Tortoiseのせいでサービスの最適化が為されていない場合は、チームがやるのではなく、集約化されたTortoiseを改善することでチームのサービスが最終的に改善されるように、われわれが働きかける。つまり、サービスごとのリソース最適化の責務をサービスの開発チームから、われわれに移していくことをコアな目的として開発しました。

小原：ハッカソンの数日間で構築したのですか？それとも業務と並行してですか？また、すでに社内で利用されているのでしょうか？

中田：元々、課題感があり、それに対するアイデアもあり、ハッカソンでアワードがあるので手を挙げました。現状のフェーズは開発ほぼ終わっており、できるだけみんなに使ってほしいというフェーズになっています。

とは言え、別の難しさがあります。リソースの最適化は、一歩間違えばサービスが落ちることもザラに起こり得るようなものなので、サービス開発者が移行に躊躇してしまっている状況です。

開発環境だと入れてみようという感じにはなるのですが、それでも導入率は50%未満です。本番環境になると、なおさら躊躇いが生まれていて、さまざまなチームに働きかけてアーリーアダプターで取り組んでくれるチームと共同で地道に数を増やしています。

最終的にKubernetesのオートスケーリングが有効になっている、すべてのデプロイメントをTortoiseに置き換えていければと考えています。

まだまだやれていないことは多い

小原：自社の競争力あるサービスを自分たちで開発・運営していることはメルカリさんの大きな強みだと感じています。というのもSIerに丸ごと委託していると、問題があると感じていても改善するには、そういった企業にお願いするしかありません。

その点、メルカリさんは自分たちで考えたものを実装し、試して改善できる点は強みですよね。メルカリさんの中でのFinOpsの活動が上手く回っている印象を受けます。

• 

  小原氏

風間：社内でもKubernetesを利用しているチームが活用できるという点が受賞に導いたポイントになっていますね。

小原：オープンソースのコミュニティなどで使ってもらおうとは考えていますか？

中田：実は、すでにオープンソース上で公開しています。自分で言うのもアレなんですが、割と注目は集まっているかなと感じています。手法が目新しく、みんなが感じているペインポイントだったりするので、コミュニティにも還元できるツールだと思います。

小原：インフラエンジニアに光を当てることは重要だと思います。インフラエンジニアは縁の下の力持ちなので、光が当たるとモチベーションも上がりますよね。今後、アワードどうしていこうと考えていますか？

風間：まだFinOps Awardを設けたばかりなので、継続的にやることが重要だと思います。次のハッカソンが間近に迫っているので、継続していきます。

小原：FinOpsの3段階の成熟度モデルである、クロール(這う)、ウォーク(歩く)、ラン(走る)では、メルカリさんはどの辺りに位置していると認識していますか？

風間：成熟度モデルで言えば、クロールとウォークの間という認識です。まだまだ、やれていないことは多くあり、全体像は見えてきたのですが、例えばアプリ機能のROI(投資収益率)といった細かい粒度までは分析できていなかったりするので、取り組みたいと考えています。

FinOpsの活動を通じて得られた効果は？

小原：FinOpsの活動を通じて、どのような効果や手応えを感じていますか？

風間：ビジネス的な成果と、プロセス的な成果の2つがあると思います。ビジネス的な成果はFinOpsを導入したことで30%以上のコスト最適化が実現できました。

プロセス的な成果は、そもそもグループ全体でどの程度クラウドにコストをかけているのかという解像度が低かったのですが、データをもとにして建設的な議論ができるようになったことが大きいです。これにより、予期しないコスト増加などに速いタイミングで対処できるようになったことから、意思決定のスピードは向上しました。

• 

  FinOpsによる効果の概要

一番大きかったのは、メルカリのエンジニアが“FinOps”という言葉自体を日常的に使っており、クラウドに対するコスト意識が確実に向上したということを実感できている点です。

小原：確かに現場のエンジニアの方が知っていて、日々の活動の中に取り入れている企業は、まだまだ多くないと感じています。その中で積み上げて、そこまで来ているのですね。一方で、取り組まれる中で苦い経験などはあったのでしょうか？

風間：これも先ほど話題に上がったコミュニケーションに気を配ることですかね。コストを闇雲に下げたいと思われないように、エンジニアとのコミュニケーションの取り方は気を付けるようにしています。

コストが上昇した=悪いことのように捉えられてしまうことがどうしてもあります。ただ必ずしも悪いことではなく、売り上げが増加すればコストも上がるのは当然というコミュニケーションをしてからは、ハレーションが起きなくなってきていると思います。

まずは、成功事例を作ることが大事です。実はエンジニアリングの頭の中では、改善できそうなところは分かってはいることがあり、そこで改善を回してみて、これだけ改善できましたと言えたことは良かったことです。こうしたことをきっかけに改善を徐々に波及させて、モメンタムを作れるかどうかは重要ですね。

「Japan FinOps Meetup」を開催 - 今後も継続に意欲

小原：FinOps Foundationとの関わりを教えてください。「Japan FinOps Meetup」を開催したメルカリさんとして、今後はFinOpsのコミュニティへのコントリビュートはどのように考えているのですか？

風間：FinOps Foundationは、Linux Foundationのサブ組織の1つです。FinOpsの活動は、どこの企業でも課題を持っているため、ベストプラクティスの共有やFinOpsのプロフェッショナルを育成する目的で設立された団体です。多くの企業が協賛していますが、メルカリが協賛しているわけではありません。

昨年6月に、FinOpsで一番大きなカンファレンスである「FinOps X」に初めて参加しました。情報収集する中で、日本でFinOpsのコミュニティが立ち上がっていないという話を聞き、これから日本でもFinOpsのコミュニティを立ち上げるのは面白そうだなと、その時に漠然と思っていました。

カンファレンスに参加したときに、FinOps Foundationのエグゼクティブから日本で盛り上げたいよねと直接言われたので、そこまで言われるんだったらやってみようという感じでした。

そして、昨年12月にメルカリのオフィスで、まずは自社の事例を紹介しようという形で初めてMeetupを開催しました。

小原：Meetupの反応はどうでしたか？

風間：アンケートの結果から、ポジティブなフィードバックを得られたことは、やってみて良かったと感じました。また、小原さんもそうですけど社外で同じような課題を抱えている人との繋がりができたことも良かったですね。

• 

  「Japan FinOps Meetup」で講演する風間氏

まだ1回しか開催していないので、これから第2回、第3回とどんどんやっていきたいと考えており、初回はメルカリの事例でしたが、他社がどのように活動されているのかを紹介できればいいなと考えています。

小原：最後にコメントがあればお願いします。

風間：FinOpsに取り組もうと考えてはいるけども二の足を踏んでいるならば、まずやってみることが重要です。

スモールスタートでも良いので始めてみることですかね。手始めに無駄遣いしていると感じる部分に関して、その改善を実際にやってみて先行事例を作ることがポイントになると思います。

中田：Kubernetesはマイクロサービスがやりやすいですし、採用している組織も多く、同じ課題を持つ人が多いと感じています。

そのような中でKubenetesのリソース最適化をどのようにしていくということが課題になるため、ぜひTortoiseを活用してもらえればと考えています。