OpsNowはFinOpsに関連する製品とサービスを提供する会社である。しかし、我々は、FinOpsというものをどれだけ正しく理解したうえでこのサービスを提供しているのか、から考える必要があるので、私の経験をもとにこの記事を書くことにした。
よく、FinOpsは「必須」、「大流行」、「なくてはならないもの」と言われる。このような話が社内から出ているが、「本当にFinOpsは必要なのか」という疑問から始めるのが正しいのではないだろうか。
「OpsNow FinOpsを導入しないと、クラウドコストを削減できないのか？」OpsNowの代表を務めている私さえもこのようなことを考えているのだから、他の人はもっと疑問に思うだろう。
まず、上記の質問に対する私の答えは「いいえ」だ。しかし、FinOpsは必ず必要なものだと考えている。私の答えが正解ではないかもしれないし、経験が全てへの答えになるとは言い切れないが、経験をもとにいくつかの話をし、個人的な考えを整理したい。
私は2012年から韓国では誰もが知っている大企業のクラウドチームの開発・運営リードを担当していた。このクラウドチームは、会社の将来の成長エンジンのために作られたものだった。クラウドの世界に対する私の第一印象は、「クラウドはユートピアだ」だった。
クラウドチーム開発運営リード以前の私は、カーネルシステム開発エンジニアとして、毎日毎日1byteのメモリとの戦い、パフォーマンス1sを改善するために、誰も分かってくれない闇の開発世界に閉じ込められていた。しかし、クラウドの世界に来てみると、メモリに問題が起きたら、その根本を解決するのではなく、サーバーの数を増やした。パフォーマンスに問題が起きたら、仕様の良いものにすればいい、そんな新世界だった。このような新世界の喜びは、闇の開発世界で働いたことがある人でなければ理解できないかもしれない。
クラウドチームの開発と運営は、最初はCloudのCも知らない私を含め、外部からクラウドを経験してきた新しいメンバーと一緒にスタートした。私たちはここで、個人・組織・会社が一緒に成熟する過程を経験した。様々なコスト効率化TF(Task Force)を運営し、生産性向上のためにインハウスソリューションを導入した。最終的に驚くべき金額を削減したTFの実質的な行動隊長になったことを覚えている。この過程で私が感じたことをもとに、我々がどういうやり方でコストを削減し、業務を行ったのか、そしてそれがどやってクラウドのほか、他人との効率性につながったのか、このすべてが現在「FinOps」と呼ばれる概念とどうつながるのかを探っていきたい。
2012年-13年のクラウドサービス拡大の黄金期
2012-13年の当時は、FinOpsという概念そのものがなかったので、クラウドへの移行は、我々が多額の費用を費やすきっかけとなった。当時は、クラウドはコストが非常に安いと思われていた。複数のサーバー上で独自に開発したモジュールを乗せ、リソース管理と技術集約を通じて大規模なインフラを運営する過程だった。その過程で時間当たりのデータトランザクションは膨大で、扱わなければならないデータもスーペタデータ環境では想像を超えるレベルだった。そこは、膨大なお金を使う世界であり、これが当たり前だという錯覚の中にいた。たぶん、2015年まではこのような方法で費用を使ったと記憶している。
だが、本当にクラウドへの理解不足のせいでそんなに多くの費用を使ったのだろうか？実際、数十億人のユーザーを対象に画像とファイル転送を管理し、開発と運用を並行して行うことは、クラウドと大容量処理に関する技術的なノウハウがなければ成り立つものではなかった。
当時は急成長するサービスが次々とクラウドに移行する時期で、サービスの安定性と性能を高めるための様々な試みと技術開発が活発に行われていた。お金よりも「拡張性」が重要だった時代だった。何が正しいのかもわからず、とりあえず「突っ込んでみる」黄金期だったと思う。
これが可能だったのは、みんながよく知らなかったからだ。お互いがよく知らなかったということは、コストを執行する部署も、それを見る部署も、クラウドやインフラに対する理解度が低かったということだ。言い換えれば、経営陣や財務チームなどを説得しやすい時代でもあった。
例えをいくつかを挙げると、当時はMSA(マイクロサービスアーキテクチャ)という構造も知らなかったし、問題が発生したら、サーバーを増設して仕様を増やせばいいと思っていた。なぜDBが重要なのかもよくわからなかった。「課題は課題でカバーする」時代だった。
この時代に様々な経験をしたが、例えばこんなものだ。大容量データトラフィックを扱うための技術的な方法論、IO処理の理解、「データはクエリで取り出せばいいんじゃない？」のような初歩的な考え、大容量トラフィックで問題が発生したとき、開発的に解決すればいいと思い込んで、運用を無視していたことなど。
最も記憶に残る経験の一つは、開発コードの修正デプロイを任意に進めちゃって、サービスオープン直前までも安定化ができず、結局、オープン報告をしなければならないその当日までの2泊3日間、サービスの全面障害が発生し、サービスが誕生する前に死にそうになった経験だ。この時、実は開発コード上の問題は解決されていたが、すでに積まれたトラフィックが、それが解消されるまでは問題を持続させるということに気が付かなかった。結局「運営の妙技」でサーバーをオンオフさせることで何とか解決はしたが、この決定を下すまで2泊3日がかかった。
これは、たくさんの非難を受けては文句を言われた経験のおかげというか、クラウドの専門家まではないが、クラウドの歴史の名残と経験で体化された熟練工に発展するきっかけとなってくれた 。今思えば、本当に多くのサービスを自分で作って運営していたこの時期は、貴重な経験だった。どうすればサービス拡張という名目でお金を浪費できるのか、どうすれば上層部をそれらしく説得できるのか、そんなことを知ることができた時期だった。
2014年の全社的なクラウドコスト削減 - FinOpsの概念に似た活動の開始
2014年からは、グローバル経済の不確実性などにより、「コスト削減」が全社的なテーマになった。本格的なクラウドコスト削減活動が始まったのだ。当時は単に予算比30％削減という表面的な目標のもと、本格的なコスト削減活動にとりかかったと記憶している。
このようなコスト削減の流れの中で、クラウド環境の複雑なコスト構造がさらに浮き彫りになっていた。クラウドは、従来の会計や財務の方法とは全く異なる属性を有していたからだ。一般的な会計や財務分野では、年間予算の範囲内でコストを運用するが、 クラウド環境では、リアルタイムで使用量が変動し、正確なコストと予算を予測することが困難だった。クラウドの使用量とコストが天文学的に増加した時期には、このような特性により、サービス品質を維持するために過度に高い仕様を維持したり、初期に設計された構造をコスト効率化のために改善することは難しいという理由から、サービスの改善なしに継続的に運営するやりかたが繰り返されていた。
当時、経営陣や財務部門はこれを「必然的な支出」、つまりグレーゾーン(Grey Zone)と呼び、やむを得ず費用を投入する状況だと受け止めていた。まるで底が抜けた桶に水を注ぐような感覚で、継続的に費用を使い続けた。財務担当者は「勝手にやってくれるだろう」と思って予算を立てたが、いざ執行が始まると予想外の支出が続出し、その時初めて深刻さを認識する仕組みだった。当時は「投資」という認識が強く、不満があってもおおむねスルーされる雰囲気だった。
そんな中、「緊急経営」というキーワードとともに、組織全体に強烈なコスト削減の圧力がかかりはじめた。この当時、クラウド集団にいるにもかかわらず、FinOpsという概念自体は存在しなかった。代わりに、経営革新とコスト削減という原論的な目標のもと、一斉に30%削減を要求され、これを達成できない場合、役員のKPIと評価に反映するという圧力がかかったことで、組織はコストに関心を持ち始めた。
コスト削減活動の最初のステップは、現状把握
まず、コストとリソースを管理する担当者はいるのか、どのような方法でリソースが使われているのかを把握することからスタートした。組織間の複雑な利害関係と隔たりにより、このような情報収集だけで数ヶ月が要された。当時は、クラウドサービスプロバイダ(CSP)もユーザーに対し、コストとリソースの使用状況を明確に提供できない時期だった。
また、内部能力だけでは限界があると判断し、外部診断を並行して行なった。これにより、外部CMPの導入とともに、同様なツールのPOC(Proof of Concept)と自社開発に着手し、マッキンゼーやアクセンチュアなどの外部コンサルティング会社が介入して300-400以上の項目の点検が行われ、本格的な診断を開始した。何百ものエクセルファイルを広げて、組織長に使用履歴を一つ一つ追及していた時代だった。今思えば、このような行動がまったく意味がなかったわけではないが、サービスを知らない状況では一方的な会話に近く、診断する部署と溝が深まるきっかけとなったようだ。「君たちにこのサービスの何が分かるんだ」という気持ちが渦巻いていた時期でもあった。
前述したように、コスト削減活動における問題認識の始まりは現状把握だった。組織ごとにクラウドを利用したことのある人は知っているだろうが、クラウド環境がきちんと管理されないと、ただ請求書を確認することがすべてで、詳細な情報把握が難しく、大きな混乱を経験することになる。このような状況でまず、情報を収集し、整理することからスタートした。
そして、徐々に「既得権」というものが形成され始めた。現状を一番初めに把握して経営陣に報告する組織が比較的大きな影響力を持つようになり、いわゆる「勝ち組」のポジションを占めるようになったのだ。このような構造が定着すると、むしろ信頼が崩れ、「溝が深まる」問題が発生することもあった。それを見守るのも、当時はかなり興味深いものだった。
情報収集が終わると、「この費用をきちんと使っているのか」という質問に移る。理論的にメモリやIO、CPUなどの使用現状を分析し、使用率の低いリソースは無駄だと判断して一括してリソースを縮小するか、削除していた。しかし、クラウド運営に適した設計が最初から正しく行われておらず、サービスに関する十分なドメイン知識もない状態で無理に推進したリソースの縮小は、大規模なサービス障害につながる可能性があった。特に、サービスの本質を十分に理解せずに行った上記のようなアプローチは、予期せぬ問題を引き起こす主な原因となった。前述したように、問題は別の問題で覆い隠すという悪循環を生み出した。
リソースを急激に削減した後に発生したサービス障害により、各組織の担当者は予算を管理する部署に強く反発し、「コスト削減で起きたサービス障害にあなたたちが責任を取れるのか」という言葉が飛び交い、たびたび対立が生じた。結局、組織は適切な妥協線でコスト削減を行うか、反発に屈するかの二者択一を余儀なくされた。
このような中、それなりに売れ行きの良いサービスがなくなるという事件も発生した。逆に、最も多くの費用を使うサービスは、削減すべき要素が多いにもかかわらず、将来の投資価値や様々な利害関係により維持されることもあった。そのサービスは今も順調に運営されていると伺っている。
2015年-18年 マルチクラウドによるコスト分散とCSPと割引率を交渉
2015年から2018年までは、「コスト」という言葉を中心に、サービスに対する理解の欠如と複雑な利害関係により、コスト削減のアプローチに変化が生じ始めた。個人的な見解だが、この変化は2つの方法に分かれていた。
まずCSP(Cloud Service Provider)との割引率の交渉で、それによる内部管理の難しさを割引率を通じて一定部分は相殺できた。これは大企業がCSPに多大な売上を上げてくれていたからこそ可能な方法だった。
第二の方法は、RI(Reserved Instance)を通じた割引の適用だった。当時はSP(Savings Plan)が登場する前だったので、中央でRIを一括管理し、これを組織ごとに配分するやりかたでコスト削減を試みた。しかし、RI管理の複雑さと、適用対処から除外された部署の不満は、深刻な問題として浮上した。特に初期はノウハウがないままRIを運営していたため、適切に管理されていないRIと低いカバレッジ問題で、むしろコスト爆弾になる場合もあった。このような経験は、なぜ今、FinOpsで重要視しているRIやSPのような項目が自動管理される必要があるかをよく示している。
結局、コスト管理戦略は、マルチクラウドによるコスト分散とCSP(Cloud Service Provider)との交渉に発展することになった。このようなアプローチは、昨今のFinOps戦略にも通じるものだが、当時は従業員のクラウドとコスト管理に対する成熟度が十分でなかったため、不満も大きかった。
また、AWSなどの主要CSPが新規サービス導入時に提供するクレジット特典のおかげで、一部の組織ではソリューションを断続的に交換していた。この一連の過程で、これまで経験したことのない様々な新規ソリューションとマルチクラウド環境に接することで、技術的には大きく成長するきっかけとなったが、個人的な観点からは、結局、最大の受益者はCSPだったと思う。なぜなら、当時はまだ大規模なトラフィックとデータを実質的に運用している企業がほとんどなかったので、CSPの立場からすると、実戦のノウハウを得る絶好の機会だったからだ。これらの経験をもとに、CSPはさらに急速な発展を遂げることになる。
一方、クラウドサービスの使用量とデータは増え続け、様々なコスト削減の努力があったにもかかわらず、再びコストが増加する現象が現れ始めた。結局、主要サービスを除き、MAU(月間ユーザー数)が一定レベル以下のものや、売上貢献度が低いサービスに対するコスト削減の圧力が激化した。これにより、運営と開発組織は生き残りのためにアーキテクチャとパフォーマンスの改善について激しい検討を開始し、限られた予算の中でインフラと開発革新が行われ始めた。(運営も含む)
この時期を起点として、一部の組織では、ChatOps、EKSベースの先進的な構造の導入、Terraformの活用、外部SaaSソリューションの使用、サーバーレスアーキテクチャーへの転換など、 より先進的なクラウドアーキテクチャーへの転換に本格的にとりかかった。コストを抑えながら性能を確保するための努力は、文字通り「必死の努力」だった。
それまでは、一部の技術リーダーが全体をリードする構造で、組織内のクラウド成熟度のばらつきも大きかった。しかし、この時期を境に、サービスを担当する人材の開発・運営・コスト管理に対する全体的な成熟度が急速に高まり始めた。特に、無停止運営、ユーザーからのクレーム対応、機能・ソリューションの比較分析と導入失敗の経験、そして運営失敗による残業と財務チームの呼び出しなど、様々なプレッシャーの中で、何とか生き残るための実質的な戦略を探し始めた。言い換えれば、運営のための開発にシフトしたことになる。
そして、このように実行するうち、いかに多くのリソースと人員を非効率的に使っていたかを自らが認識するようになった。このような自覚は、「業務の極悪な自動化」という方向性につながり、自動化のための技術・業務革新が本格化した。理由は簡単だ。そうしないと、仕事が多すぎていつか倒れてしまいそうだったからだ。
このような貴重な経験は、周辺組織との**生存のための技術交流と「技術に見栄を張る」ことを深めるきっかけとなり、さらに部門間の競争とプレッシャーにつながった。「我々のほうがうまい」、「より少ない人員で」、「より少ないコストでサービスを安定的に運営する」という競争が始まったのだ。
2019年、クラウドコストの大幅削減プロジェクト - 本格的なFinOps活動の開始
その後、時間が経ち、数年後、全社的にクラウドコスト大幅削減というプロジェクトがトップダウンミッションになった。「たくさん使うからたくさん減らせ」というシンプルだが強力なメッセージだった。この時から本格的なFinOps活動がスタートしたと言える。当初は戸惑いもあったが、 最適化と効率化、RI/SPの導入、EDP交渉など、利用可能なすべてのカードを総動員して対応した。
組織ごとの利害の対立により、プロジェクトはしばしば難航した。これを打開するために、2つの戦略を併用した。1つはクラウドの専門家で構成されたチームが各サービスのアーキテクチャを徹底的にレビューすることであり、もう1つは 財務チーム主導でFinOpsのようなツールを強制的に導入し、透明なデータを確保して診断を開始するアプローチだった。
当初は一般的に知られている普遍的な方法、つまり未使用リソースの整理やRight Sizingなどのアプローチを試みたが、これはすぐに限界にぶつかった。過去とは異なり、クラウドの成熟度が高まって、サービス品質に対する責任所在の問題が浮上したため、単純なアプローチは結局失敗に終わった。いくら見栄えの良いデータを持って行っても、そのサービスに対する深い理解と責任を求められてしまうと、それを押し付ける部署でさえ躊躇してしまう状況が発生した。
だから新しい方法が必要だった。今ではCSPがリソーススケジューリングやスポットインスタンス管理機能を基本的に提供しているが、当時はCSPにもこのような機能がなかったため、私たちはそれを社内で開発しなければならなかった。これを実証するためにマルタプロジェクトを選定した。実際の動作の有無よりも 「FinOps方式の可能性」を示すことが目的だったので、3か月間準備してテストに入った。これが動作するかどうかは重要ではなかった。FinOps導入を広めるための手段が必要だったからだ。内部的にはそれなりに完成度を上げたとはいえ、短期間で作ったソリューションは様々なバグと混乱を招いた。忍耐が必要なプロセスだったのだ。
紆余曲折の末、直接開発した様々な効率化ソリューション(リソーススケジューリング機能と当時オープンソースを改造して作ったスポット(spot.inst)管理ツール)などを通じて効率化ツールを作った。これを社内で開発・運用している課題で実証を行い、3ヶ月間の極悪な効率化を行った。そこから導き出されたデータをもとに、他の組織にも強制的にそのツールを適用し始めた。単なるツールの導入ではなかった。サービス構造を根本から設計し直し、人的リソースの効率性をチェックした。
このプロセスを「FinOpsツールの効果」と大々的に表現はしたが、実際にコスト削減に最も大きく貢献したのは、もちろん、データ構造の転換、アーキテクチャの近代化、人材の刷新などの構造的な変化だった。この一連の活動は、私が攻撃者ポジションを取ることができるようにしてくれた。そして、クラウドサービス開発者からクラウド運用責任者へ転換するきっかけを作ってくれた。
この経験から得た教訓は、全組織を動かす必要はないということだ。核心的ないくつかの組織の変化を作り出し、その結果に基づいて経営陣と財務チームにコスト削減効果と予測データを提示する。その後、各組織の担当役員にコスト削減をKPIとして割り当てることで参加を誘導した。診断組織はクラウドサービスに対する高い理解度と技術的信頼を基に各部門に必要な実行手段を提供した。このようなアプローチは、現在のFinOpsの哲学-協業ベースのコスト最適化、予測可能な意思決定、実行可能なツールとプロセス-と一致していると言える。
FinOpsツールそのものよりも、 その後の余波で行った節約の方がはるかに大きかった。その頃、最も多く受けた質問は、
「このような方法で効率化をすると、RI/SPよりも節約できるのか」、
「EDPよりも大きな割引になるのか」だった。
当時の基準ではむしろ逆転現象が頻繁に発生した。しかし、重要なのは現在ではなく、将来の構造変更後に発生する長期的な節約効果だった。これを納得させるための議論と説得は熱いものだった。
問題は、持続的な管理がなければ、このような努力も簡単に崩れてしまうことだ。少しでも管理が甘くなると、また元の姿に戻ってしまったり、技術的な負債が累積したり、コストが揺らいでしまう。一度不信感が生じると、今後FinOpsの導入自体を拒否する雰囲気になる。つまり、継続的な努力と革新がなければ、ダイエットのようにまたリバウンドしてしまう。これがFinOpsのエコシステムにおいて非常に重要なポイントだ。
また、どんなに頑張っているつもりでも、外的要因などによってその努力が無駄になることもしばしばあった。代表的なのが為替レートだ。例えば、2021年までに効率化や構造変更に一生懸命に取り組んで一定の削減を達成したのに、為替レートの上昇でその効果が全て相殺された例もある。
がんばって月10億ウォンをも減らしたのに、為替のせいで逆になり、財務では「本当にコスト削減したの？」と言われた。このような一方的なコミュニケーションなども頻繁に起こる(このような時は結局人を減らす悪循環が起こることもある)。おそらく最近の世界経済や韓国の為替レートなどで過去と似たようなことを経験する事例が出ると思われる。歴史は繰り返されるものだ。
さて、ここまでの話は過去の経験である。この経験を少し整理しよう。いつも経営者の危機意識から追及が始まり、組織が応じない時にはKPIなどのミッションと予算で圧迫し働きかけた。もちろん、独自にうまく運営している組織もある。この場合、あえて外部からツールや方法を強制しない。すでにうまくいっているのだから、無駄に手を出して流れを壊さない方がいいからだ。
また、機能的に見ると、 コスト分析、異常検知、リソース提案、マルチクラウドの比較、性能分析、ネットワーク診断など、私たちがよく知っている技術的な方法論はすでに普遍化されている。実際に問題を認識した瞬間、ほとんどの場合、このような技術的なアプローチから試みることになるだろう。
コストを削減する過程 - 単一サービスの運営組織 vs.複数のサービス管理組織
それでは、過去の経験をもとに、現実の世界ではどのようにコスト削減が行われるのか。私たちは果たしてその過程をちゃんと分かっているのだろうか？そこから話を始めよう。
前述したように、必ず何らかのきっかけがある。経営者であろうと誰であろうと、誰かがコストとリソースの使用について問題を提起する。運が良ければ、指摘を受けたときにすぐそれを正しく理解し、自発的に対応すればいいのだが、残念ながらほとんどの場合はそうではない。みんな、やろうとしない。
その理由は明確だ。やったって自分の仕事が増えるだけし、非難を言われる可能性があることを知っているからだ。そして、すでに分かっているから-もっと使うのは簡単だが、減らすのは本当に難しいことを ― 結局、この仕事は3つの基本的な軸で動くことになる。実行する担当者、診断・分析する担当者、そしてこのすべてを評価し、意思決定を行う担当者。ここからさらに拡大すると、 現在FinOps Foundationが定義しているペルソナと同様に、役割がさらに細分化されていく。
一例を挙げると、
「今月の予算は必ず20％削減すること。特にクラウドのコストから減らそう。」
上記のような目標が割り当てられたら、担当者はまずどうするか。
「最近3ヶ月、6ヶ月、1年間のクラウド費用、使ったもの全部持ってきてくれ」 と、コストがこれまで増加したかどうかはともかく、コストデータを集めることからスタートする。
ここで、単一のサービスを行う組織と複数の組織がある場合はアプローチが異なる。
単一サービスを行う組織は、最もコストを多く使っているリソースはなにかというリソース現況分析から始める。そして悩む。「これ減らせるの？」
費用のかかる領域は大抵決まっている。DB(データベース)やネットワークコストだ。一旦、何かアクションを起こすために、 通常、まず未使用のリソースから叩き始める。しかし、実際にやってみると、それによるコスト削減効果は思ったほど大きくない。あるいは、運良く、大きなコストがかかっている管理していなかったリソースを見つけられるかもしれないが、それはあくまで運である。
次に、リストを引く作業だ。どのようなリソースが近代化、つまりRight Sizingできるかを熱心に探す。
何かと調べて「これくらい減らせば、コスト削減したと言えるのでは」と思い、それなりに準備をするが、すぐに悩みが生じる。
「これを減らしたらRI/SPが足りなくなるのでは？」、
「EDPの条件が外れてshortfallが起きたらどうしよう」、
「RI/SPの期限っていつまでだっけ？それまでにこれが可能だろうか？」
このような悩みが生じると、上記のことは対処が難しいので、逆に自分たちが今使っているアカウント全て-運用系、開発系など-を見つめ直し出す。もちろん、順番は変わるかもしれないが、最終的にはすべてのアカウントを一つ一つ見ていくことになる。
ある程度アカウントなどが整理されると、報告は通常、このようなことが堂々と行われる。「このように減らしていけば、今後、コストを効果的に削減することができます。」という1次元的な報告だ。しかし、20％以上減らすことは容易ではない。となると、選択の岐路に立つ。
本当に不要なサービスを降ろすべきなのか？それとも、ここに投入される人員を減らすべきか？
しかし、どちらにしても決して簡単な選択ではない。
そこで、開発や運用の経験がある人なら、ここから本質的な悩みが始まる。
「これは売上にもつながる問題だが、ROIの観点から、私たちのアーキテクチャや設計自体を見直す必要があるのではないか？」
この地点から開発と運営の構造的な変化が始まる。もしこのような議論をせずにそのまま行けば、結局、「不可避的な費用の支出」という名目でグレーゾーン(Grey zone)の中に放置され、組織はその状態を維持し続けることになる。
複数のサービスを管理する組織であれば、流れは似ているが、スタート地点は少し異なる。
ほとんどの組織では、「どの組織が最も多く使っているのか」という質問から出発する。
この方法は、当然、最も多くの費用を使用している組織と、その組織を担当している管理者にスポットライトが当てられる。
もちろん、その費用支出が正当な理由に基づくものだとしても、比較的よく管理されている組織であっても、全体的な費用の数字を合わせるために犠牲になる場合もある。一種の「生贄」になるものだ。
その後はほとんど前述の方法-リストの作成、リソースの整理、アカウントの確認など-をそのまま踏襲することになる。しかし、この過程でも、RI/SPの管理、特定の組織への贔屓、運営ノウハウの違いなどにより、組織間の葛藤が発生しやすい。実際には、特定の担当者に責任が転嫁されることもある。
この時点で、組織内部では自然にコスト配分構造を再検討することになり、各組織の予算と配分内訳をめぐって議論が始まる。もちろん、この状況を誰もが否定的に受け止めるわけではない。むしろ、予算体系が明確になる点で歓迎する組織もあるだろう。
------------------------------------------------
しかし、開発や運営に一定以上の経験がある人であれば、結局は本質的な悩みに直面することになる。コストは売上に直結するため、ROI(投資対効果)を考慮し、私たちのアーキテクチャや設計を根本的に減らすべき時が来たのではないか、という質問を投げかけるようになる。この時点から、開発や運営方法に実質的な変化が起きる。
逆に、このような悩みもせず、単に「必然的な費用の支出」という名目で現状を維持すれば、これはますます継続的なグレーゾーンに突入し、問題はより複雑になるばかりだ。
—-----------------------
上記の事例は、ほとんどの組織が一度は必ず経験する現実的な話だろう。実行を任された部署はできるだけ一生懸命、時には一部を隠しながら仕事を進めるが、結果の報告を受ける側は数字しか見ない。「数字が減ったか減らなかったか」、それだけだ。何をどうしたかは考慮されない。
この時点から組織内部に不協和音が聞こえ始める。
どれだけもがいても、努力の結果より数字だけで判断されると思い始めたら、もうどちらか一つだ。コスト削減を見せかける目的でわざとコストを膨らませて作業をする方法と、現状維持で何とかするかである。この時、資源とコストの分析と現状を調整し始める。
この事例を基準にすると、FinOpsというのはコスト削減が目標ではなく、今我々がちゃんとやっているのか、適正性をもって運営しているかといった現状把握からスタートし、関連部署を説得する一連のメビウスの帯のように動くとものになっていると言える。
いつも悩まされるのは、 Right Sizing, Unused Resource cleanup, Modernization のようなアプローチだ。このような資料に基づいて、私たちがどれだけコストを効率的に使っているか把握できるのかと問われれば、答えははっきりと「Yes」だ。
しかし、そのデータに基づいて、新しい取り組みを今運用中のサービスにそのまま適用できるかという問いに対する答えは、「No」だ。
ここは、よく運営やサービスを直接担当しない部署が簡単だと考えている部分でもある。
サービス運営は非常に保守的であるため、運営上の問題については常に責任という重い言葉がつきまとう。こんなことをしているより、いっそのこともっとお金を使った方がいいと思ってインフラリソースの拡大などをし、コストがさらに増えるケースも出てくる。このサイクルが繰り返されると、基本的な部分を除いて、サービス運営に影響を与えないEDP / RI&SPを事前に購入してコスト削減をする方式になるしかない。時にはプログレッシブに、スケジューラのように使わない時間帯のサーバーを消してより安いリソースを交換するSpotなども考える。しかし、これもサービス運営と責任という枠の中にあって、責任を逃れることはできない。もちろん、ある程度の成熟度があれば、このような部分を自動化し、働く人の業務における選択と集中を考えてくれることもある。
そして、その次のアプローチが人に責任を与えることだ。統制をしろ、投資をしろ、それを担当部署のミッションになるように設定するのだ。なぜなら、これが一番簡単だから...。人を強く圧迫しては「できなければ責任取れ」。これほど簡単なものはないからだ。じゃあ、これをするにはどうすればいいんだろう...。人がエクセルで、または一々文書化し、見つめることもできるだろう。しかしこれも、リソースや組織が小さい場合に可能なことだ。だから、人がよく分類して管理して見られるようにTagを導入し、綺麗に整理して示す。こうすることで、膨大なデータからどの組織がどのリソースをよく使うかを区別して、より簡単に分析できるようになる。
しかし、こんなものを導入することでコストが減るか？答えは「Yes or No」だ。結局、何かしらのアクションを行うためには人が入らなければならないが、本人の責任がなくなると、途中で手を離れることになってしまう。そこで、KPIなど組織のミッションと予算コントロールをし始める。これをコントロールできなくてパーになってしまうケースをたくさん見てきたので、組織の成果として話をすることが多い。
状況がこうなると、どうすれば削減できるのか、内部的にいろいろと悩むことになる。サービスをどのようにすればより少ないコストで提供できるか、運営管理ポイントもどのようにすればより効率的にできるか、これを行うにはサービスの理解と現在自分が使っているリソースに対するコストがどれほど高いかを認識するようになり、最終的にunit economyに発展することになる。
そして人に対する効率の話も出てくるようになる。結局、誰かが責任をもって動けば、回るようになる。ただ、責任を負ったからといって、すべてがうまくいくとは限らない。その人の権限と意志の強さによって変わる場合もたくさんある。そして、この努力は短期的なものかもしれないし、長い時間がかかるかもしれない。しかし、思ったほど、組織に文化が定着していない時点では、有機的に動くことは容易ではないので、この責任を何らかの形で分散させようとする。お互いが喧嘩したくない時は、一緒に仕事して協力し、共同作業でプロジェクトを進めたりする。敵になると、お互いが違う言い訳をし始める。これが最近、FinOpsのFrameworkが技術ベースと企業のビジネスパフォーマンス指標に変わっている理由だ。
また、このデータは、財務的な責任を持つ部署で、データと作業の信頼性を把握するために、Budgetという範囲のなかで、計画した予算・予測に比較してどれだけちゃんと使っているかを説得することが非常に重要になった。このデータの信頼度によって、各組織の自由度が決まるのではないか。そして、それが発展して、一番大事な要素、共通のミッションと実行を行うチームのコミュニケーションが向上していくのだ。
よく「知らないと使いこなせない」という。このサービスを一番分かっているのは、サービスを運営、開発、運営管理する部署だ。先ほど話したように、このような最近のFinOps Foundationの新しいFrameworkの変化がこれを表している。つまり、よくわからないと、なぜたくさん使うのかわからないのだ。昔は、財務と話す時にコストという言葉を使えば、費用を削減できる余地があった。今は、サービスを運営して開発する組織こそがコストに一番詳しくなければならない理由の一つだ。
つまり、様々な部署がFinopsという名目の下、表面的には、無駄なものを見つけて削減しようとかかげるが、 結局、ちゃんと把握できるようにサポートし、それを改善して投資対比で効率的に使うようにする概念だと理解するべきだ。このような基調から、FinOpsのツールは、時間と労力、そして複数の人が使うツールを一つの声、一つの言語で話をする最も基本的な手段と考えてよいだろう。使うお金だけを見る人もいれば、技術用語だけを見る人もおり、KPIなど達成率の数字だけに関心がある人もいる。が、これを構成する基準データは全て同じだ。その詳細が何であれ、お金を払うことは変わらないし、使ったことに対するコスト計算の元データのロジックも変わっていない。
OpsNowのように、すべてのFinopsツールはそれぞれ機能の役割がある。その機能は決して一つの機能だけのために作られたものではなく、 有機的に一つの言語を提供するための手段と考えるべきだ。機能的なユーザビリティなど、違いは千差万別にあり、お互いが見ようとする内容はみんな違う。だけど、結局は、うまく使いこなしているか、より向上できる部分があるかという観点、データに対する見方はそれぞれ違っても、一つの言語で話すことだ。「うまく使っているよね。」、そして「同じ言語で話すのが合っているね」と。
現在、私たちOpsNowは、FinOpsを理解し、導入をしようとする人たちに役立たなければならない立場にある。顧客がどんなツールを使っても構わない。FinOpsを理解するためには、FinOpsについてどれだけ正確に理解しているかを確認する必要がある。その後、どのようなツールであれ、手段を導入するためには、これらの一連の過程をある程度把握した上で始める必要がある。前にも個人的な過去の事例を紹介したが、私はFinOps理論を知らなくても...挑戦をした。無数の失敗と成功を繰り返しながら、何度も何度も試行錯誤をし、それをFinOpsの言葉で包んでいる。つまり、企業は理論そのものが不足しているからではなく、組織内部の経験と挑戦への意志、運営的な理解、担当するサービスの本質、そして一緒に働くにはどうすればいいか、という深い悩みが伴われなかったからだ。理論なんてグーグルで調べるとすぐ出てくる。頭だけで知っているもの、知っているふりは限界がある。
幸いなことに、OpsNowは、MPSであるBespin Globalでたくさんの運営経験し、顧客のニーズに基づいて成長してきた。このような経験をもとに、 FinOpsの領域で、一つの声でFinOpsを物語るために日々努力している。まだまだ先は長いが、経験という財産のもと、サービスを高度化している。
しかし、内部でFinopsの業を営んでいる人は、業に対する深い悩みや経験をもとに、コストコントロールや効率性を考えながら開発を手掛けている人がどれだけいるのかを確認する必要がある。「もちろん上手くやっている」と言いつつも、実際に経験している人とそうでない人では大きな違いがある。そのため、かつてのOpsNowのクラウドコスト削減は、単に製品の機能を紹介してきたこともあったが、今は各機能の必要性と背景を明確に理解し、信頼できるデータに基づいて組織が効果的にアクションを取ることができるストーリーを作成するまでに発展している。以前は機能中心だったのが、今は全体的に同じ言語で見ることができるサービスに進化しており、これをより深く理解し、よく説明できる方向に向かっている。
今、組織内部でクラウドを分析し、費用管理と効果的な削減のために考えられる環境を構築してきたかを顧み、それをよりうまく示すことができるような努力が必要な時期だ。製品とサービスを提供する立場として、この部分に対する徹底した理解と経験は必須である。こんな機能がありますよ、という機能を紹介するレベルを超えて、私たちが本気でFinOpsを理解し、実践し、点検し、導くのがOpsNow FinOpsの立場だ。
FinOpsの本当の始まりは、管理されていないクラウド費用の理解と統制だ。多くの企業がFinOpsを導入することでコスト削減を最大化できると期待するが、実際には必要不可欠な要素ではなく、選択的に活用されることが多い。企業はすでに様々な方法でコスト削減を実践しているし、私たちが特に優れないかもしれない。
コスト削減のための方法論は様々である。CSPとの大規模割引交渉(EDP)、RI/SPの活用、リソースの効率化と最適化などは基本的なアプローチであり、これはFinOpsツールがなくても可能なことだ。それとも、労働力で代替してもいい。ただし、このプロセスは、時間と労力、ビジネスドメインとサービスに対する深い理解がある場合により効果的だ。組織の能力が十分備わっていれば、サービス構造をリアキテクチャリングし、性能最適化を図って費用と効率性を根本的に向上させることができる。
では、なぜFinOpsの哲学が必要で、OpsNowのようなツールが必要なのか、本質的な考察が必要だ。クラウド環境が複雑になり、組織が大きくなればなるほど、管理が難しくなり、責任所在が不明確になり、放置されることが多い。クラウドのコスト特性上、問題が発見された時にはすでに状況が悪化している場合が多く、修正や調整にかなりの時間と労力がかかる。継続的な努力が伴われたときにFinopsは正しく機能するが、そのためのスタートがFinOpsが必要な理由である。
FinOpsは、コストとリソースを定期的に監視し、問題発生を早期に検知してリスクを軽減することができる。これは、リソース効率化とコスト最適化のための第一歩だ。この過程で、組織における透明なデータ管理、予算の統制、ガバナンスの管理や全般的なレポートを行ってコストの流れを明確に知ることが必要だ。この段階でさらに効率的で体系的な管理のための方法論と協業体系を作るのがFinOpsの本質である。
理想的な段階は、自動化を導入し、すべての組織が同じ言語でコミュニケーションできるようにすることだ。そして、継続的にサイクルを回さなければならない。ワンタイムで終わるのであれば、FinOps / FinOpsツールは不要だ。継続的な活動を支援するために、OpsNowのFinOpsが進むべき道は、このような問題をどのように解決し、提供しなければならないのかだ。「機能が開発されたから私たちにもできますよ」じゃなくて...
OpsNow FinOpsが進むべき道
我々が進むべき道と、やるべきことはたくさんある。技術トレンドが過去と違って急速に変化しており、これを補完しなければならないのが私たちの仕事だが、肝心の我々内部でその機能/技術以外のものに対する本質を理解しなければ、いくらAIなど先端技術を導入しても、むしろ新しいAI時代に私たちが食われかもしれないだろうし、すでに浸食されつつある。また、クラウドの成熟度が過去と違って均等に発展している時代だ。レベルの高いサービスと製品の競争力を持つためには、誰よりも内部からこの本質をよく理解しなければならない。
今、OpsNowは韓国内CMPの中でFinOpsを最も得意とする集団として定着しつつある。様々なFinOpsの資格保有、FinOps Certified Platformの取得など、従来の技術だけにこだわるのではなく、どのようなメッセージを伝えるべきかを考えるソリューション、サービスとして発展し続けている。
サービスが発展し、便利になるにつれ、過去と違って大半の人は、これがどのように動くのか、どのように実装されているのかよく知らないまま使っている。以前はリソーススケジューリング、Spot機能は当たり前の機能ではなかったが、今では当たり前の機能かつサービスとなった。つまり、技術の進歩がユーザーの利便性を提供したが、それを理解し、運用しなければならない部分からさらに遠ざかるようになった。
今もクラウドが快適になればなるほど、見えるものだけを見るようにしがちだし。これをどのように動作するのかを理解するケースは稀になっている。このようなサービスを提供する我々こそが掘り下げなければならない部分でもある。人は知っている分だけ見えるものだ。AIなどで、より便利さを求める世の中になったが、それを理解し、きちんと情報を提供する人の役割が減ると思っている。これが現在、私たちが注目すべきOpsNow FinOpsの出発点ではないか。当たり前だと思っていたことは、いつも当たり前ではなかった。しかし、我々が語っているRI/SPの自動管理もいつの間にか当たり前の機能になっているように、サービスの当たり前を作って提供するのも私たちであるべきだと思っている。
OpsNowはFinOpsに関連する製品とサービスを提供する会社である。しかし、我々は、FinOpsというものをどれだけ正しく理解したうえでこのサービスを提供しているのか、から考える必要があるので、私の経験をもとにこの記事を書くことにした。
よく、FinOpsは「必須」、「大流行」、「なくてはならないもの」と言われる。このような話が社内から出ているが、「本当にFinOpsは必要なのか」という疑問から始めるのが正しいのではないだろうか。
「OpsNow FinOpsを導入しないと、クラウドコストを削減できないのか？」OpsNowの代表を務めている私さえもこのようなことを考えているのだから、他の人はもっと疑問に思うだろう。
まず、上記の質問に対する私の答えは「いいえ」だ。しかし、FinOpsは必ず必要なものだと考えている。私の答えが正解ではないかもしれないし、経験が全てへの答えになるとは言い切れないが、経験をもとにいくつかの話をし、個人的な考えを整理したい。
私は2012年から韓国では誰もが知っている大企業のクラウドチームの開発・運営リードを担当していた。このクラウドチームは、会社の将来の成長エンジンのために作られたものだった。クラウドの世界に対する私の第一印象は、「クラウドはユートピアだ」だった。
クラウドチーム開発運営リード以前の私は、カーネルシステム開発エンジニアとして、毎日毎日1byteのメモリとの戦い、パフォーマンス1sを改善するために、誰も分かってくれない闇の開発世界に閉じ込められていた。しかし、クラウドの世界に来てみると、メモリに問題が起きたら、その根本を解決するのではなく、サーバーの数を増やした。パフォーマンスに問題が起きたら、仕様の良いものにすればいい、そんな新世界だった。このような新世界の喜びは、闇の開発世界で働いたことがある人でなければ理解できないかもしれない。
クラウドチームの開発と運営は、最初はCloudのCも知らない私を含め、外部からクラウドを経験してきた新しいメンバーと一緒にスタートした。私たちはここで、個人・組織・会社が一緒に成熟する過程を経験した。様々なコスト効率化TF(Task Force)を運営し、生産性向上のためにインハウスソリューションを導入した。最終的に驚くべき金額を削減したTFの実質的な行動隊長になったことを覚えている。この過程で私が感じたことをもとに、我々がどういうやり方でコストを削減し、業務を行ったのか、そしてそれがどやってクラウドのほか、他人との効率性につながったのか、このすべてが現在「FinOps」と呼ばれる概念とどうつながるのかを探っていきたい。
2012年-13年のクラウドサービス拡大の黄金期
2012-13年の当時は、FinOpsという概念そのものがなかったので、クラウドへの移行は、我々が多額の費用を費やすきっかけとなった。当時は、クラウドはコストが非常に安いと思われていた。複数のサーバー上で独自に開発したモジュールを乗せ、リソース管理と技術集約を通じて大規模なインフラを運営する過程だった。その過程で時間当たりのデータトランザクションは膨大で、扱わなければならないデータもスーペタデータ環境では想像を超えるレベルだった。そこは、膨大なお金を使う世界であり、これが当たり前だという錯覚の中にいた。たぶん、2015年まではこのような方法で費用を使ったと記憶している。
だが、本当にクラウドへの理解不足のせいでそんなに多くの費用を使ったのだろうか？実際、数十億人のユーザーを対象に画像とファイル転送を管理し、開発と運用を並行して行うことは、クラウドと大容量処理に関する技術的なノウハウがなければ成り立つものではなかった。
当時は急成長するサービスが次々とクラウドに移行する時期で、サービスの安定性と性能を高めるための様々な試みと技術開発が活発に行われていた。お金よりも「拡張性」が重要だった時代だった。何が正しいのかもわからず、とりあえず「突っ込んでみる」黄金期だったと思う。
これが可能だったのは、みんながよく知らなかったからだ。お互いがよく知らなかったということは、コストを執行する部署も、それを見る部署も、クラウドやインフラに対する理解度が低かったということだ。言い換えれば、経営陣や財務チームなどを説得しやすい時代でもあった。
例えをいくつかを挙げると、当時はMSA(マイクロサービスアーキテクチャ)という構造も知らなかったし、問題が発生したら、サーバーを増設して仕様を増やせばいいと思っていた。なぜDBが重要なのかもよくわからなかった。「課題は課題でカバーする」時代だった。
この時代に様々な経験をしたが、例えばこんなものだ。大容量データトラフィックを扱うための技術的な方法論、IO処理の理解、「データはクエリで取り出せばいいんじゃない？」のような初歩的な考え、大容量トラフィックで問題が発生したとき、開発的に解決すればいいと思い込んで、運用を無視していたことなど。
最も記憶に残る経験の一つは、開発コードの修正デプロイを任意に進めちゃって、サービスオープン直前までも安定化ができず、結局、オープン報告をしなければならないその当日までの2泊3日間、サービスの全面障害が発生し、サービスが誕生する前に死にそうになった経験だ。この時、実は開発コード上の問題は解決されていたが、すでに積まれたトラフィックが、それが解消されるまでは問題を持続させるということに気が付かなかった。結局「運営の妙技」でサーバーをオンオフさせることで何とか解決はしたが、この決定を下すまで2泊3日がかかった。
これは、たくさんの非難を受けては文句を言われた経験のおかげというか、クラウドの専門家まではないが、クラウドの歴史の名残と経験で体化された熟練工に発展するきっかけとなってくれた 。今思えば、本当に多くのサービスを自分で作って運営していたこの時期は、貴重な経験だった。どうすればサービス拡張という名目でお金を浪費できるのか、どうすれば上層部をそれらしく説得できるのか、そんなことを知ることができた時期だった。
2014年の全社的なクラウドコスト削減 - FinOpsの概念に似た活動の開始
2014年からは、グローバル経済の不確実性などにより、「コスト削減」が全社的なテーマになった。本格的なクラウドコスト削減活動が始まったのだ。当時は単に予算比30％削減という表面的な目標のもと、本格的なコスト削減活動にとりかかったと記憶している。
このようなコスト削減の流れの中で、クラウド環境の複雑なコスト構造がさらに浮き彫りになっていた。クラウドは、従来の会計や財務の方法とは全く異なる属性を有していたからだ。一般的な会計や財務分野では、年間予算の範囲内でコストを運用するが、 クラウド環境では、リアルタイムで使用量が変動し、正確なコストと予算を予測することが困難だった。クラウドの使用量とコストが天文学的に増加した時期には、このような特性により、サービス品質を維持するために過度に高い仕様を維持したり、初期に設計された構造をコスト効率化のために改善することは難しいという理由から、サービスの改善なしに継続的に運営するやりかたが繰り返されていた。
当時、経営陣や財務部門はこれを「必然的な支出」、つまりグレーゾーン(Grey Zone)と呼び、やむを得ず費用を投入する状況だと受け止めていた。まるで底が抜けた桶に水を注ぐような感覚で、継続的に費用を使い続けた。財務担当者は「勝手にやってくれるだろう」と思って予算を立てたが、いざ執行が始まると予想外の支出が続出し、その時初めて深刻さを認識する仕組みだった。当時は「投資」という認識が強く、不満があってもおおむねスルーされる雰囲気だった。
そんな中、「緊急経営」というキーワードとともに、組織全体に強烈なコスト削減の圧力がかかりはじめた。この当時、クラウド集団にいるにもかかわらず、FinOpsという概念自体は存在しなかった。代わりに、経営革新とコスト削減という原論的な目標のもと、一斉に30%削減を要求され、これを達成できない場合、役員のKPIと評価に反映するという圧力がかかったことで、組織はコストに関心を持ち始めた。
コスト削減活動の最初のステップは、現状把握
まず、コストとリソースを管理する担当者はいるのか、どのような方法でリソースが使われているのかを把握することからスタートした。組織間の複雑な利害関係と隔たりにより、このような情報収集だけで数ヶ月が要された。当時は、クラウドサービスプロバイダ(CSP)もユーザーに対し、コストとリソースの使用状況を明確に提供できない時期だった。
また、内部能力だけでは限界があると判断し、外部診断を並行して行なった。これにより、外部CMPの導入とともに、同様なツールのPOC(Proof of Concept)と自社開発に着手し、マッキンゼーやアクセンチュアなどの外部コンサルティング会社が介入して300-400以上の項目の点検が行われ、本格的な診断を開始した。何百ものエクセルファイルを広げて、組織長に使用履歴を一つ一つ追及していた時代だった。今思えば、このような行動がまったく意味がなかったわけではないが、サービスを知らない状況では一方的な会話に近く、診断する部署と溝が深まるきっかけとなったようだ。「君たちにこのサービスの何が分かるんだ」という気持ちが渦巻いていた時期でもあった。
前述したように、コスト削減活動における問題認識の始まりは現状把握だった。組織ごとにクラウドを利用したことのある人は知っているだろうが、クラウド環境がきちんと管理されないと、ただ請求書を確認することがすべてで、詳細な情報把握が難しく、大きな混乱を経験することになる。このような状況でまず、情報を収集し、整理することからスタートした。
そして、徐々に「既得権」というものが形成され始めた。現状を一番初めに把握して経営陣に報告する組織が比較的大きな影響力を持つようになり、いわゆる「勝ち組」のポジションを占めるようになったのだ。このような構造が定着すると、むしろ信頼が崩れ、「溝が深まる」問題が発生することもあった。それを見守るのも、当時はかなり興味深いものだった。
情報収集が終わると、「この費用をきちんと使っているのか」という質問に移る。理論的にメモリやIO、CPUなどの使用現状を分析し、使用率の低いリソースは無駄だと判断して一括してリソースを縮小するか、削除していた。しかし、クラウド運営に適した設計が最初から正しく行われておらず、サービスに関する十分なドメイン知識もない状態で無理に推進したリソースの縮小は、大規模なサービス障害につながる可能性があった。特に、サービスの本質を十分に理解せずに行った上記のようなアプローチは、予期せぬ問題を引き起こす主な原因となった。前述したように、問題は別の問題で覆い隠すという悪循環を生み出した。
リソースを急激に削減した後に発生したサービス障害により、各組織の担当者は予算を管理する部署に強く反発し、「コスト削減で起きたサービス障害にあなたたちが責任を取れるのか」という言葉が飛び交い、たびたび対立が生じた。結局、組織は適切な妥協線でコスト削減を行うか、反発に屈するかの二者択一を余儀なくされた。
このような中、それなりに売れ行きの良いサービスがなくなるという事件も発生した。逆に、最も多くの費用を使うサービスは、削減すべき要素が多いにもかかわらず、将来の投資価値や様々な利害関係により維持されることもあった。そのサービスは今も順調に運営されていると伺っている。
2015年-18年 マルチクラウドによるコスト分散とCSPと割引率を交渉
2015年から2018年までは、「コスト」という言葉を中心に、サービスに対する理解の欠如と複雑な利害関係により、コスト削減のアプローチに変化が生じ始めた。個人的な見解だが、この変化は2つの方法に分かれていた。
まずCSP(Cloud Service Provider)との割引率の交渉で、それによる内部管理の難しさを割引率を通じて一定部分は相殺できた。これは大企業がCSPに多大な売上を上げてくれていたからこそ可能な方法だった。
第二の方法は、RI(Reserved Instance)を通じた割引の適用だった。当時はSP(Savings Plan)が登場する前だったので、中央でRIを一括管理し、これを組織ごとに配分するやりかたでコスト削減を試みた。しかし、RI管理の複雑さと、適用対処から除外された部署の不満は、深刻な問題として浮上した。特に初期はノウハウがないままRIを運営していたため、適切に管理されていないRIと低いカバレッジ問題で、むしろコスト爆弾になる場合もあった。このような経験は、なぜ今、FinOpsで重要視しているRIやSPのような項目が自動管理される必要があるかをよく示している。
結局、コスト管理戦略は、マルチクラウドによるコスト分散とCSP(Cloud Service Provider)との交渉に発展することになった。このようなアプローチは、昨今のFinOps戦略にも通じるものだが、当時は従業員のクラウドとコスト管理に対する成熟度が十分でなかったため、不満も大きかった。
また、AWSなどの主要CSPが新規サービス導入時に提供するクレジット特典のおかげで、一部の組織ではソリューションを断続的に交換していた。この一連の過程で、これまで経験したことのない様々な新規ソリューションとマルチクラウド環境に接することで、技術的には大きく成長するきっかけとなったが、個人的な観点からは、結局、最大の受益者はCSPだったと思う。なぜなら、当時はまだ大規模なトラフィックとデータを実質的に運用している企業がほとんどなかったので、CSPの立場からすると、実戦のノウハウを得る絶好の機会だったからだ。これらの経験をもとに、CSPはさらに急速な発展を遂げることになる。
一方、クラウドサービスの使用量とデータは増え続け、様々なコスト削減の努力があったにもかかわらず、再びコストが増加する現象が現れ始めた。結局、主要サービスを除き、MAU(月間ユーザー数)が一定レベル以下のものや、売上貢献度が低いサービスに対するコスト削減の圧力が激化した。これにより、運営と開発組織は生き残りのためにアーキテクチャとパフォーマンスの改善について激しい検討を開始し、限られた予算の中でインフラと開発革新が行われ始めた。(運営も含む)
この時期を起点として、一部の組織では、ChatOps、EKSベースの先進的な構造の導入、Terraformの活用、外部SaaSソリューションの使用、サーバーレスアーキテクチャーへの転換など、 より先進的なクラウドアーキテクチャーへの転換に本格的にとりかかった。コストを抑えながら性能を確保するための努力は、文字通り「必死の努力」だった。
それまでは、一部の技術リーダーが全体をリードする構造で、組織内のクラウド成熟度のばらつきも大きかった。しかし、この時期を境に、サービスを担当する人材の開発・運営・コスト管理に対する全体的な成熟度が急速に高まり始めた。特に、無停止運営、ユーザーからのクレーム対応、機能・ソリューションの比較分析と導入失敗の経験、そして運営失敗による残業と財務チームの呼び出しなど、様々なプレッシャーの中で、何とか生き残るための実質的な戦略を探し始めた。言い換えれば、運営のための開発にシフトしたことになる。
そして、このように実行するうち、いかに多くのリソースと人員を非効率的に使っていたかを自らが認識するようになった。このような自覚は、「業務の極悪な自動化」という方向性につながり、自動化のための技術・業務革新が本格化した。理由は簡単だ。そうしないと、仕事が多すぎていつか倒れてしまいそうだったからだ。
このような貴重な経験は、周辺組織との**生存のための技術交流と「技術に見栄を張る」ことを深めるきっかけとなり、さらに部門間の競争とプレッシャーにつながった。「我々のほうがうまい」、「より少ない人員で」、「より少ないコストでサービスを安定的に運営する」という競争が始まったのだ。
2019年、クラウドコストの大幅削減プロジェクト - 本格的なFinOps活動の開始
その後、時間が経ち、数年後、全社的にクラウドコスト大幅削減というプロジェクトがトップダウンミッションになった。「たくさん使うからたくさん減らせ」というシンプルだが強力なメッセージだった。この時から本格的なFinOps活動がスタートしたと言える。当初は戸惑いもあったが、 最適化と効率化、RI/SPの導入、EDP交渉など、利用可能なすべてのカードを総動員して対応した。
組織ごとの利害の対立により、プロジェクトはしばしば難航した。これを打開するために、2つの戦略を併用した。1つはクラウドの専門家で構成されたチームが各サービスのアーキテクチャを徹底的にレビューすることであり、もう1つは 財務チーム主導でFinOpsのようなツールを強制的に導入し、透明なデータを確保して診断を開始するアプローチだった。
当初は一般的に知られている普遍的な方法、つまり未使用リソースの整理やRight Sizingなどのアプローチを試みたが、これはすぐに限界にぶつかった。過去とは異なり、クラウドの成熟度が高まって、サービス品質に対する責任所在の問題が浮上したため、単純なアプローチは結局失敗に終わった。いくら見栄えの良いデータを持って行っても、そのサービスに対する深い理解と責任を求められてしまうと、それを押し付ける部署でさえ躊躇してしまう状況が発生した。
だから新しい方法が必要だった。今ではCSPがリソーススケジューリングやスポットインスタンス管理機能を基本的に提供しているが、当時はCSPにもこのような機能がなかったため、私たちはそれを社内で開発しなければならなかった。これを実証するためにマルタプロジェクトを選定した。実際の動作の有無よりも 「FinOps方式の可能性」を示すことが目的だったので、3か月間準備してテストに入った。これが動作するかどうかは重要ではなかった。FinOps導入を広めるための手段が必要だったからだ。内部的にはそれなりに完成度を上げたとはいえ、短期間で作ったソリューションは様々なバグと混乱を招いた。忍耐が必要なプロセスだったのだ。
紆余曲折の末、直接開発した様々な効率化ソリューション(リソーススケジューリング機能と当時オープンソースを改造して作ったスポット(spot.inst)管理ツール)などを通じて効率化ツールを作った。これを社内で開発・運用している課題で実証を行い、3ヶ月間の極悪な効率化を行った。そこから導き出されたデータをもとに、他の組織にも強制的にそのツールを適用し始めた。単なるツールの導入ではなかった。サービス構造を根本から設計し直し、人的リソースの効率性をチェックした。
このプロセスを「FinOpsツールの効果」と大々的に表現はしたが、実際にコスト削減に最も大きく貢献したのは、もちろん、データ構造の転換、アーキテクチャの近代化、人材の刷新などの構造的な変化だった。この一連の活動は、私が攻撃者ポジションを取ることができるようにしてくれた。そして、クラウドサービス開発者からクラウド運用責任者へ転換するきっかけを作ってくれた。
この経験から得た教訓は、全組織を動かす必要はないということだ。核心的ないくつかの組織の変化を作り出し、その結果に基づいて経営陣と財務チームにコスト削減効果と予測データを提示する。その後、各組織の担当役員にコスト削減をKPIとして割り当てることで参加を誘導した。診断組織はクラウドサービスに対する高い理解度と技術的信頼を基に各部門に必要な実行手段を提供した。このようなアプローチは、現在のFinOpsの哲学-協業ベースのコスト最適化、予測可能な意思決定、実行可能なツールとプロセス-と一致していると言える。
FinOpsツールそのものよりも、 その後の余波で行った節約の方がはるかに大きかった。その頃、最も多く受けた質問は、
「このような方法で効率化をすると、RI/SPよりも節約できるのか」、
「EDPよりも大きな割引になるのか」だった。
当時の基準ではむしろ逆転現象が頻繁に発生した。しかし、重要なのは現在ではなく、将来の構造変更後に発生する長期的な節約効果だった。これを納得させるための議論と説得は熱いものだった。
問題は、持続的な管理がなければ、このような努力も簡単に崩れてしまうことだ。少しでも管理が甘くなると、また元の姿に戻ってしまったり、技術的な負債が累積したり、コストが揺らいでしまう。一度不信感が生じると、今後FinOpsの導入自体を拒否する雰囲気になる。つまり、継続的な努力と革新がなければ、ダイエットのようにまたリバウンドしてしまう。これがFinOpsのエコシステムにおいて非常に重要なポイントだ。
また、どんなに頑張っているつもりでも、外的要因などによってその努力が無駄になることもしばしばあった。代表的なのが為替レートだ。例えば、2021年までに効率化や構造変更に一生懸命に取り組んで一定の削減を達成したのに、為替レートの上昇でその効果が全て相殺された例もある。
がんばって月10億ウォンをも減らしたのに、為替のせいで逆になり、財務では「本当にコスト削減したの？」と言われた。このような一方的なコミュニケーションなども頻繁に起こる(このような時は結局人を減らす悪循環が起こることもある)。おそらく最近の世界経済や韓国の為替レートなどで過去と似たようなことを経験する事例が出ると思われる。歴史は繰り返されるものだ。
さて、ここまでの話は過去の経験である。この経験を少し整理しよう。いつも経営者の危機意識から追及が始まり、組織が応じない時にはKPIなどのミッションと予算で圧迫し働きかけた。もちろん、独自にうまく運営している組織もある。この場合、あえて外部からツールや方法を強制しない。すでにうまくいっているのだから、無駄に手を出して流れを壊さない方がいいからだ。
また、機能的に見ると、 コスト分析、異常検知、リソース提案、マルチクラウドの比較、性能分析、ネットワーク診断など、私たちがよく知っている技術的な方法論はすでに普遍化されている。実際に問題を認識した瞬間、ほとんどの場合、このような技術的なアプローチから試みることになるだろう。
コストを削減する過程 - 単一サービスの運営組織 vs.複数のサービス管理組織
それでは、過去の経験をもとに、現実の世界ではどのようにコスト削減が行われるのか。私たちは果たしてその過程をちゃんと分かっているのだろうか？そこから話を始めよう。
前述したように、必ず何らかのきっかけがある。経営者であろうと誰であろうと、誰かがコストとリソースの使用について問題を提起する。運が良ければ、指摘を受けたときにすぐそれを正しく理解し、自発的に対応すればいいのだが、残念ながらほとんどの場合はそうではない。みんな、やろうとしない。
その理由は明確だ。やったって自分の仕事が増えるだけし、非難を言われる可能性があることを知っているからだ。そして、すでに分かっているから-もっと使うのは簡単だが、減らすのは本当に難しいことを ― 結局、この仕事は3つの基本的な軸で動くことになる。実行する担当者、診断・分析する担当者、そしてこのすべてを評価し、意思決定を行う担当者。ここからさらに拡大すると、 現在FinOps Foundationが定義しているペルソナと同様に、役割がさらに細分化されていく。
一例を挙げると、
「今月の予算は必ず20％削減すること。特にクラウドのコストから減らそう。」
上記のような目標が割り当てられたら、担当者はまずどうするか。
「最近3ヶ月、6ヶ月、1年間のクラウド費用、使ったもの全部持ってきてくれ」 と、コストがこれまで増加したかどうかはともかく、コストデータを集めることからスタートする。
ここで、単一のサービスを行う組織と複数の組織がある場合はアプローチが異なる。
単一サービスを行う組織は、最もコストを多く使っているリソースはなにかというリソース現況分析から始める。そして悩む。「これ減らせるの？」
費用のかかる領域は大抵決まっている。DB(データベース)やネットワークコストだ。一旦、何かアクションを起こすために、 通常、まず未使用のリソースから叩き始める。しかし、実際にやってみると、それによるコスト削減効果は思ったほど大きくない。あるいは、運良く、大きなコストがかかっている管理していなかったリソースを見つけられるかもしれないが、それはあくまで運である。
次に、リストを引く作業だ。どのようなリソースが近代化、つまりRight Sizingできるかを熱心に探す。
何かと調べて「これくらい減らせば、コスト削減したと言えるのでは」と思い、それなりに準備をするが、すぐに悩みが生じる。
「これを減らしたらRI/SPが足りなくなるのでは？」、
「EDPの条件が外れてshortfallが起きたらどうしよう」、
「RI/SPの期限っていつまでだっけ？それまでにこれが可能だろうか？」
このような悩みが生じると、上記のことは対処が難しいので、逆に自分たちが今使っているアカウント全て-運用系、開発系など-を見つめ直し出す。もちろん、順番は変わるかもしれないが、最終的にはすべてのアカウントを一つ一つ見ていくことになる。
ある程度アカウントなどが整理されると、報告は通常、このようなことが堂々と行われる。「このように減らしていけば、今後、コストを効果的に削減することができます。」という1次元的な報告だ。しかし、20％以上減らすことは容易ではない。となると、選択の岐路に立つ。
本当に不要なサービスを降ろすべきなのか？それとも、ここに投入される人員を減らすべきか？
しかし、どちらにしても決して簡単な選択ではない。
そこで、開発や運用の経験がある人なら、ここから本質的な悩みが始まる。
「これは売上にもつながる問題だが、ROIの観点から、私たちのアーキテクチャや設計自体を見直す必要があるのではないか？」
この地点から開発と運営の構造的な変化が始まる。もしこのような議論をせずにそのまま行けば、結局、「不可避的な費用の支出」という名目でグレーゾーン(Grey zone)の中に放置され、組織はその状態を維持し続けることになる。
複数のサービスを管理する組織であれば、流れは似ているが、スタート地点は少し異なる。
ほとんどの組織では、「どの組織が最も多く使っているのか」という質問から出発する。
この方法は、当然、最も多くの費用を使用している組織と、その組織を担当している管理者にスポットライトが当てられる。
もちろん、その費用支出が正当な理由に基づくものだとしても、比較的よく管理されている組織であっても、全体的な費用の数字を合わせるために犠牲になる場合もある。一種の「生贄」になるものだ。
その後はほとんど前述の方法-リストの作成、リソースの整理、アカウントの確認など-をそのまま踏襲することになる。しかし、この過程でも、RI/SPの管理、特定の組織への贔屓、運営ノウハウの違いなどにより、組織間の葛藤が発生しやすい。実際には、特定の担当者に責任が転嫁されることもある。
この時点で、組織内部では自然にコスト配分構造を再検討することになり、各組織の予算と配分内訳をめぐって議論が始まる。もちろん、この状況を誰もが否定的に受け止めるわけではない。むしろ、予算体系が明確になる点で歓迎する組織もあるだろう。
------------------------------------------------
しかし、開発や運営に一定以上の経験がある人であれば、結局は本質的な悩みに直面することになる。コストは売上に直結するため、ROI(投資対効果)を考慮し、私たちのアーキテクチャや設計を根本的に減らすべき時が来たのではないか、という質問を投げかけるようになる。この時点から、開発や運営方法に実質的な変化が起きる。
逆に、このような悩みもせず、単に「必然的な費用の支出」という名目で現状を維持すれば、これはますます継続的なグレーゾーンに突入し、問題はより複雑になるばかりだ。
—-----------------------
上記の事例は、ほとんどの組織が一度は必ず経験する現実的な話だろう。実行を任された部署はできるだけ一生懸命、時には一部を隠しながら仕事を進めるが、結果の報告を受ける側は数字しか見ない。「数字が減ったか減らなかったか」、それだけだ。何をどうしたかは考慮されない。
この時点から組織内部に不協和音が聞こえ始める。
どれだけもがいても、努力の結果より数字だけで判断されると思い始めたら、もうどちらか一つだ。コスト削減を見せかける目的でわざとコストを膨らませて作業をする方法と、現状維持で何とかするかである。この時、資源とコストの分析と現状を調整し始める。
この事例を基準にすると、FinOpsというのはコスト削減が目標ではなく、今我々がちゃんとやっているのか、適正性をもって運営しているかといった現状把握からスタートし、関連部署を説得する一連のメビウスの帯のように動くとものになっていると言える。
いつも悩まされるのは、 Right Sizing, Unused Resource cleanup, Modernization のようなアプローチだ。このような資料に基づいて、私たちがどれだけコストを効率的に使っているか把握できるのかと問われれば、答えははっきりと「Yes」だ。
しかし、そのデータに基づいて、新しい取り組みを今運用中のサービスにそのまま適用できるかという問いに対する答えは、「No」だ。
ここは、よく運営やサービスを直接担当しない部署が簡単だと考えている部分でもある。
サービス運営は非常に保守的であるため、運営上の問題については常に責任という重い言葉がつきまとう。こんなことをしているより、いっそのこともっとお金を使った方がいいと思ってインフラリソースの拡大などをし、コストがさらに増えるケースも出てくる。このサイクルが繰り返されると、基本的な部分を除いて、サービス運営に影響を与えないEDP / RI&SPを事前に購入してコスト削減をする方式になるしかない。時にはプログレッシブに、スケジューラのように使わない時間帯のサーバーを消してより安いリソースを交換するSpotなども考える。しかし、これもサービス運営と責任という枠の中にあって、責任を逃れることはできない。もちろん、ある程度の成熟度があれば、このような部分を自動化し、働く人の業務における選択と集中を考えてくれることもある。
そして、その次のアプローチが人に責任を与えることだ。統制をしろ、投資をしろ、それを担当部署のミッションになるように設定するのだ。なぜなら、これが一番簡単だから...。人を強く圧迫しては「できなければ責任取れ」。これほど簡単なものはないからだ。じゃあ、これをするにはどうすればいいんだろう...。人がエクセルで、または一々文書化し、見つめることもできるだろう。しかしこれも、リソースや組織が小さい場合に可能なことだ。だから、人がよく分類して管理して見られるようにTagを導入し、綺麗に整理して示す。こうすることで、膨大なデータからどの組織がどのリソースをよく使うかを区別して、より簡単に分析できるようになる。
しかし、こんなものを導入することでコストが減るか？答えは「Yes or No」だ。結局、何かしらのアクションを行うためには人が入らなければならないが、本人の責任がなくなると、途中で手を離れることになってしまう。そこで、KPIなど組織のミッションと予算コントロールをし始める。これをコントロールできなくてパーになってしまうケースをたくさん見てきたので、組織の成果として話をすることが多い。
状況がこうなると、どうすれば削減できるのか、内部的にいろいろと悩むことになる。サービスをどのようにすればより少ないコストで提供できるか、運営管理ポイントもどのようにすればより効率的にできるか、これを行うにはサービスの理解と現在自分が使っているリソースに対するコストがどれほど高いかを認識するようになり、最終的にunit economyに発展することになる。
そして人に対する効率の話も出てくるようになる。結局、誰かが責任をもって動けば、回るようになる。ただ、責任を負ったからといって、すべてがうまくいくとは限らない。その人の権限と意志の強さによって変わる場合もたくさんある。そして、この努力は短期的なものかもしれないし、長い時間がかかるかもしれない。しかし、思ったほど、組織に文化が定着していない時点では、有機的に動くことは容易ではないので、この責任を何らかの形で分散させようとする。お互いが喧嘩したくない時は、一緒に仕事して協力し、共同作業でプロジェクトを進めたりする。敵になると、お互いが違う言い訳をし始める。これが最近、FinOpsのFrameworkが技術ベースと企業のビジネスパフォーマンス指標に変わっている理由だ。
また、このデータは、財務的な責任を持つ部署で、データと作業の信頼性を把握するために、Budgetという範囲のなかで、計画した予算・予測に比較してどれだけちゃんと使っているかを説得することが非常に重要になった。このデータの信頼度によって、各組織の自由度が決まるのではないか。そして、それが発展して、一番大事な要素、共通のミッションと実行を行うチームのコミュニケーションが向上していくのだ。
よく「知らないと使いこなせない」という。このサービスを一番分かっているのは、サービスを運営、開発、運営管理する部署だ。先ほど話したように、このような最近のFinOps Foundationの新しいFrameworkの変化がこれを表している。つまり、よくわからないと、なぜたくさん使うのかわからないのだ。昔は、財務と話す時にコストという言葉を使えば、費用を削減できる余地があった。今は、サービスを運営して開発する組織こそがコストに一番詳しくなければならない理由の一つだ。
つまり、様々な部署がFinopsという名目の下、表面的には、無駄なものを見つけて削減しようとかかげるが、 結局、ちゃんと把握できるようにサポートし、それを改善して投資対比で効率的に使うようにする概念だと理解するべきだ。このような基調から、FinOpsのツールは、時間と労力、そして複数の人が使うツールを一つの声、一つの言語で話をする最も基本的な手段と考えてよいだろう。使うお金だけを見る人もいれば、技術用語だけを見る人もおり、KPIなど達成率の数字だけに関心がある人もいる。が、これを構成する基準データは全て同じだ。その詳細が何であれ、お金を払うことは変わらないし、使ったことに対するコスト計算の元データのロジックも変わっていない。
OpsNowのように、すべてのFinopsツールはそれぞれ機能の役割がある。その機能は決して一つの機能だけのために作られたものではなく、 有機的に一つの言語を提供するための手段と考えるべきだ。機能的なユーザビリティなど、違いは千差万別にあり、お互いが見ようとする内容はみんな違う。だけど、結局は、うまく使いこなしているか、より向上できる部分があるかという観点、データに対する見方はそれぞれ違っても、一つの言語で話すことだ。「うまく使っているよね。」、そして「同じ言語で話すのが合っているね」と。
現在、私たちOpsNowは、FinOpsを理解し、導入をしようとする人たちに役立たなければならない立場にある。顧客がどんなツールを使っても構わない。FinOpsを理解するためには、FinOpsについてどれだけ正確に理解しているかを確認する必要がある。その後、どのようなツールであれ、手段を導入するためには、これらの一連の過程をある程度把握した上で始める必要がある。前にも個人的な過去の事例を紹介したが、私はFinOps理論を知らなくても...挑戦をした。無数の失敗と成功を繰り返しながら、何度も何度も試行錯誤をし、それをFinOpsの言葉で包んでいる。つまり、企業は理論そのものが不足しているからではなく、組織内部の経験と挑戦への意志、運営的な理解、担当するサービスの本質、そして一緒に働くにはどうすればいいか、という深い悩みが伴われなかったからだ。理論なんてグーグルで調べるとすぐ出てくる。頭だけで知っているもの、知っているふりは限界がある。
幸いなことに、OpsNowは、MPSであるBespin Globalでたくさんの運営経験し、顧客のニーズに基づいて成長してきた。このような経験をもとに、 FinOpsの領域で、一つの声でFinOpsを物語るために日々努力している。まだまだ先は長いが、経験という財産のもと、サービスを高度化している。
しかし、内部でFinopsの業を営んでいる人は、業に対する深い悩みや経験をもとに、コストコントロールや効率性を考えながら開発を手掛けている人がどれだけいるのかを確認する必要がある。「もちろん上手くやっている」と言いつつも、実際に経験している人とそうでない人では大きな違いがある。そのため、かつてのOpsNowのクラウドコスト削減は、単に製品の機能を紹介してきたこともあったが、今は各機能の必要性と背景を明確に理解し、信頼できるデータに基づいて組織が効果的にアクションを取ることができるストーリーを作成するまでに発展している。以前は機能中心だったのが、今は全体的に同じ言語で見ることができるサービスに進化しており、これをより深く理解し、よく説明できる方向に向かっている。
今、組織内部でクラウドを分析し、費用管理と効果的な削減のために考えられる環境を構築してきたかを顧み、それをよりうまく示すことができるような努力が必要な時期だ。製品とサービスを提供する立場として、この部分に対する徹底した理解と経験は必須である。こんな機能がありますよ、という機能を紹介するレベルを超えて、私たちが本気でFinOpsを理解し、実践し、点検し、導くのがOpsNow FinOpsの立場だ。
FinOpsの本当の始まりは、管理されていないクラウド費用の理解と統制だ。多くの企業がFinOpsを導入することでコスト削減を最大化できると期待するが、実際には必要不可欠な要素ではなく、選択的に活用されることが多い。企業はすでに様々な方法でコスト削減を実践しているし、私たちが特に優れないかもしれない。
コスト削減のための方法論は様々である。CSPとの大規模割引交渉(EDP)、RI/SPの活用、リソースの効率化と最適化などは基本的なアプローチであり、これはFinOpsツールがなくても可能なことだ。それとも、労働力で代替してもいい。ただし、このプロセスは、時間と労力、ビジネスドメインとサービスに対する深い理解がある場合により効果的だ。組織の能力が十分備わっていれば、サービス構造をリアキテクチャリングし、性能最適化を図って費用と効率性を根本的に向上させることができる。
では、なぜFinOpsの哲学が必要で、OpsNowのようなツールが必要なのか、本質的な考察が必要だ。クラウド環境が複雑になり、組織が大きくなればなるほど、管理が難しくなり、責任所在が不明確になり、放置されることが多い。クラウドのコスト特性上、問題が発見された時にはすでに状況が悪化している場合が多く、修正や調整にかなりの時間と労力がかかる。継続的な努力が伴われたときにFinopsは正しく機能するが、そのためのスタートがFinOpsが必要な理由である。
FinOpsは、コストとリソースを定期的に監視し、問題発生を早期に検知してリスクを軽減することができる。これは、リソース効率化とコスト最適化のための第一歩だ。この過程で、組織における透明なデータ管理、予算の統制、ガバナンスの管理や全般的なレポートを行ってコストの流れを明確に知ることが必要だ。この段階でさらに効率的で体系的な管理のための方法論と協業体系を作るのがFinOpsの本質である。
理想的な段階は、自動化を導入し、すべての組織が同じ言語でコミュニケーションできるようにすることだ。そして、継続的にサイクルを回さなければならない。ワンタイムで終わるのであれば、FinOps / FinOpsツールは不要だ。継続的な活動を支援するために、OpsNowのFinOpsが進むべき道は、このような問題をどのように解決し、提供しなければならないのかだ。「機能が開発されたから私たちにもできますよ」じゃなくて...
OpsNow FinOpsが進むべき道
我々が進むべき道と、やるべきことはたくさんある。技術トレンドが過去と違って急速に変化しており、これを補完しなければならないのが私たちの仕事だが、肝心の我々内部でその機能/技術以外のものに対する本質を理解しなければ、いくらAIなど先端技術を導入しても、むしろ新しいAI時代に私たちが食われかもしれないだろうし、すでに浸食されつつある。また、クラウドの成熟度が過去と違って均等に発展している時代だ。レベルの高いサービスと製品の競争力を持つためには、誰よりも内部からこの本質をよく理解しなければならない。
今、OpsNowは韓国内CMPの中でFinOpsを最も得意とする集団として定着しつつある。様々なFinOpsの資格保有、FinOps Certified Platformの取得など、従来の技術だけにこだわるのではなく、どのようなメッセージを伝えるべきかを考えるソリューション、サービスとして発展し続けている。
サービスが発展し、便利になるにつれ、過去と違って大半の人は、これがどのように動くのか、どのように実装されているのかよく知らないまま使っている。以前はリソーススケジューリング、Spot機能は当たり前の機能ではなかったが、今では当たり前の機能かつサービスとなった。つまり、技術の進歩がユーザーの利便性を提供したが、それを理解し、運用しなければならない部分からさらに遠ざかるようになった。
今もクラウドが快適になればなるほど、見えるものだけを見るようにしがちだし。これをどのように動作するのかを理解するケースは稀になっている。このようなサービスを提供する我々こそが掘り下げなければならない部分でもある。人は知っている分だけ見えるものだ。AIなどで、より便利さを求める世の中になったが、それを理解し、きちんと情報を提供する人の役割が減ると思っている。これが現在、私たちが注目すべきOpsNow FinOpsの出発点ではないか。当たり前だと思っていたことは、いつも当たり前ではなかった。しかし、我々が語っているRI/SPの自動管理もいつの間にか当たり前の機能になっているように、サービスの当たり前を作って提供するのも私たちであるべきだと思っている。
OpsNowはFinOpsに関連する製品とサービスを提供する会社である。しかし、我々は、FinOpsというものをどれだけ正しく理解したうえでこのサービスを提供しているのか、から考える必要があるので、私の経験をもとにこの記事を書くことにした。
よく、FinOpsは「必須」、「大流行」、「なくてはならないもの」と言われる。このような話が社内から出ているが、「本当にFinOpsは必要なのか」という疑問から始めるのが正しいのではないだろうか。
「OpsNow FinOpsを導入しないと、クラウドコストを削減できないのか？」OpsNowの代表を務めている私さえもこのようなことを考えているのだから、他の人はもっと疑問に思うだろう。
まず、上記の質問に対する私の答えは「いいえ」だ。しかし、FinOpsは必ず必要なものだと考えている。私の答えが正解ではないかもしれないし、経験が全てへの答えになるとは言い切れないが、経験をもとにいくつかの話をし、個人的な考えを整理したい。
私は2012年から韓国では誰もが知っている大企業のクラウドチームの開発・運営リードを担当していた。このクラウドチームは、会社の将来の成長エンジンのために作られたものだった。クラウドの世界に対する私の第一印象は、「クラウドはユートピアだ」だった。
クラウドチーム開発運営リード以前の私は、カーネルシステム開発エンジニアとして、毎日毎日1byteのメモリとの戦い、パフォーマンス1sを改善するために、誰も分かってくれない闇の開発世界に閉じ込められていた。しかし、クラウドの世界に来てみると、メモリに問題が起きたら、その根本を解決するのではなく、サーバーの数を増やした。パフォーマンスに問題が起きたら、仕様の良いものにすればいい、そんな新世界だった。このような新世界の喜びは、闇の開発世界で働いたことがある人でなければ理解できないかもしれない。
クラウドチームの開発と運営は、最初はCloudのCも知らない私を含め、外部からクラウドを経験してきた新しいメンバーと一緒にスタートした。私たちはここで、個人・組織・会社が一緒に成熟する過程を経験した。様々なコスト効率化TF(Task Force)を運営し、生産性向上のためにインハウスソリューションを導入した。最終的に驚くべき金額を削減したTFの実質的な行動隊長になったことを覚えている。この過程で私が感じたことをもとに、我々がどういうやり方でコストを削減し、業務を行ったのか、そしてそれがどやってクラウドのほか、他人との効率性につながったのか、このすべてが現在「FinOps」と呼ばれる概念とどうつながるのかを探っていきたい。
2012年-13年のクラウドサービス拡大の黄金期
2012-13年の当時は、FinOpsという概念そのものがなかったので、クラウドへの移行は、我々が多額の費用を費やすきっかけとなった。当時は、クラウドはコストが非常に安いと思われていた。複数のサーバー上で独自に開発したモジュールを乗せ、リソース管理と技術集約を通じて大規模なインフラを運営する過程だった。その過程で時間当たりのデータトランザクションは膨大で、扱わなければならないデータもスーペタデータ環境では想像を超えるレベルだった。そこは、膨大なお金を使う世界であり、これが当たり前だという錯覚の中にいた。たぶん、2015年まではこのような方法で費用を使ったと記憶している。
だが、本当にクラウドへの理解不足のせいでそんなに多くの費用を使ったのだろうか？実際、数十億人のユーザーを対象に画像とファイル転送を管理し、開発と運用を並行して行うことは、クラウドと大容量処理に関する技術的なノウハウがなければ成り立つものではなかった。
当時は急成長するサービスが次々とクラウドに移行する時期で、サービスの安定性と性能を高めるための様々な試みと技術開発が活発に行われていた。お金よりも「拡張性」が重要だった時代だった。何が正しいのかもわからず、とりあえず「突っ込んでみる」黄金期だったと思う。
これが可能だったのは、みんながよく知らなかったからだ。お互いがよく知らなかったということは、コストを執行する部署も、それを見る部署も、クラウドやインフラに対する理解度が低かったということだ。言い換えれば、経営陣や財務チームなどを説得しやすい時代でもあった。
例えをいくつかを挙げると、当時はMSA(マイクロサービスアーキテクチャ)という構造も知らなかったし、問題が発生したら、サーバーを増設して仕様を増やせばいいと思っていた。なぜDBが重要なのかもよくわからなかった。「課題は課題でカバーする」時代だった。
この時代に様々な経験をしたが、例えばこんなものだ。大容量データトラフィックを扱うための技術的な方法論、IO処理の理解、「データはクエリで取り出せばいいんじゃない？」のような初歩的な考え、大容量トラフィックで問題が発生したとき、開発的に解決すればいいと思い込んで、運用を無視していたことなど。
最も記憶に残る経験の一つは、開発コードの修正デプロイを任意に進めちゃって、サービスオープン直前までも安定化ができず、結局、オープン報告をしなければならないその当日までの2泊3日間、サービスの全面障害が発生し、サービスが誕生する前に死にそうになった経験だ。この時、実は開発コード上の問題は解決されていたが、すでに積まれたトラフィックが、それが解消されるまでは問題を持続させるということに気が付かなかった。結局「運営の妙技」でサーバーをオンオフさせることで何とか解決はしたが、この決定を下すまで2泊3日がかかった。
これは、たくさんの非難を受けては文句を言われた経験のおかげというか、クラウドの専門家まではないが、クラウドの歴史の名残と経験で体化された熟練工に発展するきっかけとなってくれた 。今思えば、本当に多くのサービスを自分で作って運営していたこの時期は、貴重な経験だった。どうすればサービス拡張という名目でお金を浪費できるのか、どうすれば上層部をそれらしく説得できるのか、そんなことを知ることができた時期だった。
2014年の全社的なクラウドコスト削減 - FinOpsの概念に似た活動の開始
2014年からは、グローバル経済の不確実性などにより、「コスト削減」が全社的なテーマになった。本格的なクラウドコスト削減活動が始まったのだ。当時は単に予算比30％削減という表面的な目標のもと、本格的なコスト削減活動にとりかかったと記憶している。
このようなコスト削減の流れの中で、クラウド環境の複雑なコスト構造がさらに浮き彫りになっていた。クラウドは、従来の会計や財務の方法とは全く異なる属性を有していたからだ。一般的な会計や財務分野では、年間予算の範囲内でコストを運用するが、 クラウド環境では、リアルタイムで使用量が変動し、正確なコストと予算を予測することが困難だった。クラウドの使用量とコストが天文学的に増加した時期には、このような特性により、サービス品質を維持するために過度に高い仕様を維持したり、初期に設計された構造をコスト効率化のために改善することは難しいという理由から、サービスの改善なしに継続的に運営するやりかたが繰り返されていた。
当時、経営陣や財務部門はこれを「必然的な支出」、つまりグレーゾーン(Grey Zone)と呼び、やむを得ず費用を投入する状況だと受け止めていた。まるで底が抜けた桶に水を注ぐような感覚で、継続的に費用を使い続けた。財務担当者は「勝手にやってくれるだろう」と思って予算を立てたが、いざ執行が始まると予想外の支出が続出し、その時初めて深刻さを認識する仕組みだった。当時は「投資」という認識が強く、不満があってもおおむねスルーされる雰囲気だった。
そんな中、「緊急経営」というキーワードとともに、組織全体に強烈なコスト削減の圧力がかかりはじめた。この当時、クラウド集団にいるにもかかわらず、FinOpsという概念自体は存在しなかった。代わりに、経営革新とコスト削減という原論的な目標のもと、一斉に30%削減を要求され、これを達成できない場合、役員のKPIと評価に反映するという圧力がかかったことで、組織はコストに関心を持ち始めた。
コスト削減活動の最初のステップは、現状把握
まず、コストとリソースを管理する担当者はいるのか、どのような方法でリソースが使われているのかを把握することからスタートした。組織間の複雑な利害関係と隔たりにより、このような情報収集だけで数ヶ月が要された。当時は、クラウドサービスプロバイダ(CSP)もユーザーに対し、コストとリソースの使用状況を明確に提供できない時期だった。
また、内部能力だけでは限界があると判断し、外部診断を並行して行なった。これにより、外部CMPの導入とともに、同様なツールのPOC(Proof of Concept)と自社開発に着手し、マッキンゼーやアクセンチュアなどの外部コンサルティング会社が介入して300-400以上の項目の点検が行われ、本格的な診断を開始した。何百ものエクセルファイルを広げて、組織長に使用履歴を一つ一つ追及していた時代だった。今思えば、このような行動がまったく意味がなかったわけではないが、サービスを知らない状況では一方的な会話に近く、診断する部署と溝が深まるきっかけとなったようだ。「君たちにこのサービスの何が分かるんだ」という気持ちが渦巻いていた時期でもあった。
前述したように、コスト削減活動における問題認識の始まりは現状把握だった。組織ごとにクラウドを利用したことのある人は知っているだろうが、クラウド環境がきちんと管理されないと、ただ請求書を確認することがすべてで、詳細な情報把握が難しく、大きな混乱を経験することになる。このような状況でまず、情報を収集し、整理することからスタートした。
そして、徐々に「既得権」というものが形成され始めた。現状を一番初めに把握して経営陣に報告する組織が比較的大きな影響力を持つようになり、いわゆる「勝ち組」のポジションを占めるようになったのだ。このような構造が定着すると、むしろ信頼が崩れ、「溝が深まる」問題が発生することもあった。それを見守るのも、当時はかなり興味深いものだった。
情報収集が終わると、「この費用をきちんと使っているのか」という質問に移る。理論的にメモリやIO、CPUなどの使用現状を分析し、使用率の低いリソースは無駄だと判断して一括してリソースを縮小するか、削除していた。しかし、クラウド運営に適した設計が最初から正しく行われておらず、サービスに関する十分なドメイン知識もない状態で無理に推進したリソースの縮小は、大規模なサービス障害につながる可能性があった。特に、サービスの本質を十分に理解せずに行った上記のようなアプローチは、予期せぬ問題を引き起こす主な原因となった。前述したように、問題は別の問題で覆い隠すという悪循環を生み出した。
リソースを急激に削減した後に発生したサービス障害により、各組織の担当者は予算を管理する部署に強く反発し、「コスト削減で起きたサービス障害にあなたたちが責任を取れるのか」という言葉が飛び交い、たびたび対立が生じた。結局、組織は適切な妥協線でコスト削減を行うか、反発に屈するかの二者択一を余儀なくされた。
このような中、それなりに売れ行きの良いサービスがなくなるという事件も発生した。逆に、最も多くの費用を使うサービスは、削減すべき要素が多いにもかかわらず、将来の投資価値や様々な利害関係により維持されることもあった。そのサービスは今も順調に運営されていると伺っている。
2015年-18年 マルチクラウドによるコスト分散とCSPと割引率を交渉
2015年から2018年までは、「コスト」という言葉を中心に、サービスに対する理解の欠如と複雑な利害関係により、コスト削減のアプローチに変化が生じ始めた。個人的な見解だが、この変化は2つの方法に分かれていた。
まずCSP(Cloud Service Provider)との割引率の交渉で、それによる内部管理の難しさを割引率を通じて一定部分は相殺できた。これは大企業がCSPに多大な売上を上げてくれていたからこそ可能な方法だった。
第二の方法は、RI(Reserved Instance)を通じた割引の適用だった。当時はSP(Savings Plan)が登場する前だったので、中央でRIを一括管理し、これを組織ごとに配分するやりかたでコスト削減を試みた。しかし、RI管理の複雑さと、適用対処から除外された部署の不満は、深刻な問題として浮上した。特に初期はノウハウがないままRIを運営していたため、適切に管理されていないRIと低いカバレッジ問題で、むしろコスト爆弾になる場合もあった。このような経験は、なぜ今、FinOpsで重要視しているRIやSPのような項目が自動管理される必要があるかをよく示している。
結局、コスト管理戦略は、マルチクラウドによるコスト分散とCSP(Cloud Service Provider)との交渉に発展することになった。このようなアプローチは、昨今のFinOps戦略にも通じるものだが、当時は従業員のクラウドとコスト管理に対する成熟度が十分でなかったため、不満も大きかった。
また、AWSなどの主要CSPが新規サービス導入時に提供するクレジット特典のおかげで、一部の組織ではソリューションを断続的に交換していた。この一連の過程で、これまで経験したことのない様々な新規ソリューションとマルチクラウド環境に接することで、技術的には大きく成長するきっかけとなったが、個人的な観点からは、結局、最大の受益者はCSPだったと思う。なぜなら、当時はまだ大規模なトラフィックとデータを実質的に運用している企業がほとんどなかったので、CSPの立場からすると、実戦のノウハウを得る絶好の機会だったからだ。これらの経験をもとに、CSPはさらに急速な発展を遂げることになる。
一方、クラウドサービスの使用量とデータは増え続け、様々なコスト削減の努力があったにもかかわらず、再びコストが増加する現象が現れ始めた。結局、主要サービスを除き、MAU(月間ユーザー数)が一定レベル以下のものや、売上貢献度が低いサービスに対するコスト削減の圧力が激化した。これにより、運営と開発組織は生き残りのためにアーキテクチャとパフォーマンスの改善について激しい検討を開始し、限られた予算の中でインフラと開発革新が行われ始めた。(運営も含む)
この時期を起点として、一部の組織では、ChatOps、EKSベースの先進的な構造の導入、Terraformの活用、外部SaaSソリューションの使用、サーバーレスアーキテクチャーへの転換など、 より先進的なクラウドアーキテクチャーへの転換に本格的にとりかかった。コストを抑えながら性能を確保するための努力は、文字通り「必死の努力」だった。
それまでは、一部の技術リーダーが全体をリードする構造で、組織内のクラウド成熟度のばらつきも大きかった。しかし、この時期を境に、サービスを担当する人材の開発・運営・コスト管理に対する全体的な成熟度が急速に高まり始めた。特に、無停止運営、ユーザーからのクレーム対応、機能・ソリューションの比較分析と導入失敗の経験、そして運営失敗による残業と財務チームの呼び出しなど、様々なプレッシャーの中で、何とか生き残るための実質的な戦略を探し始めた。言い換えれば、運営のための開発にシフトしたことになる。
そして、このように実行するうち、いかに多くのリソースと人員を非効率的に使っていたかを自らが認識するようになった。このような自覚は、「業務の極悪な自動化」という方向性につながり、自動化のための技術・業務革新が本格化した。理由は簡単だ。そうしないと、仕事が多すぎていつか倒れてしまいそうだったからだ。
このような貴重な経験は、周辺組織との**生存のための技術交流と「技術に見栄を張る」ことを深めるきっかけとなり、さらに部門間の競争とプレッシャーにつながった。「我々のほうがうまい」、「より少ない人員で」、「より少ないコストでサービスを安定的に運営する」という競争が始まったのだ。
2019年、クラウドコストの大幅削減プロジェクト - 本格的なFinOps活動の開始
その後、時間が経ち、数年後、全社的にクラウドコスト大幅削減というプロジェクトがトップダウンミッションになった。「たくさん使うからたくさん減らせ」というシンプルだが強力なメッセージだった。この時から本格的なFinOps活動がスタートしたと言える。当初は戸惑いもあったが、 最適化と効率化、RI/SPの導入、EDP交渉など、利用可能なすべてのカードを総動員して対応した。
組織ごとの利害の対立により、プロジェクトはしばしば難航した。これを打開するために、2つの戦略を併用した。1つはクラウドの専門家で構成されたチームが各サービスのアーキテクチャを徹底的にレビューすることであり、もう1つは 財務チーム主導でFinOpsのようなツールを強制的に導入し、透明なデータを確保して診断を開始するアプローチだった。
当初は一般的に知られている普遍的な方法、つまり未使用リソースの整理やRight Sizingなどのアプローチを試みたが、これはすぐに限界にぶつかった。過去とは異なり、クラウドの成熟度が高まって、サービス品質に対する責任所在の問題が浮上したため、単純なアプローチは結局失敗に終わった。いくら見栄えの良いデータを持って行っても、そのサービスに対する深い理解と責任を求められてしまうと、それを押し付ける部署でさえ躊躇してしまう状況が発生した。
だから新しい方法が必要だった。今ではCSPがリソーススケジューリングやスポットインスタンス管理機能を基本的に提供しているが、当時はCSPにもこのような機能がなかったため、私たちはそれを社内で開発しなければならなかった。これを実証するためにマルタプロジェクトを選定した。実際の動作の有無よりも 「FinOps方式の可能性」を示すことが目的だったので、3か月間準備してテストに入った。これが動作するかどうかは重要ではなかった。FinOps導入を広めるための手段が必要だったからだ。内部的にはそれなりに完成度を上げたとはいえ、短期間で作ったソリューションは様々なバグと混乱を招いた。忍耐が必要なプロセスだったのだ。
紆余曲折の末、直接開発した様々な効率化ソリューション(リソーススケジューリング機能と当時オープンソースを改造して作ったスポット(spot.inst)管理ツール)などを通じて効率化ツールを作った。これを社内で開発・運用している課題で実証を行い、3ヶ月間の極悪な効率化を行った。そこから導き出されたデータをもとに、他の組織にも強制的にそのツールを適用し始めた。単なるツールの導入ではなかった。サービス構造を根本から設計し直し、人的リソースの効率性をチェックした。
このプロセスを「FinOpsツールの効果」と大々的に表現はしたが、実際にコスト削減に最も大きく貢献したのは、もちろん、データ構造の転換、アーキテクチャの近代化、人材の刷新などの構造的な変化だった。この一連の活動は、私が攻撃者ポジションを取ることができるようにしてくれた。そして、クラウドサービス開発者からクラウド運用責任者へ転換するきっかけを作ってくれた。
この経験から得た教訓は、全組織を動かす必要はないということだ。核心的ないくつかの組織の変化を作り出し、その結果に基づいて経営陣と財務チームにコスト削減効果と予測データを提示する。その後、各組織の担当役員にコスト削減をKPIとして割り当てることで参加を誘導した。診断組織はクラウドサービスに対する高い理解度と技術的信頼を基に各部門に必要な実行手段を提供した。このようなアプローチは、現在のFinOpsの哲学-協業ベースのコスト最適化、予測可能な意思決定、実行可能なツールとプロセス-と一致していると言える。
FinOpsツールそのものよりも、 その後の余波で行った節約の方がはるかに大きかった。その頃、最も多く受けた質問は、
「このような方法で効率化をすると、RI/SPよりも節約できるのか」、
「EDPよりも大きな割引になるのか」だった。
当時の基準ではむしろ逆転現象が頻繁に発生した。しかし、重要なのは現在ではなく、将来の構造変更後に発生する長期的な節約効果だった。これを納得させるための議論と説得は熱いものだった。
問題は、持続的な管理がなければ、このような努力も簡単に崩れてしまうことだ。少しでも管理が甘くなると、また元の姿に戻ってしまったり、技術的な負債が累積したり、コストが揺らいでしまう。一度不信感が生じると、今後FinOpsの導入自体を拒否する雰囲気になる。つまり、継続的な努力と革新がなければ、ダイエットのようにまたリバウンドしてしまう。これがFinOpsのエコシステムにおいて非常に重要なポイントだ。
また、どんなに頑張っているつもりでも、外的要因などによってその努力が無駄になることもしばしばあった。代表的なのが為替レートだ。例えば、2021年までに効率化や構造変更に一生懸命に取り組んで一定の削減を達成したのに、為替レートの上昇でその効果が全て相殺された例もある。
がんばって月10億ウォンをも減らしたのに、為替のせいで逆になり、財務では「本当にコスト削減したの？」と言われた。このような一方的なコミュニケーションなども頻繁に起こる(このような時は結局人を減らす悪循環が起こることもある)。おそらく最近の世界経済や韓国の為替レートなどで過去と似たようなことを経験する事例が出ると思われる。歴史は繰り返されるものだ。
さて、ここまでの話は過去の経験である。この経験を少し整理しよう。いつも経営者の危機意識から追及が始まり、組織が応じない時にはKPIなどのミッションと予算で圧迫し働きかけた。もちろん、独自にうまく運営している組織もある。この場合、あえて外部からツールや方法を強制しない。すでにうまくいっているのだから、無駄に手を出して流れを壊さない方がいいからだ。
また、機能的に見ると、 コスト分析、異常検知、リソース提案、マルチクラウドの比較、性能分析、ネットワーク診断など、私たちがよく知っている技術的な方法論はすでに普遍化されている。実際に問題を認識した瞬間、ほとんどの場合、このような技術的なアプローチから試みることになるだろう。
コストを削減する過程 - 単一サービスの運営組織 vs.複数のサービス管理組織
それでは、過去の経験をもとに、現実の世界ではどのようにコスト削減が行われるのか。私たちは果たしてその過程をちゃんと分かっているのだろうか？そこから話を始めよう。
前述したように、必ず何らかのきっかけがある。経営者であろうと誰であろうと、誰かがコストとリソースの使用について問題を提起する。運が良ければ、指摘を受けたときにすぐそれを正しく理解し、自発的に対応すればいいのだが、残念ながらほとんどの場合はそうではない。みんな、やろうとしない。
その理由は明確だ。やったって自分の仕事が増えるだけし、非難を言われる可能性があることを知っているからだ。そして、すでに分かっているから-もっと使うのは簡単だが、減らすのは本当に難しいことを ― 結局、この仕事は3つの基本的な軸で動くことになる。実行する担当者、診断・分析する担当者、そしてこのすべてを評価し、意思決定を行う担当者。ここからさらに拡大すると、 現在FinOps Foundationが定義しているペルソナと同様に、役割がさらに細分化されていく。
一例を挙げると、
「今月の予算は必ず20％削減すること。特にクラウドのコストから減らそう。」
上記のような目標が割り当てられたら、担当者はまずどうするか。
「最近3ヶ月、6ヶ月、1年間のクラウド費用、使ったもの全部持ってきてくれ」 と、コストがこれまで増加したかどうかはともかく、コストデータを集めることからスタートする。
ここで、単一のサービスを行う組織と複数の組織がある場合はアプローチが異なる。
単一サービスを行う組織は、最もコストを多く使っているリソースはなにかというリソース現況分析から始める。そして悩む。「これ減らせるの？」
費用のかかる領域は大抵決まっている。DB(データベース)やネットワークコストだ。一旦、何かアクションを起こすために、 通常、まず未使用のリソースから叩き始める。しかし、実際にやってみると、それによるコスト削減効果は思ったほど大きくない。あるいは、運良く、大きなコストがかかっている管理していなかったリソースを見つけられるかもしれないが、それはあくまで運である。
次に、リストを引く作業だ。どのようなリソースが近代化、つまりRight Sizingできるかを熱心に探す。
何かと調べて「これくらい減らせば、コスト削減したと言えるのでは」と思い、それなりに準備をするが、すぐに悩みが生じる。
「これを減らしたらRI/SPが足りなくなるのでは？」、
「EDPの条件が外れてshortfallが起きたらどうしよう」、
「RI/SPの期限っていつまでだっけ？それまでにこれが可能だろうか？」
このような悩みが生じると、上記のことは対処が難しいので、逆に自分たちが今使っているアカウント全て-運用系、開発系など-を見つめ直し出す。もちろん、順番は変わるかもしれないが、最終的にはすべてのアカウントを一つ一つ見ていくことになる。
ある程度アカウントなどが整理されると、報告は通常、このようなことが堂々と行われる。「このように減らしていけば、今後、コストを効果的に削減することができます。」という1次元的な報告だ。しかし、20％以上減らすことは容易ではない。となると、選択の岐路に立つ。
本当に不要なサービスを降ろすべきなのか？それとも、ここに投入される人員を減らすべきか？
しかし、どちらにしても決して簡単な選択ではない。
そこで、開発や運用の経験がある人なら、ここから本質的な悩みが始まる。
「これは売上にもつながる問題だが、ROIの観点から、私たちのアーキテクチャや設計自体を見直す必要があるのではないか？」
この地点から開発と運営の構造的な変化が始まる。もしこのような議論をせずにそのまま行けば、結局、「不可避的な費用の支出」という名目でグレーゾーン(Grey zone)の中に放置され、組織はその状態を維持し続けることになる。
複数のサービスを管理する組織であれば、流れは似ているが、スタート地点は少し異なる。
ほとんどの組織では、「どの組織が最も多く使っているのか」という質問から出発する。
この方法は、当然、最も多くの費用を使用している組織と、その組織を担当している管理者にスポットライトが当てられる。
もちろん、その費用支出が正当な理由に基づくものだとしても、比較的よく管理されている組織であっても、全体的な費用の数字を合わせるために犠牲になる場合もある。一種の「生贄」になるものだ。
その後はほとんど前述の方法-リストの作成、リソースの整理、アカウントの確認など-をそのまま踏襲することになる。しかし、この過程でも、RI/SPの管理、特定の組織への贔屓、運営ノウハウの違いなどにより、組織間の葛藤が発生しやすい。実際には、特定の担当者に責任が転嫁されることもある。
この時点で、組織内部では自然にコスト配分構造を再検討することになり、各組織の予算と配分内訳をめぐって議論が始まる。もちろん、この状況を誰もが否定的に受け止めるわけではない。むしろ、予算体系が明確になる点で歓迎する組織もあるだろう。
------------------------------------------------
しかし、開発や運営に一定以上の経験がある人であれば、結局は本質的な悩みに直面することになる。コストは売上に直結するため、ROI(投資対効果)を考慮し、私たちのアーキテクチャや設計を根本的に減らすべき時が来たのではないか、という質問を投げかけるようになる。この時点から、開発や運営方法に実質的な変化が起きる。
逆に、このような悩みもせず、単に「必然的な費用の支出」という名目で現状を維持すれば、これはますます継続的なグレーゾーンに突入し、問題はより複雑になるばかりだ。
—-----------------------
上記の事例は、ほとんどの組織が一度は必ず経験する現実的な話だろう。実行を任された部署はできるだけ一生懸命、時には一部を隠しながら仕事を進めるが、結果の報告を受ける側は数字しか見ない。「数字が減ったか減らなかったか」、それだけだ。何をどうしたかは考慮されない。
この時点から組織内部に不協和音が聞こえ始める。
どれだけもがいても、努力の結果より数字だけで判断されると思い始めたら、もうどちらか一つだ。コスト削減を見せかける目的でわざとコストを膨らませて作業をする方法と、現状維持で何とかするかである。この時、資源とコストの分析と現状を調整し始める。
この事例を基準にすると、FinOpsというのはコスト削減が目標ではなく、今我々がちゃんとやっているのか、適正性をもって運営しているかといった現状把握からスタートし、関連部署を説得する一連のメビウスの帯のように動くとものになっていると言える。
いつも悩まされるのは、 Right Sizing, Unused Resource cleanup, Modernization のようなアプローチだ。このような資料に基づいて、私たちがどれだけコストを効率的に使っているか把握できるのかと問われれば、答えははっきりと「Yes」だ。
しかし、そのデータに基づいて、新しい取り組みを今運用中のサービスにそのまま適用できるかという問いに対する答えは、「No」だ。
ここは、よく運営やサービスを直接担当しない部署が簡単だと考えている部分でもある。
サービス運営は非常に保守的であるため、運営上の問題については常に責任という重い言葉がつきまとう。こんなことをしているより、いっそのこともっとお金を使った方がいいと思ってインフラリソースの拡大などをし、コストがさらに増えるケースも出てくる。このサイクルが繰り返されると、基本的な部分を除いて、サービス運営に影響を与えないEDP / RI&SPを事前に購入してコスト削減をする方式になるしかない。時にはプログレッシブに、スケジューラのように使わない時間帯のサーバーを消してより安いリソースを交換するSpotなども考える。しかし、これもサービス運営と責任という枠の中にあって、責任を逃れることはできない。もちろん、ある程度の成熟度があれば、このような部分を自動化し、働く人の業務における選択と集中を考えてくれることもある。
そして、その次のアプローチが人に責任を与えることだ。統制をしろ、投資をしろ、それを担当部署のミッションになるように設定するのだ。なぜなら、これが一番簡単だから...。人を強く圧迫しては「できなければ責任取れ」。これほど簡単なものはないからだ。じゃあ、これをするにはどうすればいいんだろう...。人がエクセルで、または一々文書化し、見つめることもできるだろう。しかしこれも、リソースや組織が小さい場合に可能なことだ。だから、人がよく分類して管理して見られるようにTagを導入し、綺麗に整理して示す。こうすることで、膨大なデータからどの組織がどのリソースをよく使うかを区別して、より簡単に分析できるようになる。
しかし、こんなものを導入することでコストが減るか？答えは「Yes or No」だ。結局、何かしらのアクションを行うためには人が入らなければならないが、本人の責任がなくなると、途中で手を離れることになってしまう。そこで、KPIなど組織のミッションと予算コントロールをし始める。これをコントロールできなくてパーになってしまうケースをたくさん見てきたので、組織の成果として話をすることが多い。
状況がこうなると、どうすれば削減できるのか、内部的にいろいろと悩むことになる。サービスをどのようにすればより少ないコストで提供できるか、運営管理ポイントもどのようにすればより効率的にできるか、これを行うにはサービスの理解と現在自分が使っているリソースに対するコストがどれほど高いかを認識するようになり、最終的にunit economyに発展することになる。
そして人に対する効率の話も出てくるようになる。結局、誰かが責任をもって動けば、回るようになる。ただ、責任を負ったからといって、すべてがうまくいくとは限らない。その人の権限と意志の強さによって変わる場合もたくさんある。そして、この努力は短期的なものかもしれないし、長い時間がかかるかもしれない。しかし、思ったほど、組織に文化が定着していない時点では、有機的に動くことは容易ではないので、この責任を何らかの形で分散させようとする。お互いが喧嘩したくない時は、一緒に仕事して協力し、共同作業でプロジェクトを進めたりする。敵になると、お互いが違う言い訳をし始める。これが最近、FinOpsのFrameworkが技術ベースと企業のビジネスパフォーマンス指標に変わっている理由だ。
また、このデータは、財務的な責任を持つ部署で、データと作業の信頼性を把握するために、Budgetという範囲のなかで、計画した予算・予測に比較してどれだけちゃんと使っているかを説得することが非常に重要になった。このデータの信頼度によって、各組織の自由度が決まるのではないか。そして、それが発展して、一番大事な要素、共通のミッションと実行を行うチームのコミュニケーションが向上していくのだ。
よく「知らないと使いこなせない」という。このサービスを一番分かっているのは、サービスを運営、開発、運営管理する部署だ。先ほど話したように、このような最近のFinOps Foundationの新しいFrameworkの変化がこれを表している。つまり、よくわからないと、なぜたくさん使うのかわからないのだ。昔は、財務と話す時にコストという言葉を使えば、費用を削減できる余地があった。今は、サービスを運営して開発する組織こそがコストに一番詳しくなければならない理由の一つだ。
つまり、様々な部署がFinopsという名目の下、表面的には、無駄なものを見つけて削減しようとかかげるが、 結局、ちゃんと把握できるようにサポートし、それを改善して投資対比で効率的に使うようにする概念だと理解するべきだ。このような基調から、FinOpsのツールは、時間と労力、そして複数の人が使うツールを一つの声、一つの言語で話をする最も基本的な手段と考えてよいだろう。使うお金だけを見る人もいれば、技術用語だけを見る人もおり、KPIなど達成率の数字だけに関心がある人もいる。が、これを構成する基準データは全て同じだ。その詳細が何であれ、お金を払うことは変わらないし、使ったことに対するコスト計算の元データのロジックも変わっていない。
OpsNowのように、すべてのFinopsツールはそれぞれ機能の役割がある。その機能は決して一つの機能だけのために作られたものではなく、 有機的に一つの言語を提供するための手段と考えるべきだ。機能的なユーザビリティなど、違いは千差万別にあり、お互いが見ようとする内容はみんな違う。だけど、結局は、うまく使いこなしているか、より向上できる部分があるかという観点、データに対する見方はそれぞれ違っても、一つの言語で話すことだ。「うまく使っているよね。」、そして「同じ言語で話すのが合っているね」と。
現在、私たちOpsNowは、FinOpsを理解し、導入をしようとする人たちに役立たなければならない立場にある。顧客がどんなツールを使っても構わない。FinOpsを理解するためには、FinOpsについてどれだけ正確に理解しているかを確認する必要がある。その後、どのようなツールであれ、手段を導入するためには、これらの一連の過程をある程度把握した上で始める必要がある。前にも個人的な過去の事例を紹介したが、私はFinOps理論を知らなくても...挑戦をした。無数の失敗と成功を繰り返しながら、何度も何度も試行錯誤をし、それをFinOpsの言葉で包んでいる。つまり、企業は理論そのものが不足しているからではなく、組織内部の経験と挑戦への意志、運営的な理解、担当するサービスの本質、そして一緒に働くにはどうすればいいか、という深い悩みが伴われなかったからだ。理論なんてグーグルで調べるとすぐ出てくる。頭だけで知っているもの、知っているふりは限界がある。
幸いなことに、OpsNowは、MPSであるBespin Globalでたくさんの運営経験し、顧客のニーズに基づいて成長してきた。このような経験をもとに、 FinOpsの領域で、一つの声でFinOpsを物語るために日々努力している。まだまだ先は長いが、経験という財産のもと、サービスを高度化している。
しかし、内部でFinopsの業を営んでいる人は、業に対する深い悩みや経験をもとに、コストコントロールや効率性を考えながら開発を手掛けている人がどれだけいるのかを確認する必要がある。「もちろん上手くやっている」と言いつつも、実際に経験している人とそうでない人では大きな違いがある。そのため、かつてのOpsNowのクラウドコスト削減は、単に製品の機能を紹介してきたこともあったが、今は各機能の必要性と背景を明確に理解し、信頼できるデータに基づいて組織が効果的にアクションを取ることができるストーリーを作成するまでに発展している。以前は機能中心だったのが、今は全体的に同じ言語で見ることができるサービスに進化しており、これをより深く理解し、よく説明できる方向に向かっている。
今、組織内部でクラウドを分析し、費用管理と効果的な削減のために考えられる環境を構築してきたかを顧み、それをよりうまく示すことができるような努力が必要な時期だ。製品とサービスを提供する立場として、この部分に対する徹底した理解と経験は必須である。こんな機能がありますよ、という機能を紹介するレベルを超えて、私たちが本気でFinOpsを理解し、実践し、点検し、導くのがOpsNow FinOpsの立場だ。
FinOpsの本当の始まりは、管理されていないクラウド費用の理解と統制だ。多くの企業がFinOpsを導入することでコスト削減を最大化できると期待するが、実際には必要不可欠な要素ではなく、選択的に活用されることが多い。企業はすでに様々な方法でコスト削減を実践しているし、私たちが特に優れないかもしれない。
コスト削減のための方法論は様々である。CSPとの大規模割引交渉(EDP)、RI/SPの活用、リソースの効率化と最適化などは基本的なアプローチであり、これはFinOpsツールがなくても可能なことだ。それとも、労働力で代替してもいい。ただし、このプロセスは、時間と労力、ビジネスドメインとサービスに対する深い理解がある場合により効果的だ。組織の能力が十分備わっていれば、サービス構造をリアキテクチャリングし、性能最適化を図って費用と効率性を根本的に向上させることができる。
では、なぜFinOpsの哲学が必要で、OpsNowのようなツールが必要なのか、本質的な考察が必要だ。クラウド環境が複雑になり、組織が大きくなればなるほど、管理が難しくなり、責任所在が不明確になり、放置されることが多い。クラウドのコスト特性上、問題が発見された時にはすでに状況が悪化している場合が多く、修正や調整にかなりの時間と労力がかかる。継続的な努力が伴われたときにFinopsは正しく機能するが、そのためのスタートがFinOpsが必要な理由である。
FinOpsは、コストとリソースを定期的に監視し、問題発生を早期に検知してリスクを軽減することができる。これは、リソース効率化とコスト最適化のための第一歩だ。この過程で、組織における透明なデータ管理、予算の統制、ガバナンスの管理や全般的なレポートを行ってコストの流れを明確に知ることが必要だ。この段階でさらに効率的で体系的な管理のための方法論と協業体系を作るのがFinOpsの本質である。
理想的な段階は、自動化を導入し、すべての組織が同じ言語でコミュニケーションできるようにすることだ。そして、継続的にサイクルを回さなければならない。ワンタイムで終わるのであれば、FinOps / FinOpsツールは不要だ。継続的な活動を支援するために、OpsNowのFinOpsが進むべき道は、このような問題をどのように解決し、提供しなければならないのかだ。「機能が開発されたから私たちにもできますよ」じゃなくて...
OpsNow FinOpsが進むべき道
我々が進むべき道と、やるべきことはたくさんある。技術トレンドが過去と違って急速に変化しており、これを補完しなければならないのが私たちの仕事だが、肝心の我々内部でその機能/技術以外のものに対する本質を理解しなければ、いくらAIなど先端技術を導入しても、むしろ新しいAI時代に私たちが食われかもしれないだろうし、すでに浸食されつつある。また、クラウドの成熟度が過去と違って均等に発展している時代だ。レベルの高いサービスと製品の競争力を持つためには、誰よりも内部からこの本質をよく理解しなければならない。
今、OpsNowは韓国内CMPの中でFinOpsを最も得意とする集団として定着しつつある。様々なFinOpsの資格保有、FinOps Certified Platformの取得など、従来の技術だけにこだわるのではなく、どのようなメッセージを伝えるべきかを考えるソリューション、サービスとして発展し続けている。
サービスが発展し、便利になるにつれ、過去と違って大半の人は、これがどのように動くのか、どのように実装されているのかよく知らないまま使っている。以前はリソーススケジューリング、Spot機能は当たり前の機能ではなかったが、今では当たり前の機能かつサービスとなった。つまり、技術の進歩がユーザーの利便性を提供したが、それを理解し、運用しなければならない部分からさらに遠ざかるようになった。
今もクラウドが快適になればなるほど、見えるものだけを見るようにしがちだし。これをどのように動作するのかを理解するケースは稀になっている。このようなサービスを提供する我々こそが掘り下げなければならない部分でもある。人は知っている分だけ見えるものだ。AIなどで、より便利さを求める世の中になったが、それを理解し、きちんと情報を提供する人の役割が減ると思っている。これが現在、私たちが注目すべきOpsNow FinOpsの出発点ではないか。当たり前だと思っていたことは、いつも当たり前ではなかった。しかし、我々が語っているRI/SPの自動管理もいつの間にか当たり前の機能になっているように、サービスの当たり前を作って提供するのも私たちであるべきだと思っている。
