コスト削減に全員が楽しく参加するための「モブコスト分析」　実践する上で大事な3つのこと

経営陣が指揮を取る、「削減している」と思っているとうまくいく

丹哲郎氏：ということで、今回の後半に入っていきます。早口でしゃべってしまったので早めに後半に入っちゃいました。ケモノ道というのは非常に大事になってきます。これはもう「全員でやりましょう」という話になります。

どうすれば全員が参加できるの？　という話でいうと、僕が170社ぐらい見ている中でうまくいくケースは、CTOやVPoEといった、高いレイヤーの技術責任者の人が、自分のタスクだと認識して、経営陣として指揮をとっているケースはやはりうまくいくなと思っています。

そしてもう1個は、最適化するということじゃなくて、「削減しているぞ」と思うと、もっと良くできるというところがあります。

全員が楽しく参加するための「モブコスト分析」

ここからが具体的なプラクティスの話に入っていくのですが、やはり全員が楽しく参加できないとお祭りじゃないと思っているので、僕らはモブコスト分析を社内でやっているということを紹介したいです。

みんなでBillingやレポートなどを眺めながら「DBってめちゃくちゃ大きいけど小さくできないの？」ということを話すとか、「ここの転送量ってなんで多いの？」ということを話すとか、「このNATを通っているトラフィックって何？」みたいなことを話すようなことを、社内みんなでワイワイやっています。

（スライドを示して）こんな写真を見ても何もわからないかもしれないですが、みんなで画面を見ながらワイワイ話しています。

「新しいお客さんのコスト診断をやってください」と依頼されたら、僕らはこれを最初にやるんですね。途中まで誰かが分析してレポートを持ってきて、それに対してレビューをするのだともう遅くて、最初にこのBillingを全部バーッと見て、どこが安くできそうかなという当たりを全員で話し合って、「ここができそうだね」「あそこができそうだね」というブレストを社内でやっています。これはすごく楽しいし、みなさんの会社でも絶対にできると思うので、やってみてほしいなと思っています。

モブコスト分析で大事なこと1　「こうすればいいよね」を全員が考える

これをやる上で大事なことは、まず全員が「こうすればいいよね」ということを考えることです。このあと実例で話したいと思うのですが、例えば「通信料が多いよね」という話があった時に、「じゃあ通信料を削減しましょう」と当たりを作るのは、実は意外とフロントエンドエンジニアかもしれないんですよね。

「この画像の読み込みをもう少し遅延させたら、その分アセットの読み込みが減るからコストが減るかもね」ということをフロントエンドの人が言うかもしれない。逆に、CSの人が「ここってこういうユースケースの人たちが多いから、ということはこういうトラフィックが多いよね」みたいな知を持ち寄ってくれるかもしれない。

インフラエンジニアの観点からすると、「こういうトラフィックが多いけど、ここってなんとかならない？」という会話があったりするかもしれないし、バックエンドエンジニアの人が「あ、やべ。俺ここちょっと最適化できていない処理があるわ。でもこれはこんなコストが跳ねていたんだ。ごめん」みたいなことがパッと思い浮かぶかもしれない。

なので、みなさんの持っている知を持ち寄って、みんなのドメインから見えることをコストに紐づけて、その場でBillingを見ながらいったん「うんうん」と考えるというのを全員がやるのがめちゃくちゃ大事だなというのが1個。

モブコスト分析で大事なこと2　ドメインとアーキテクチャをつなぐ

あとはやはりドメインが大事だなと思っていて。これは本当に技術的な話だけじゃなくて、先ほど言ったとおり、CSの人から見たらこういうユースケースがあるとはわかっているとか、バックエンドの人から見ると「ここってこういうデータ構造になっているよね」ということがわかるとか。あとはサービス全体で、「このサービスって、トラフィックはどこにめちゃくちゃかかるの？」みたいなところは、そのサービスの特性に普通に依存します。

なので事業ドメイン的な意味でのドメインというのもあるし、それぞれの目から見える職責というか、職域という意味でのドメインもあるります。それをアーキテクチャやコスト削減という観点で見ると、「いや、こういう解釈になるよね」ということを繋げるのが非常に大事です。

モブコスト分析で大事なこと3　Elephant in The Roomをちゃんと見る

あとは、内製する上で一番ぜひみなさんにやってほしいなと思うもう1個は、Elephant in The Roomをちゃんと見るということですね。「コスト削減をやりましょう」と言うと、まずは「Cloudwatchを見直そう」とか「ここの通信を減らしましょう」ということをやることになりがちです。

これは本当にいいことではあるのですが、結局「大きいAuroraのインスタンスがあるのってどうするの？」みたいな話でいうと、そういうのはみんなあまりやらないというか、「これはもう本当にしょうがないよな」と（なってしまう）。「でもそれって本当にしょうがないって言えるの？」ということは、あまりやりたがらない。

大きすぎると逆に「これって動かせないんじゃないか」と思っちゃうのですが、上位5パーセントぐらいのクエリがこのインスタンスのパフォーマンスに影響を与えていたとしたら、そこをチューニングするだけで「意外と半分にできたじゃん」ということもぜんぜんあるので。大きいものから逃げずにちゃんと消滅していこうとできているところは、けっこううまくいったようなケースが多いかなと思っています。

（次回に続く）