2年半を費やしたチャットワークのScala移行、もしやり直すならどうしますか?(後編)

トレタCTOの増井雄一郎さんがチャットワークのScala化プロジェクトのお話を掘り起こすインタビューの後編です(前編はこちら:チャットワークのScala移行と大規模メッセージDB再構築、本当にできたんですね!)。ChatWork CTOの山本さんは2年半を費やしたプロジェクトを振り返り、「やっぱりScala化は必要だった」と語ります。

左から増井雄一郎氏(トレタCTO)、山本正喜氏(ChatWork 専務取締役 兼 CTO)、春日重俊氏(ChatWork 開発本部 本部長)

「2年半って長いですよね」

増井 2年半ってどういったタイムスパンで進んだんですか?

山本正喜氏(ChatWork 専務取締役 兼 CTO)

山本 2014年4月ぐらいにScala化を決断して、社内で勉強会が立ち上がりつつ、採用をかけていった感じです。2014年7月に加藤潤一(「日本Scalaユーザーズグループ」発起人のひとり)というScalaの優秀なエンジニアが入ってくれて。そこから設計をどうしよう、と始まって。しばらくは加藤と、もう1人ぐらいで設計をしていた。それが半年ぐらいあったのかな。

2015年ぐらいから実装を始めて。1年でチームメンバーも増えて、そのときは全部まるっと移そうと計画をたてて。1年走ってチームの人数も2人から6〜7人に増えて。2015年中にリリースするぞ、とやっていたんですけど。2016年1月に本番にデプロイしようかということでリリース作業をしていたとき、全部つなぎこむとサーバーコストやトラフィック的に耐えられないことが分かってきて。このあたりは前回の記事の話とも一部つながってくるんですが。

このままのアーキテクチャでは難しい。いったん仕切り直し。再スタートして、メッセージDB中心で切り替えようと判断したのが2016年1月。ミドルウェアの選定から始まってHBaseとKafkaを導入して。2016年内には絶対に出すという目標を立てて、年内ぎりぎりでなんとか出せました。

増井 スタートアップで2年半って、すごく長い時間じゃないですか。

山本 長いですね。2年半かかると分かっていたらゴーサインは出ませんでした。最初は「半年でやります」と言っていた(一同爆笑)。

「PHPはどうするんですか?」

増井 この2年半でPHP7も出たりしたじゃないですか。PHPのコードはこの先どうするんですか?

山本 少しずつ切り出してScala化していきます。ただ、かなり残っていると思うので、Scala化した方がいいところを中心に。ちょうどメッセージDBのプロジェクトのメンバーが解放されるので、彼らが動けるようになるとどんどん進んでいくと思います。少なくとも3年ぐらいは残ります。

プロダクトに近い部分はScalaへの移行が進んで、一方で管理画面とか決済まわりとか社内システムとかではPHPがかなり残っていくんじゃないか、というところもある。

増井 次に「ここをやろう」という話は?

山本 Scalaのチームが自発的に動いていて、メッセージまわりがScalaになったので、その前後をScala化を進めていこうと。ScalaからPHPを叩いている受け口とか。メッセージまわりは流量が凄く多いので、その周辺処理をScala化しようという感じです。あとは認証まわりのようにマイクロサービスとして切り出しやすいところをScala化する。公開APIのところとか。

増井 公開APIを待ってる人は多いと思うんですよね。

山本 今年、かなり強化します。メッセージまわりも耐えられるようになったので。Webフックも作れるようにしたいし、OAuthも今年やります。

「ChatBotは難しい」

増井 去年はChatBotが、それこそLINEが出したりでコンシューマに認知されるようになってきました。でも、まだうまい活用例が見えてないですよね。。

山本 ChatBotは面白いけど、実現できるユースケースが少ない。面白い答えを返すBotは作れるんだけど、ビジネスコミュニケーションで間違えないようにするのが難しい。

増井 うちも予約をチャットできるツールを試作はしたんですが、あまり使いやすくならなくて。

山本 言語解析は難しいですね。

増井 でもエンジニアはデプロイとかにChatBotを使ってますよね。

山本 注文を出す側がフォーマットを理解してくれるなら便利です。

増井 エンジニアはそういうふうに考えますよね。

