コスト意識は“現場レベル”での浸透が必要　システム肥大化で上がったコストをどう削減するか

“コストの壁”

春日重俊氏（以下、春日氏）：土橋さんのインタビュー動画でした。続いて、コストの壁といったところです。土橋さんと一緒にやったFALCONという分散システム導入するというところで、ようやくサービスを安定的に運用できるという、僕の心理的なところの1つのプレッシャーが解かれたところがありました。

この後に待っていたのが、その後のビジネスをよりGrowthさせてかないといけないので、やはりサービスを安定運用させるためには、コストがどんどん上がってしまっていたような状況でした。

ヘルシーにきっちり儲かるビジネスにしないといけないところがあり、そのコストの壁といったところで、どういうふうにChatworkがいろんな施策を通じて、システムをさらにバージョンアップさせていったのかについて、これから話したいと思っています。

先ほどの分散システムを導入したといったときのアーキテクチャです。、スライドにあるように、どんどん複雑化してるようなところになってきています。

システムが肥大化してしまった結果、何が起こったのかというと、原価率が50パーセント以上を超えてしまいました。要は、売っても売ってもなかなか利益にならない、みたいな。これは経営的には非常にまずいというところで、その当時は役員から常々言われて。「いやいや、それはわかるけど、でもサービス落ちたら元も子もないでしょう」みたいな心理でした。

とはいえ「言うことはごもっともだな」と思っていて。とはいえ、やはりサービスの構成を見直せばもっとヘルシーになるかなと思っていました。一定のリソースを、サービスの減価率の改善に関して経営的にも合意をしてもらい、いろいろな施策を通じて減価率を改善するところをやり切った結果、直近でいうと、ピーク時から約4分の1ほど減価率までダウンできました。

“コストの壁”で行った2つの施策

どんな施策をやってきたかを、すべてではありませんが、大きなところをかいつまんで説明したいと思っています。

1つ目が検索エンジンです。「え、検索エンジンって、ちょっと前にCloud Searchリプレイスしたやん」っと思った方もいるかと思いますが、アーキテクチャはやはり数年単位に見直す必要がある。Googleとかも提唱している考え方かと思いますが、導入して、コストがどんどんかかるようであれば、数年単位に見直して、その時々に応じた最適なものに変える必要があり、そういういい例かなと思っています。

その当時のCloud Searchは、やはりRIがなかったり、コスト効率があまりよくないような構成になっていました。そういったところがあったので、Elastic Searchサービスに乗り換えるような策をやりました。

その結果、サーバーの台数が10分の1に削減して、ランニングコストも6分の1に削減できるといった、大きな効果を得られました。

2つ目、spotインスタンスの活用です。先ほど冒頭で説明したように、弊社ではアプリケーションの実行基盤としてKubernetesを採用しています。Kubernetesをフル活用することによって実現できた施策になっています。

日中帯にEC2をすごく立ち上げたりするので、こちらを保護することによって、だいたい70パーセントぐらいコストを削減的したところが大きいと思っています。

あとはオートスケールです。やってるようでなかなかやりきれないところのサービスのトラフィックに合わせて伸び縮みするような。こういったところは、サービスを長く運用していく上には意外に必要な概念じゃないかと思ってます。こちらもざっくりな試算でいうと、50パーセント以上は削減できているのではと思っています。

この後、コストの壁のエキスパートでも出てもらいますが、PHP7対応があります。FALCONという分散システムを導入しましたが、技術負債すべてを一気に変えるのはなかなか難しいなと目に見えたとき、じゃあPHPも一定の長い年度を付き合っていかなければいけないといったときに、どういったかたちで付き合っていくべきかを内部ディスカッションしました。

そのときにPHP7にするか、HHVMにするか非常に悩みました。その当時、ある会社さんにお邪魔して、僕たちの感覚としてはHHVMも有力候補の1つじゃないかと思っていましたが、そのエキスパートである新原さんと一緒に議論した結果、PHP7が弊社としては現実的な回答だろうといったところで、やり切った結果、いろいろなものが半減する素晴らしい効果になりました。

“コストの壁”の課題からの学び

このときの学びです。やはりコスト意識は現場レベルまで浸透させて、やる意義を理解してもらっているかが重要だと思っています。あと採択した技術は数年単位で見直して、継続するかの判断は必要じゃないかなと思っています。あと3つ目は、自社の体制を鑑みた上での運用コストは非常に重要じゃないかなと考えています。

エキスパート新原さんのインタビュー

この当時に非常にお世話になり、この当時以外もいろいろお世話になっていますが、弊社の長年の技術パートナーである新原さんについて、当時支援してもらったところについてインタビューがあるので見てください。

新原雅司氏（以下、新原）：1×1の新原といいます。Chatworkさんとは、もう何年も一緒にしていますが、私のほうは主にPHPアプリケーションの技術開発とか、技術サポートのお手伝いをしています。

当時は、もうPHP7はリリースされた後ではありましたが、まだ世の中としてもPHP5のコードがたくさん動いている状況でした。その後、次にPHP7という次のバージョンに行くのか、もう1つの選択肢として、HHVMという、Facebookが開発ているオープンソースの実行エンジンがありますが、そのどちらに移行するかを検討していて、その指針となるような調査をしてほしいということで声をかけてもらいました。

争点となるのは、パフォーマンスのことがあると思います。というのは、PHP5からHHVMに移るパターンの大きな狙いは、パフォーマンスの向上でした。

実際にPHP5のChatworkのアプリケーション移行をしてもパフォーマンスはもちろん上がりますが、でもPHP7もパフォーマンスが上がるので。パフォーマンス検証してみると、両者そんなに違いがありませんでした。そのため、パフォーマンスに関してはどちらを選んでもよさそうだと。

ただPHP7は、PHP5の正常進化形というか。PHPコミュニティの人たちも当然PHP7へ移行していくので、フレームワークやライブラリ、あとは拡張などの周辺のエコシステムは、全部PHP7に移っていくこととはもう明らかでした。

一方、HHVMはFacebookが作っている実行エンジンということもあり、今後どれだけサポートされるかがちょっとわからない状況でした。HHVMにはNew Relicの拡張がありませんでした。パフォーマンスモニタのサービスをChatworkさんではずっと使っていたので、これがHHVMに対応してないということで難しいかな、というのはあったと思います。

結果的に、HHVMはその後PHPのサポートを完全に切ってしまったので、HHVMに移っていたら全部をHackに書き換えるか、一部をHackに書き換えたものをPHPに戻して、PHP7に移るかしなくてはいけなかったので、そういった意味でもあの検討は割と大きかったかもしれないです。

Chatworkさんは、技術を突き詰めるというか、技術的にしっかりしたものをちゃんとやりつつ、ビジネスとしてもちゃんとやっていく、プロダクトとしてもちゃんと伸ばしていくバランスをうまくちゃんと取っている会社だとはすごく感じます。すばらしい魅力だと思います。

（次回につづく）