苦労して育てたPHPを捨てるメリットは? チャットワークに聞く(後編)

増井さんが「今、気になる人」に直撃する連載。前編では、PHPの独自フレームワークで開発したチャットワークをScalaで刷新すると宣言したChatWorkの山本正喜CTOに、プロジェクトの進捗と、このプロジェクトがもたらした影響について聞きました。

PHPからScalaに乗り換えたチャットワークさん、その後どうですか?(前編)
IT芸人の異名を持つ、トレタの増井雄一郎さんが「今、気になる人」に直撃する連載。今回は、ビジネス向...

後編では、チャットワークの未来像や、技術的負債を抱えないための方法論などについて、話を進めていきます。

苦労して育て上げたPHPを捨てるメリットとは?

ChatWorkの山本正喜さんとトレタの増井雄一郎さん

増井:現行のシステムはまだPHPで動いてるんですよね?

山本:そうです。

増井:10万4000社が使っている大規模サービスなのに、特に大きな問題はないんですか?

山本:今は安定していますから問題はありません。でも3年ぐらい前までは、大きな障害を起こすことが度々あったので、正直、大丈夫とは言い切れない部分がありました。増井さんならよくご存じでしょうが、大規模なシステムでPHPを使う時には、気をつけるべきトラップがいくつもあるんですよ。

増井:そうですね。

山本:セッションまわりとか、ネットワークまわりとか、DBコネクションまわりとか……。そもそも「最初から大丈夫だった」というより、問題が起きるたびにPHPをソースレベルで読める人に入ってもらい、障害を1つひとつ解消しながら「大丈夫な状態にした」というのが正しいかもしれません。ここ2年で障害はほぼなくなりました。

増井:そこまで苦労して育てたPHPを捨ててまで、Scalaに移行するメリットってどこにあるんですか?

山本:安定化までは何とかやり切りましたが、将来性を考えると、どうしても刷新が必要な状況でした。改良に次ぐ改良で、ソースコードが密結合になっているため、テスト時のカバレッジの悪さとか、基幹部分に手を入れた後の影響範囲が読めない感じとか……。この規模のトラフィックになってくると、ちょっとつまずくとサーバーが全オチしてしまう危険性をはらんでるので、いずれは手をつけなければならない課題だという認識をずっと持っていたんです。

増井:今はよくても、先々を考えると問題が多いと。

山本:技術的負債がたまったシステムを「終盤のジェンガ」なんて言いますけど、チャットワークもある意味で、その表現に近い状況だったといえるかもしれません。ある程度までは、リファクタリングを重ねて続けることはできますし、今までもそうやってきました。でも根本的なところで限界があるという意味では、今の延長線上に解決策はないと思っています。

PHPコード延命は「現実解だった」

増井:大規模な障害が起こらなくなったということは、2年前よりソースコードがきれいなったということですか?

山本:そうですね。障害が起きるたびに問題となる箇所を改修していき、周辺のリファクタリングを継続して行っていました。そのことで結果的にPHPのコード寿命は伸びましたが、それはそれで現実解だったという気がします。

増井:メッセージDB部分は、どうしてもPHPじゃ書きようがありません。どうしたって、Non blocking IOが得意なGoやNode.js、Scalaなどで書かざるをえない。メッセージDBって関数型言語の特性がすごく生きる部分でもありますよね。

山本:そうですね。単純な処理なんだけれど、すごく大量のデータを同時並行で捌かなければいけない時に特に有効だと思います。このあたりをPHPで開発するのは苦しいですね。

増井:もし僕が山本さんの立場なら、メッセージング以外の部分は、PHPのままでいいという判断をすると思いますがどうでしょう?

山本:メッセージング以外の部分でも高負荷だったり大規模なデータ量を扱う部分はたくさんあるので、なかなかそういうわけにはいかなさそうです。ただ、僕もあまり高パフォーマンスが求められないシステムはPHPのままでもいい部分はあると思います。でも、継続してシステムを維持していく上で技術的負債は常にたまっていくものなので、開発リソースとの兼ね合いはありますが大部分はScala化していく方が今後楽になってくると思います。

増井:Scala化するにあたって、テストコードはかなりきちんと書くんですか?

山本:そうですね。かなりしっかりと書いています。ユニットテストの整備などは当然なんですが、Scalaが静的型付け言語であることも品質の高さにつながっていますね。僕はどちらかというと「ゼロイチ」タイプのエンジニアで、プロトタイプ的に壊しながらガンガン書くようなスタイルばかりやってきたんですが、いま実装されているScalaのソースコードを見ていると、その美しさに驚くことが多いです。

増井:最終形が見えてるからこそ、こまかくきれいに書けるというのもありますしね。

山本:そうですね。すでにサービス的にはある程度仕様が固まっているので、それなりに重厚につくってもペイするのかなと思います。そういう意味で、ある程度規模が大きくなってきたシステムのセカンド・ランゲージとしてのScalaは悪くない選択なんじゃないかなと思っています。PHPはカジュアルに書いても動きます。それはそれで素晴らしい価値です。でもシステムが大規模になると、どんどん苦しくなっていくんですよ。

ChatWorkの山本正喜さん

増井:システムが大規模になって1番キツかったところってどこでした? やはり密結合による不具合でしょうか?

山本:イレギュラーなユーザー操作や、データ状態をきっかけにサーバーが突然落ちるところですね。それ自体はそこまで重たい処理じゃなかったとしても、高いユーザートラフィックがあるとすぐに処理が詰まってしまう。パフォーマンスチューニングを必死にやって、重たい処理は全部キューに入れてバックグラウンドで処理させていくということをひたすらやり続け、やっと安定稼働できるようになりました。

増井:そこは地道にやるしかないですよね。ちなみに、Scala以外にも検討された言語はあるんですか?