山本 普通にやるには自然言語の理解が必要になっちゃうので。でも、チャットワークでもBotは作れるようにしていきたいと思ってます。

AWSからKubernetesで構築した自社インフラに徐々に移行

増井 PHPとScalaが両方載っていると、複雑性が増して大変になりませんか? ロギングとか。

山本 既存システムとはアーキテクチャが変わってきています。Scalaで新しく作ったのはメッセージDBだけなんですけど、一緒に開発したサーバーの運用まわりでは社内PaaSのようなものができあがりつつあるので、そこに既存のPHP部分も載せていきます。今まではAmazon EC2にサーバーをそのまま置いてたのを、Kubernetesを導入してDockerコンテナのクラスタとして運用する。PHPの部分もコンテナ化して詰め込んで。

増井 Scala化と同時に今風のコンポーネントやオートスケーリングの基盤も作ったんですね。

山本 新しい基盤を共通に使うようにしていきます。

増井 増井雄一郎氏(トレタCTO)

増井 ECS(Amazon EC2 Container Service)は候補にならなかったんですか?

山本 選定の結果、Kubernetes一択でした。APIがこなれていた。

春日 それにECS単体では運用できず、AWS CloudFormationのような他のツールを組み合わせる必要があります。そこで「秘伝のタレ」化していく懸念があった。

Kubernetesの場合は周辺ツールを含めてOSS(オープンソースソフトウェア)化するムーブメントがあります。例えばKubernetesをAWSに浮かべるためのkube-awsというOSSがあって、そのコミッタをうちの九岡佑介がやっていて。

増井 kube-awsは初めて知りました。コミッタがいるのは強いですね。

山本 自分たちの運用に合わせて世界中のエンジニアが一緒に作ってくれてます(笑)。

増井 大きな事例がないとOSS側も開発が進まないですからね。

春日 トラフィックも多いので、サーバーのコストを考えるとどうするべきか。そこでインフラにはある程度の技術投資をするべきだと決断しました。

山本 それまでは、インフラはできるだけマネージドサービスに載せる方針だったんですが、サービスのボリュームが想定する一線を越えると、とたんにコストパフォーマンスが悪くなったりします。

増井 ありますね。実はこのキーの桁数がこれだけしかなかったとか。

山本 例えばいまメッセージが18億件あるんですけど、それだけ扱うことをマネージドサービスは想定していなくて。自分たちでやらざるを得なかった。

Scala宣言したことで人材を採用できた

春日重俊氏(ChatWork 開発本部 本部長)

増井 2年半前は、PHPのチームしかいなかったんですよね。開発組織はどれぐらいの規模ですか?

山本 2年半前は会社全体で12〜13名かな。

春日 今は37〜38人です。

増井 3倍ぐらいに増えてるんですね。採用は苦労しましたか?

山本 Scala開発者の採用は最初は苦労しましたが、期間全体で見ると実はそこまで困ってなくて。「Scala化するぞ」という宣言をしたこと認知があがりましたし、Scalaコミュニティで有名なメンバーがいるので知り合い経由で参加してくれたり。いい感じで人が入ってくれました。

増井 もし2年半前に戻ってやり直せるとしたら、どこを変えますか?

山本 最初の1回目の試行のところですね。2015年の1年間でやったことは、アーキテクチャの筋は悪くなかったんだけど、完成したところでパフォーマンスやサーバーコストの観点でゴーサインを出せないと分かった。もっと途中の段階で判断できるように進められたらよかったですね。

アジャイル手法だけだと終わりを見失う

増井 一番難しかった部分はどこですか?

山本 ここまでの大規模プロジェクトをそれまでやったことがなく、アジャイルなやり方で動いていて終わりが見えない、着地点が見えない時期が長く続いたことですね。

反省としては、ウォーターフォール的にアジャイルをすればよかった。フェーズを切って、階段状にマイルストーンを決めて、その中でアジャイルで進める。そうしないと、いつまでも桃源郷を求めちゃうんですよ。それで終わりが見えず、登る山の高さが見えない。

増井 アジャイルは、短いイテレーション(反復型開発の区切りになる期間)の中で足下を見ることが多いじゃないですか。それで明日を見失うみたいな話に。

