キーポイント
- FinOps is the latest addition to the DevOps toolset and "shift left" mindset
- We are in a point in time where financial efficiency is that much more crucial to any organization's success
- As with any endeavour, the team practicing it is the most crucial part
- While cloud billing visibility may be limited, there are simple ways to expand on it using an analytical database
- The most relevant cost dimensions are in your operational data and not in your invoice (e.g. traffic, customer usage)
あなたがクラウドにたくさんの費用を使っていることはご存知でしょう。では、その費用のどれだけが本当に必要なのでしょうか？費用の効率を改善することは可能でしょうか？これらは、クラウドでワークロードを運用しているすべてのチームや企業に影響する疑問です。世界経済がパンデミックの影響で減速している今、企業の利益を守るために、あるいは、最悪のケースでは、企業が存続するために、無駄の削減(cutting fat)は極めて重要です。
スタートアップとして急成長を遂げたPerimeterX (私が勤務する企業) では、自分たちのビジネスに — プラスとマイナス、両方の意味で — 大きく影響するインフラストラクチャ費用がブラックボックスであると認識した数年前から、FinOpsについて検討を始めていました。DevOpsに関わる者なら誰しもが、驚愕のクラウド費用に関するホラーストーリについて読んだ(あるいは、実際にその渦中にいた)ことがあるでしょう。 開発チームがミスをしたり、誰かが大規模な一時的クラスタのシャットダウンを忘れていたり、あるいはスケールアップイベントへの緊急対応がタイムリに解消されなかったりした時、このような状況が発生します。FinOpsの目標は、クラウドインフラストラクチャを管理するチームによる費用の分析と調査を、さらにはクラウドサービス間の関係に関する仮説のテストを可能にして、このような災害を防止することにあります。
驚くでしょうか？FinOpsというテーマに踏み込んだことによって、私たちは、優れたFinOpsプラクティスが費用削減だけではなく、よりよいカスタマエクスペリエンスやもっとスマートなプロダクトデザインにもつながるのだ、ということに気づいたのです。
FinOpsとは何か？
ほとんどの読者にとって、初めて聞くコンセプトかも知れません。FinOps Foundationによる定義が、その内容をうまく表現しています。
FinOpsはクラウドの運用モデルです。FinOpsは、組織がクラウドのコストを理解し、トレードオフを行う能力を向上させるためのシフト — システムのコンビネーション、ベストプラクティス、文化 — を可能にします。DevOpsはサイロを破壊し、アジリティを向上させることによって、開発業務に革命を起こしました。同じようにFinOpsは、技術、営業、財務のプロフェッショナルを新たなプロセスセットに集結させることにより、クラウドのビジネスバリューを向上します。
簡単に言うと、FinOpsとは、DevOpsと同じ原則をクラウド資産とインフラストラクチャの財務管理、運用管理に適用するものです。究極的にはこれらの資産を、人の介在ではなくコードを通じて管理する、という意味も含んでいます。これを効率的に行うために、FinOpsの実践者には、カスタマの使用パターンとプロダクトの要求パターンの両方を理解し、この2つを適切にマップすることによって、カスタマエクスペリエンスの最適化を継続しながら価値を最大化することが求められます。
PerimeterXのFinOpsへの旅立ちはいかにして始まったか
最初は"なぜこれをやるのか？"という問いかけで始まりました。最初の理由はマージンを改善し、クラウド費用をもっとよく管理するためだったのですが、後になって、インフラストラクチャ哲学に対するより明快なビジョンを得るためや、Dev/DevOps/財務チームの間のコミュニケーションギャップに橋を架けるためにも、FinOpsを利用できることに気付きました。当時の私たちが注目し、解決したいと望んでいた問題は、おもに次のようなものでした。
- 開発チームがアーキテクチャ判断において、経済的な影響を必ずしも考慮していない
- DevOpsチームのコスト最適化目標とプロダクトの機能を一致させることが難しい
- 財務チームが1～2ヶ月前の請求書を使ってマネジメントチームに情報提供しているため、意思決定や、支出の増加している領域の特定が困難である
- 現在および将来の費用に関してDevチーム、DevOpsチーム、財務チームの間で行われるコミュニケーションが、多くの場合において遅く、効果のないものになっている
FinOpsのプログラムとマインドセットを採用することによって、それぞれのチームが考え方を同じくし、価値観を一致させ、日々の意思決定プロセスにおいてメトリクスを追跡するフレームワークを共有することが可能になったのです。
PerimeterXの実践するFinOps
PerimeterXは、企業のWebアプリケーションやモバイルアプリやAPIを、悪意を持ったbotやMagecartのようなスキミング攻撃から防御する、SaaSセキュリティ企業です。ビジネスオペレーションとエンジニアリングの一部がシリコンバレーにいますが、開発チームの主力はイスラエルにあります。
FinOpsに関する私たちの取り組みは、3年前、クラウド費用を理解し、把握し、よりよく管理するための活動として始まりました。業務の拡大に伴い、クラウド費用を最適化することが当社のマージン全体に重大な影響のあることが分かったためです。FinOpsへの取り組みは、クラウドの費用の算出と管理のためのツーリングを開発する社内R&Dプロジェクトとして始まりました。クラウドの費用は、アプリケーションの使用方法やパフォーマンスとも強い結び付きがあり、その影響は個々のカスタマにまで及んでいました。PerimeterXでは、複数の社内チームがクラウドインフラストラクチャを使用している他、特別なニーズを満足するための社内プロダクトの開発も頻繁に行っています。R&Dチームの次に位置するエンジニアリングチームが、これらのプロダクトを開発するユニットです。新機能に関するリサーチと開発もエンジニアリングチームが行います。機能がプロダクトロードマップに予定として記載され、運用への投入が決定すると、エンジニアリングチームがその開発を引き継ぎます。
私たちがFinOpsプロジェクトを立ち上げた頃、開発に使用する資料はフラットなデータファイルがすべてで、重要な情報が不足していました。指定されたプロジェクトや研究展開に対して、金銭的価値を帰属させるための簡単な手段がなかったのです。言うまでもなく、これは悪夢でした。出発点を作るにあたっては、社内のクラウド費用のパターンを大雑把に計算した概算値を使って、手作業で多くのデータを補足する以外に方法がなかったのです。計算した数値は(控えめに言って)正確なものではありませんでしたが、次のような理由があったため、当初掲げた目標が変更されることはありませんでした。
- R&Dに配分する予算の立案と維持、および研究、ステージング、その他のR&Dクラウド支出(運用環境への展開とセールスやマーケティング機能での支出は除く)における月毎実績の追跡
- 提供したトラフィックやカスタマの所在地などの重要な変数に対する、新しいプロダクト機能の依存度を表現するためのモデル構築
フラットファイルから詳細なクラウドサービス追跡へ — FinOpsの実践
Google Cloudが詳細な費用情報のエクスポート機能をロールアウトして、同社の分析データベースであるBigQueryに直接転送できるようになったことは、私たちにとって大きな転換点になりました。リッチで詳細な情報をGCPの使用状況データから自動取得できるようになったという点において、この機能はまさに、私たちのFinOpsへの取り組みにおける啓蒙時代(Age of Enlightenment)の到来を告げるものでした。
運用を数値化する必要性から、当社はその頃すでに、システム内の各サブシステムとサービスに対する詳細なラベリングを行っていました。例えば、各インスタンスに対して、それぞれがホストするサービスやストレージバケット、データベースインスタンス、テーブルなどを添記したのです。レイテンシや稼働時間を追跡するために、ラベルの運用監視機能も追加していました。基本的には、リテール用語で言う"SKU(Stock Keeping Unit)"を導入して、クラウドプロバイダがすでに使用しているSKUに追加する形で、システムの各コンポーネントにSKUを定義したのです。ラベルの導入によって、サービスの使用量をサービスのコストや効率性、稼働時間にマッピングしたり、DevOpsと運用監視を財務モデルやコストモデルにリンクすることが容易になりました。
これが実現するまで、財務の最適化プロセスは、部分的に正確なデータ、あるいは自動スケール機能を持たないコアやメモリ、ディスク容量といった単純なメトリクスを中心に構築されていたのです。このリッチなラベルを、BigQueryや更新頻度の高いすべてのクラウドプロバイダ情報と統合することで、パフォーマンスとコストとのトレードオフに関するQ&Aが行えるようになりました。つまり、問題に対処するための２、３の方法について、仮説を立て、それをテストすることが可能になったのです。会社の成長が加速し、クラウドインフラストラクチャのコスト上昇というリスクが顕在化する中にあって、この機能のおかげで、私たちの行うプロダクトとデプロイメントの選択による影響がより明確に把握できるようになりました。
FinOpsのレンズで見たクラウド支出とプロダクト選択の検討
2019年の初め、新たなFinOpsのマイクロスコープ(つまりBigQuery)を使ってネットワークを調査していた私たちは、驚くべき事実に突き当たりました。当時はちょうど、さまざまなPoP(Points of Presence)にわたる計算結果を同期するために、新たなサービス(ここでは"the syncr"と呼びましょう)を追加したところでした。PoPをさらに追加したいと考えていた私たちは、その潜在的コストを理解したいと思ったのです。
その一部を詳細に調査したところ、ネットワークコストの大部分をリージョン間のネットワーク通信が占めていて、それが"syncr"サービスによるものであることが分かりました。(詳細は下記イメージ1および2を参照)"syncr"を開発したチームはすぐさまレビューを開始し、間もなく、syncrのメッセージがすべて2回送信されているというバグを発見しました。システムが冪等(複数回実行しても同じ結果になる)性を持つように設計されていたため、処理には影響がなかったことが、FinOps調査としてネットワークコストを見直すまでバグが発覚しなかった原因になっていました。
イメージ 1 — タイプ別のネットワーク費用
イメージ 2 — バグ修正のデプロイ前後におけるリージョン間ネットワークコスト
2019年初めのこの時点で、私たちがデプロイし管理するシステム数は191にまで達していました。サービスのコード、機能、コンフィギュレーションは毎日変更されていて、それぞれがコストに影響を与えていました。このような状況において、これらの変更がデプロイされた時のコスト面での影響を考慮してもらうために、(FinOpsの考え方を持った)コストモデルの管理方法をもっと多くの人たちに教育する必要のあることは明らかでした。プロダクトスイートに今後も機能やプロダクトを追加するという私たちの計画の中で、コストモデルを今後も維持していくためにはこれが最も重要だ、ということも分かっていました。
イメージ 3 — 月毎の課金対象コンポーネント数の推移 (2018～2020)
まず最初に、それぞれのチームと一緒にクラウドコストの構成(コア、メモリ、ネットワーク)についてレビューすることによって、全員がその基本を理解できるようにしました。次に、プリエンプティブル(preemptible)ホスト(AWSのスポットインスタンスに相当)とそれよりも高価なインスタンスタイプとの比較や、その他のクラウドコストに関する諸々のトレードオフの評価を対象とした、具体的なセッションを行いました。これらのセッションを通じて、FinOpsへの支持や認識が各チームに広がりました。その結果として獲得したFinOpsの実践方法に対する支持や一般認識が、私たちの用意したツールとも相まって、チームがクラウド費用を削減し、あるいは最終目標と優先順位(パフォーマンス対コストなど)の最適化をより徹底的に考慮することにつながったのです。
私たちの実施したFinOpsセッションに価値のあったことを示す絶好の例が、2020年2月、チームのひとつが通常のGCP VMを使って新サービスをデプロイする際にありました。FinOps教育セッションの別ラウンドの成果として、そのチームのメンバたちから、対象となるサービスのSLAに影響を与えることなく、安価なプリエンプティブルホストに変更することが可能だ、という指摘があったのです。この変更により、サービスのコストを50パーセント近く削減することができました。このコスト削減はそのまま粗利益になりましたが、カスタマエクスペリエンスやプロダクトの機能にはまったく影響しなかったのです。
イメージ4 — プリエンプティブル容量の最適化
2020年の始めになると、当社のさまざまなシステムを最適化する上で比較的簡単に手の付けられる部分については、その大半が特定されていました。サービスを効率化する方法の発見が難しくなったことは同時に、当社のFinOpsツーリングにディメンションを追加すべき時であることを告げる大きな兆候でした。同時にそれらは、もはやクラウドプロバイダからは入手できないものであることも分かっていました。
マルチテナントSaaS企業である当社は、各カスタマが当社のコストモデルに与えている影響度や、それらをカスタマのレベルで最適化可能かどうかを理解したいと思っていました。この新たな課題が、最適化思考の第2の波を生み出しました。それはまさに、社内に生まれたFinOpsへの支持と、当社のFinOpsチームメンバからの調査によるものでした。当時すでに、特定のカスタマとAPIへのルーティング最適化に関して実装した一例があったのですが、ここでの最適化には、広範なシステム的問題というフラグは付けられていませんでした。これをアカウントレベルで見れば、一部のAPIコールに関しては、カスタマのデプロイメントのSLAや応答時間に影響することなく、コスト面での最適化が可能である、ということが明らかです。
イメージ 5 — 8月初旬のルーティング最適化により、規格外値であったアカウント効率が通常に復帰
あなたの会社にFinOpsマインドセットを作るには
FinOpsの採用を進めるには、いくつかの文化的エンジニアリングが必要です。ひとりでFinOpsを極めることもできなくはありませんが、それでは限界があります。もっと変革を起こすには、FinOpsに関心を持つ人たちを開発とDevOpsチームの両方で見つけて、彼らの学習の手助けをする必要があります。
FinOpsのアンバサダとパイオニアを見つける
起業家なら誰でも知っているように、チームはあらゆる企画において最も重要なファクタです。FinOpsチームの成功確率を最大限にしたいのであれば、次のようなメンバを人選する必要があります。
- 物事の仕組みに関心と興味がある
- 財務的なアカウンタビリティに関心があり、その重要性を理解している
- 企業の成功に(明確な)関心を持っている
- FinOpsシステムの働きを知っている
- クラウドアーキテクチャとコスト構造の機能や動作について知っている
- コスト、安定性、パフォーマンス、その他のトレードオフを考慮して、バランスの取れた決定を行う方法を知っている
- FinOpsのマインドセットを効果的に伝道し、その大義にチーム内外の人々を集結させることができる
あなたが成長し、あなたのFinOpsプラクティスが成熟するにつれて、あなたの行うFinOpsが正しければ、FinOpsアンバサダのチームは組織的に、あるいは周りのチームの関心を越えるように成長するでしょう。DevOpsと同じように、FinOpsは、新たな領土を作り出すのではなく、財務的なアカウンタビリティを皆のものにする存在なのです。プラクティスを効率的かつ永続的に拡大するには、それが唯一の方法です。
視覚化によってFinOpsの効果を高める
次に私たちは、主要なFinOpsメトリクスを表示するベーシックなダッシュボードを開発して社内に公開し、DevOpsや開発チームとミーティングで共有して、私たちの行っていることを彼らに伝えました。単に公開するだけでは不十分なのです。私たちに必要なのは、次のようなことです。
- 私たちのFinOps方法論、ツーリング、ユーザエクスペリエンスを明らかに有用なものにする — 社内MVPを獲得できる位に。
- 実施可能なものにする — すなわち、コスト構造や設計、あるいはアプリケーションパフォーマンスを改善するものとして示した情報を、私たちのチームが彼らに代わって実施可能であることを強調する。
- 意味のあるものにする — 時間経過に伴うコスト削減を明確に示し、結果へと誘導し、チームの業務全般にFinOps的考慮を含めることによって。
- ターゲットを決める — 他のKPIと同じです。何を測るか、何を目標にするのか、という設定が人々の関心事なので、私たちはFinOps KPIを作ってターゲットにしました。
当社がFinOpsを使い始めて3年になりますが、コストを削減する、あるいは運用上のディシジョンを改善するための機会は、現在でも毎月あります。それよりも重要なのは、FinOpsのレンズを通すことが、インフラストラクチャやアプリケーションの設計プロセスにおいて重要な部分を占めるようになったことです。機能開発を中心としてFinOpsを後付けするのではなく、FinOpsを事前に考慮しておくことで、よりスマートな長期的ビジネス判断を行うことが可能になりました。さらには、偶然ではなく、カスタマエクスペリエンスの向上にもつながるのです。
あなたが現在直面しているFinOpsの課題について、ぜひ聞かせてください！
著者について
Elad Amit氏は1998年からIT産業の一員となり、プロダクト管理へと移行した後、2001年にはEコマースソリューションを専門とする自身のソフトウェア開発ショップを身近な友人たちと立ち上げました。以降はR&Dチームのリーダとして、プロダクト開発のディレクタとして、アジャイル開発コンサルタントとして活動を続けています。6年以上前からは、急成長を遂げた大規模環境の中で、いくつかのアーキテクチャチームや運用チームを指導する職務に就いています。