2023/06/22(木), 23(金) の2日間で開催された AWS Dev Day 2023 Tokyo のセッション視聴レポートです。
Chatwork さんのセッション、SA-3-2「成長を続ける SaaS の AWS コスト管理において開発者としてできること」について感想を書きます。
セッション内容
セッション概要 jpdevday.awsevents.com
感想
私なりの解釈や印象を中心に述べようと思います。全般的に大変有意義なセッションでした。
トーク内容の紹介はわざわざブログでやる価値が薄いと思いますので、感想述べる上で必要な部分以外は省略します。 ぜひ上述のリンク先から、スライドを直接ご確認ください。
大まかな話の筋はこんな感じでした。
- "ユニットメトリクス" の導入によって、事業チームと経営陣が同じ認識で会話できる「数字」を手にした
- 組織構造の発展・変遷と、AWS リソースのコスト管理の在り方の変化を述べている
- チームが増えていくに従って、プロダクト単位での "自律的な" コスト管理が難しくなった。それに対して Chatwork 社はどうアプローチしてきたか？
私が特に良かったと思うのは冒頭の「ユニットメトリクス」のくだりです。まずここについて触れます。
ユニットメトリクス
スライド中でも紹介されていますが、「ユニットメトリクス」の出典として AWS ブログが紹介されています。以下の記事です。
(引用: AWS Blog - "What is a unit metric?" より)
Chatwork 社ではユニットメトリクスを以下のように定義し、運用されているようです。
(AWS コスト月額) / MAU = 1MAU あたりのAWSコスト
事業会社におけるコスト管理の在り方として大変参考になる考え方だと思います。顧客当たりのサービス提供コストを考えるというのは SaaS 事業の採算管理として非常に妥当だと思いますし、このメトリクスが経営陣との会話ツールとしても使えるというのが素晴らしいですね。ユニットメトリクスがあることで社内の異なる利害関係者間を集めた際の共通プロトコルになる、と。
アクションに繋がりやすいメトリクスであることも非常に良いポイントかと思いました。実際の運用ではこのメトリクスだけを見て施策を決定するわけではなく、ユーザー数やアクティブユーザーの割合など他の指標も突き合わせて現状分析した上で対応方針を検討をされるはずだと思いますが、各関係者が最初に見るものとしてユニットメトリクスは非常に便利だと思います。
出典元の AWS ブログ "What is a unit metric?" についても少し触れてみようと思います。超意訳に基づくコメントですので正確性は保証しかねます。あしからず。
当該記事では "Demand driver" という用語が登場します。本文や単語のニュアンスから察するに、要はなんらかのサービスに対する「需要」を持つ登場人物を指す用語と思われます。平たく言えば「利用者」ということになりそうです。
”Demand driver" を分母とし、分子に「消費量」あるいは「支出量」を当てはめることでユーザー当たりの提供コストに相当する KPI になるよと言っています。
で、財務・会計のドメインだとこのへんの話は「限界費用 (marginal cost)」と呼ばれる概念と関連があるそうです。 そこで、限界費用の定義を wikipedia にあたってみました。
「単位あたりのコスト」という視点はありつつもこちらの定義は微分関数なので、このブログが言っている「ユニットメトリクス」の定義とは少々異なるようです。今回の発表内容に当てはめるなら「アクティブユーザー数でコストを微分する関数」あるいは「ある観測期間（例えば月次）において、利用料の変化分を同期間のアクティブユーザー数の変化分で割った数字」が限界費用の定義に沿う感じになるでしょう。こっちの指標が好ましくない増加傾向を見せているなら、それは現状構成が提供コストの観点でスケーラブルでない可能性を示唆していると言えます。これはこれで、サービス運営の指標として有用だと思います。
まあ、実際の事業運営においてそういう微分式を意識することは少ないでしょうけど、実際これに近い考え方は暗黙的にやってるんじゃないかなとも思いました。微分って要は「傾き」なので、過去の定点観測の結果と見比べて「１年前よりペース悪化してるね」みたいな会話をしてるならその見方は時間軸に対する微分的な考え方だよねと（適当）。「MAU が1万人規模のときは緩やかだったのに、10万人超えたくらいの規模からは（大きく構成を変えてないのに）利用料激増しちゃってるね〜」みたいな会話をしてたら、それは限界費用の定義に沿うような微分の考え方してるんじゃないかなって思います（これも適当）。
組織拡大に伴う、コスト管理の在り方の変遷
次に、組織拡大とコスト管理の在り方の変遷について述べたセクションについて。
単独のチーム → 職能分割 → サービスコンポーネントでの分割
という変遷を辿られています。
AWS リソースの面倒を見るチームが利用料についても把握する、という運用をしていたものの、マイクロサービス化したことで各サービスの単位に踏み込んで詳しく把握することは難しくなった、という課題が共有されていました。これ自体は、まあ割とあるあるな話のように思います。
ここで Chatwork さんは、解決の方向性として「AWS 担当チームが全部把握できるように仕組みを作ろう」というよりはむしろ「各チームの開発者が自発的・自律的にコスト意識を持てるようにしよう！」という発想からスタートされてるようにお見受けします。この考え方は本当に真っ当と言いますか。とてもお手本になる考え方だと思いました。
各チームがオーナーシップを持ってやっていこう、という発想が基本なんですよね。「中央 or 横断」なチームがいて、そのチームが全体としてのコスト管理を握っていく...というのも引き続き必要なことだと思いますが、開発組織のスケーラビリティの観点からするとコスト管理を AWS 担当チームにすべて預けるのはあまり好ましくない印象があります（そのあたりはスライド中でも触れられています）。各チームの開発者 "も" 自律的にやっていけるようにしよう、というのはとても良い方針だなぁと思いました。付け忘れを防止する施策もセットでかなりいいですね。
少し興味があるのは、Chatwork さんでは会社の採算管理（あるいは原価計算）をどういった単位で行われているかという点です。AWS はじめとするサービスの利用料であれば大きなサービスごとの括りである程度は見られるし経営会議で上がるレベル感にフィットする数字は十分出せるだろうと思うんですが、実際にはサービス or 部署を横断して使っているツールやインフラリソースなんかもあったりするわけでグレーゾーンは出ます。経理的な視点だとこのへんのサービス利用料に人件費等をひっくるめて事業単位でのお金の出入りを計算しているはずだと思いますが、そのへんの領域と今回紹介された取り組みの間に絡みがあるなら伺ってみたいなと思いました。（といっても、これは Dev Day の趣旨からは少々ずれてしまいますね）
もう1点興味深かったのは terraform Infracost です。（私がまったく当該機能を使ったことがないので、的外れコメントになるかもしれません）
infracost は tf ファイルの定義を読み取ってそこからクラウドリソースの利用料を推定するツールです。ネットワーク I/O や S3/DDB のストレージ使用量など IaC テンプレートの定義から直接読み取れないコストをこのツールで試算できるのだろうか？というのが気になったんですが、Usage ファイルというのを定義してあげればトラフィック量などの推定コストを反映した見積もりを出してくれるようですね。
Usage-based resources | Infracost
Chatwork さんではハイトラフィックなサービスを運用されているはずなので、特にトラフィックのコストは馬鹿にならないはずだと思っていました。Infracost がこのあたりもカバーしているらしいと知れたのは大変有益でした。
まとめ
Chatwork さん、面白いセッションありがとうございました。
月並ですけど、まだまだ知らないことがたくさんあるなぁと思いました。自分ひとりのアンテナでは限界がありますが、Dev Day のようなイベントがあることで貴重な他社事例を見聞きすることができますし、大変良い刺激が得られたと思います。
余談）セッション一覧のまとめ記事書いてます。よかったら併せてご覧ください