山本:言語でいうとPythonとRuby、モダンなフレームワークのPHPで書き直すという案もありました。現場のエンジニアに「好きなものを選んでいいよ」と言ったら、合宿でのコンペの末、Scalaになりました。

増井:みなさんチャレンジングですね(笑)

山本:そうかもしれません(笑)。僕も一度先入観を持たずゼロベースで考えてみた方がいいかなと。正直、LL(軽量プログラミング言語)を別のLLで書き換えるっていうのは、あまり筋がいいとは思っていなかったのですけれど。

増井:だったらPHPでいいじゃないかって気はしますよね。

山本:なので、もしもあの時、Scalaじゃないものを選べと言われたら、僕はPHPを推していたと思います。でも、現場のエンジニアたちに「もしゼロから作り直すとしたらどうする?」と問いかけ、議論の末に出した結論がScalaだったんです。

増井:エンジニアにも選んだ責任が伴いますね。

山本:そうですね。ぶっちゃけ、ヒヤヒヤしながら見ていたというのも確かです。でも、新しいことに挑戦することはいいことだし、選んだ理由にも合理性がありましたから、今にして思えばあの選択で良かったと思っています。

マイクロサービスは「痛みをこらえて」採用するアーキテクチャ

増井:先ほど「チャットワークはマイクロサービスに近づいている感じ」と言ってましたよね。

山本:ええ。密結合を解消するために切り離そうとしているので、今後はマイクロサービス的なアーキテクチャになっていくと思います。

増井:そうなると、パフォーマンスを出したり、テストが難しくなったりしませんか?

山本:確かにそういう面があります。

トレタの増井雄一郎さん

増井:僕は、フレームワークやテストツール、周辺ツールがちゃんと整わないと、マイクロサービス化には踏み込めないなと感じているんですが、どう思われますか?

山本:安易に取り入れたら絶対カオスになると思いますよ。だからよっぽどのイシューがなければやるべきじゃないかと。「巨大なモノリシック(一枚岩)なサービスで、チームのデプロイサイクルが合わなくなってきている」とか「ひとつこけたら全部こける」みたいな、シャレにならない損害が起きる可能性があるといったような、大きなイシューを克服するために「痛みをこらえて」採用するアーキテクチャだと思っています。小さければモノリシックのほうが、絶対に見通しがいいですしパフォーマンスも出せますからね。

増井:同感です。

山本:トレタさんはどうなんですか?

増井:Core APIはモノリシックですけれど、それ以外のサービスを分けたりはしています。「マイクロ」まではいかないですが、「ミドル」サイズぐらいでしょうか。ただ、Ruby on Railsを使っているのですが、あまりマイクロサービスに向いているとは言えないですね。

山本:なるほど。結局、システムのアーキテクチャって、チームのアーキテクチャに似てくるという法則があるじゃないですか。マイクロサービスのアーキテクチャは、サーバーサイドで何チームもできてきて、それぞれのデプロイサイクルが違うとか、ビジネス要件が違ってきたという時に生きてくるものなんですよね。

増井:僕もそう思います。コアはなるべく触りたくないですからね。

山本:いちいち、社内のご意見番みたいな人に、アーキテクチャレビューなんてしていられないじゃないですか。チームサイズが小さいところで、マイクロサービスを採用する必要はあんまりないんじゃないかなと思います。

増井:マイクロサービスに向いたフレームワークとかツールセットが充実してくれば、ありだと思いますが、文言をひとつ変えるのに、本体のデプロイが必要ですっていうのはなかなか辛いものがありますからね。

山本:部分的にデプロイできるというのはいいことです。でも、それが運用まわりまでこなれていかないと難しいと思います。そこまでいくにはまだ数年かかるのではないでしょうか。

Scala化で開発側とビジネス側の軋轢は?

増井:最後に聞きたいのは、Scalaを採用するに当たって、開発側とビジネス側との軋轢はなかったのかということなんですが、その点はどうでしたか?

山本:僕は役員でもあるので「技術的負債って何だ」とか「それだけのコストかける意味があるのか」といった質問は、あちこちから受けました。でも結局のところ、システムに何か手を加えた時、その影響範囲が読めないという状況を変えない限り、いま発生しているシステム障害やプロジェクトの大幅な遅延の根本原因は、解消できないと説明し、理解してもらいました。

増井:そうだったんですね。

山本:ただ、当初の見込みより時間がかかってしまっていて、移行がまだ完了しているわけではないので、まだまだScala化で成功したと大きく言える状況ではありません。最終的にペイできるよう、やりきるしかないかなと思っています。実は増井さんにお伝えした話は、Scala化の目処がついたらブログに書こうと思っていたんですが……。

増井:すいません、その前に来ちゃって(笑)

山本:いえいえ。実際「あれからどうなったの?」ってよく聞かれますので、お話できる機会を作っていただき、ありがとうございました。なるべく早くScala化を実現して、巨大システム運用するノウハウを含めて公開できるよう頑張りたいと思います。まずは年内を目処に、やりきるつもりです。

増井:でも、いざ切り替えるとなるとドキドキですね。考えるだけで胃が痛くなりそう。

山本:これだけ大きなシステムだと、走りながらシステムを切り替えるのは相当怖いものです。でもやらないでいるといつか限界が来ちゃいますから、何としてもやりきるしかありません。でも、やればやったで、きっと日本でも類を見ない規模感や技術的チャレンジの事例になると思います。年明けには、かなり面白い話ができると思うので、ぜひまた取材に来てください。

増井:その日が来るのを楽しみにしています。今日は長い時間、ありがとうございました。

(構成/武田敏則)

ChatWorkの山本正喜さんとトレタの増井雄一郎さん