山本 大規模プロジェクトは難しい。設計を間違えると果てしなく遠くに到着してしまう。マネジメントの難易度が跳ね上がります。全然違うなと。

増井 スタートアップにはゼロから1にする、小規模中規模の開発が得意な人が集まる傾向がありますからね。PM(プロジェクトマネージャ)も増えましたか?

山本 春日が入ってくれたのが大きい。前職はリクルートで大規模システムを担当していて。1年前の仕切り直しのタイミングで入社して、すぐに鉄火場に投入されて(笑)。

増井 スタートアップが成長して、進め方を切り替えるタイミング、みんな悩むんですね。

山本 求められるスキルが突然変わるタイミングがあります。大規模開発だと、少しずつ学んでいく、リーンなやり方ができない。組織や経営の問題も同じですけどね。

増井 CTOとしての役割はこの2年半で変わりましたか?

山本 前はアーキテクチャもみてプロダクト全般を見て、開発もしてと全部をコントロールしていた。今は、ScalaだったりHBaseだったり、自分がやったことがないものをどうマネジメントするか。自分が勉強して挑戦するんじゃなくて、できる人を連れてきて、その人を通してプロジェクトを見ていくマネジメントが必要になる。人を通して組織を見ていくところで、レイヤーが一つ上がった感があります。

技術的負債の解消は改善型かビッグバン型か

増井 2年半の間にPHPのコードも増えているんですか?

山本 はい。PHPを全く触らない訳にはいかないし、PHPのメンバーの方が多い。リファクタリングをしたり、機能追加をしたりしています。

増井 PHPのチームはしばらくは残る形ですか。最終的にはみんなScalaのチームになるのかと思っていました。

山本 併存します。Scalaを書ける人は書くし、Scalaのコードが増えてくれば少しずつ転換していくと思います。当初は「全部切り替えるぞ」という言い方をしていたんですけどね。そう言った方がみんな勉強すると思って(笑)。

増井 そのへんのノウハウを知りたい人は多いと思います。技術的負債がたまりすぎたとき、一つのやり方は、リファクタリングしながら少しずつテストを増やして小さな単位に分けて書き換えていく。もう一つはビッグバン的にどんと書き換える。どちらにするか、みんな判断に困ると思うんです。そこで判断に気をつける点などありますか。

山本 我々がすごくうまくいったかというと、そうでもありません。他社の事例は参考にさせていただいたけど、ビッグバンでうまくいった会社もあれば、大失敗した会社もある。プロダクトの規模やステージによって違います。

基本的な考え方としては、どこまでの期間を許容できるか、経営的なデッドラインを持っておく。そこを越えるかどうかの判断は経営を巻き込んで議論することをきっちりやった方がいい。

僕らの場合は「PHP資産の延長には未来はない、やるしかない」とメンバーも必死になっていました。ただ冷静な目線で損切りのラインを決めておかないと。

増井 僕らは撤退ラインといってます。そこまでにできなければ、やめだと。

山本 要するに経営です。リソース配分で、どこまでコストとして張りますか、という話なので。

紆余曲折はありましたが、結果としてどう思っているかというと、Scala化の判断は良かったと思っています。PHPのコードを改善するインプルーブ型でいこうよ、となっていたら、例えばHBaseやKafkaを触れるメンバーを採用できていたかどうかは怪しい。組織として技術的なジャンプが必要な局面で、それを越えられなかったかもしれない。しばらくはサービスとして成長できたかもしれないけれど、途中でシステムが負荷に耐えきれず大爆発していたかもと。

増井 最初の段階で「Scalaでいく」と決めて器を作ったから、人材という中身が器に入ってきたんですね。

山本 何も言わずに実行するやり方もあります。宣言すると怖いじゃないですか。そこで勇気は必要だったんですが、宣言したことで注目を集めて、人が集まって実態が伴ってきた。そういうやり方もあるかなと。

春日 前回の取材を受けたとき、いろいろな話を掘り起こしていただいて。この記事が公開されるなら我々も後には引けないと腹をくくった瞬間でした。

増井 2年半は辛いですよね。

山本 結構、いや、だいぶ辛かったですね。

増井 お疲れ様でした!