【エンジニアイベントvol.6】3社はなぜScalaの導入に至ったのか～Nextbeat (衣笠) x SmartNews(瀬良) x ChatWork(かとじゅん)トークセッション①～

上津原清子, Yoshinobu Kinugasa

広報兼営業担当, 技術顧問

上津原清子

株式会社ネクストビート / 広報兼営業担当

フォロー

Yoshinobu Kinugasa

株式会社ネクストビート / 技術顧問

フォロー

on 2018/05/30

皆さんこんにちは、ネクストビート広報チームです。

3月16日から18日の３日間にかけて開催された ScalaMatsuri (https://2018.scalamatsuri.org/) の後日イベント、「NextMatsuri」を5月12日にネクストビート新オフィスで開催いたしました。本日は【NextMatsuriレポート】第一弾ということで、イベント概要とトークセッションのテーマ①の内容をご紹介させていただきます！

イベント会場はネクストビート新オフィス

一階エントランスの様子です！今回のイベントはオフィス移転を記念したエンジニアイベントでした。

ScalaMatsuri の登壇者のお二人とネクストビートCTO衣笠の三人のトークセッションを行いました

イベントコンテンツのトークセッションには、スマートニュースの瀬良様と、ChatWorkの加藤様、そしてネクストビートCTOの衣笠が登壇致しました。

登壇者プロフィール（敬称略）

瀬良和弘（せら・かずひろ）

スマートニュース株式会社 VP of Engineering。グローバル展開を目指すスタートアップ企業で VPoE として日々チームビルディングやエンジニア組織の構築に取り組む。ScalikeJDBCやSkinny Frameworkのメインコミッタであり、OSS活動やコミュニティ活動に積極的に取り組む大のScala好き。最近の趣味は英語学習。

加藤潤一(かとう・じゅんいち)

2014年7月入社／テックリードとして、次世代チャットワーク開発に従事。業界歴25年、小学四年生で初めてプログラムを組む。FA系、オープン系、ウェブ系など様々の現場を経験。大手Web企業において、Scalaやドメイン駆動設計を採用した大規模な基盤系システムの開発に従事。現職では、サーバサイドのアーキテクトとして、メッセージングシステムやOAuth関連プロダクトの開発を担当している。

衣笠嘉展(きぬがさ・よしのぶ)

ヤフー株式会社に新卒で就職し、メール事業部にてヤフーメールを日本版にローカライズするプロジェクトを担当。アメリカと日本を行き来する中で、少人数のエンジニアたちが事業を構築するシリコンバレーのベンチャー風土に触発され、2006年上場前のグリー株式会社に転職。新規事業のメインエンジニアとして、釣りスタ・探検ドリランドの立ち上げ・開発等に携わりGREEの収益拡大に貢献。その後インフラ事業部に異動、１万台のサーバを超える大規模インフラの設計・運用、またシニアエンジニアとしてチームをマネジメントを行いGREEでは8年間従事。その後立ち上げ間もないベンチャーのCTOとして、企業の人材採用を効率化するプラットフォームを開発。2015年に株式会社ネクストビートCTOに就任。

そして、今回のトークテーマは公募の中から厳選されたこちらの3つです！

①SmartNews、ChatWork、ネクストビートそれぞれがScalaを導入したきっかけ・目的
②ChatWorkとネクストビートのDDDに対する考え方
③Scalaコミュニティの盛り上がり

②③についてはまた後日の【NextMatsuriレポート続編】でお伝えすることにして、今回は①のトーク内容をお伝えさせていただきます！

①各社がScalaを導入したきっかけ・目的

Q-まずは、世の中には様々な言語がある中、なぜあえてScalaを選択し、導入に至ったのかについてお聞かせください！！(以下、敬称略)

加藤: ChatWorkでScalaを導入することになったきっかけは、当時開発をしていた社内プロダクトを外部に公開する際に起こった、システムをベースから見直そうとする機運の高まりからでした。
これは私が入社する前の話なのですが、ChatWorkは2010年から今のFalcon(ChatWorkのScala採用プロダクト)に当たる社内向けのシステムをphpで構築していました。それが色々と反響もあって、2013年頃から外部に向けて公開しようという動きが出てきたんです。

ただ、その時は社内のみでの運用を想定していたため、そもそものシステムの設計がスケールを一切考慮したものではありませんでした。そのため技術的負債が溜まりやすく、既にあちらこちらに支障が出てきている状況でした。
このまま中長期的な視点で運用するとなればいつか限界を迎えてしまうのは火を見るよりも明らかだったので、アーキテクチャ設計を一から見直すこととなり、その過程で言語も選定し直すことになりました。

そこで、言語選定を目的とした開発合宿がエンジニアとインフラチームの中で行われたのですが、ここでphpやpythonなど多種多様な言語と比較し、最終的にエンジニア達から選ばれたのがScalaだったそうです。*1
実はこの話を最初聞いたときはびっくりしました。「php書いてた人がいきなりScalaで書けるものなんですか？」と聞いたら「いや、意外といけますね」って。ホントかよ、って正直驚いてしまいました（笑）
兎にも角にも、これがChatWorkで初めてScalaが導入されることとなったきっかけですね。
そしてその時、Scalaをリードできる人がまだChatWorkの中に居なかったので、そこに私が参画するという形でChatWorkに入社しました。

やはりScalaは誰かリードできる人が居ないと、なかなか導入には踏み切れないと思うのですが、そのあたりネクストビートはどう考えているのでしょうか？

衣笠: そうですね、やはり言語やフレームワーク、設計によってそれぞれお作法があるわけで、それが分からないと中々難しいと思います。ScalaにはScalaのお作法があるので、それを理解した上で事業の基盤を作り上げていなかければならないですから。
実は私自身、ScalaとDDDを始めたときは、そのお作法が分からないものですから、加藤さんが書いているテックブログにはよくお世話になっていました。特にDDDとモデルの設計の箇所は『わからねぇな〜』と思いながら何回も読み直していた記憶があります（笑）*2

瀬良さんはどうですか？

瀬良: そうですね、私が2009年にエムスリーに入社した当時は、ずっと全てのプロダクトをJavaで開発していたのですが、当時Groovyとかの人気が出始めてきていたこともあって、新しい言語への興味が社内で湧きつつあったんですね。

ちょうどその当時、Twitterがサービスの一部をRuby on RailsからScalaに置き換えたなどの話題もあり、Scalaへの注目が少しずつ高まってきていました*3。そこでScalaを採用してみようという話になり、新しいサービスが Scala で開発されるケースが増え、結果としてシステムの2 割程度がScalaで書かれたコードで動くようになりました。

Scalaの導入にあたっては、やはり学習のコストなどが懸念されがちですが、エムスリーでは比較的スムーズに移行することができたと思っています。エムスリーのエンジニアの多くはJavaを書いていましたが、その時は別プロジェクトでRuby on Railsを採用していた事もあって、Rubyエンジニアも多く在籍していました。ただ、ScalaがJavaにもRubyにも似通っている部分が多かったので、両者とも習得には時間があまりかかりませんでしたね。ScalaがちょうどJavaとRubyの融合点にあるような言語だったので、結果的にScalaを採用してよかったのかなと思っています。

加藤: 新しい言語を導入する際に、よくScalaは複雑だからという理由で敬遠されてしまうことも多いのですが、導入するにあたって言語の複雑さ単体で比べても仕方がないと私は思っています。
言語を導入するにあたって一番重要なのは、目的と用途が合致しているかですね。そういう観点でいうと、大規模なシステムを作るときやパフォーマンスが要求されるようなシステムではScalaを採用したほうが良いかもしれない。それこそ瀬良さんが開発されているSkinny Frameworkとかを採用すればフルスタックでやりたいことがすぐにできますし、結局のところトータルコストを考えたときにどの言語を採用するべきか、とかは見えてくると思うんですね。
なので言語単体での難易度で比べるのではなく、もっと広い視点からどの言語を採用するかは考えたほうが良いと思います。

衣笠: そうですね。ただいきなり最初からScalaで頑張ろうと気合を入れてしまうと、特にベンチャー企業なんかは厳しい立場に追いやられてしまう可能性があるかもしれません。

ベンチャー企業は限られたリソースの中で、１年後とかには絶対に盛り上げていかなければならなかったりするわけで、とにかく開発スピードが求められる状況下でScalaを採用するか、というのはやはり難しいところがあると思います。
それこそRubyのような軽量プログラミング言語を使って、開発工数を加速して効率を重視したほうが良いのかもしれません。

実際、最初からScalaを採用して立ち上がった会社ってあまり無いような気がします。実はネクストビートのシステムも最初からScalaだったわけではなくて、主にphpとWordPressで動いていました。ただ、事業が成長し利用者が増えるに従って、負荷が指数関数的に増加してきて、サーバーにもスケール性が求められるようになってきたんです。でもスケールアウトができずに、スケールアップしかできなかったためサーバーの性能を高めるしか選択肢がない状況で。どこまでWordPressだけで億単位を稼ぐシステムを運用するんだろう・・・って感じでした（笑）

なのでシステムを抜本的に改修することに決めて、開発やリリースのしやすさなどを重視し、Dockerとの相性が良いScalaが良いんじゃないか、という話が出たこともあり、最終的にScalaを採用するに至りました。

瀬良: その話で言うと、私のエムスリーでの最後の仕事でもScalaを採用するか否か、という話はよく議論になりました。最初はその仕事を２人でやっていて、まずはどの言語を採用するかっていう段階から始まったんですが、もう一人の方から私がいるんだから全面的にScalaでいいんじゃない、ってよく言われていたんです。

でも結果としてAPIサーバーにはRuby on Railsを採用し、更に後ろのレコメンデーションエンジンやバックエンドのシステムにだけScalaを採用するに留めるというところに落ち着きました。これは絶対にこうしたほうが良いという確信があったのでScalaの採用は部分的に留めたのですが、結果として凄く良い選択でした。

なぜならJSONを構築する部分にRuby on Railsを使っているので他の部署からも開発の人員を集めやすいですし、インターン生とかでもコミットできる環境を作ることができたので。その反面、裏側のしっかりと作り込まなくては行けない部分に関しては、まず色々な知識も経験も必要となってきますし、しっかりと作り込めるレベルの人でないと一緒にできない。そこの境界分けが言語レベルで出来たのは良かったなと思っています。

当日は参加者の方々からの質問も受付け、Scalaの導入だけでなく、導入後の取り扱いに関してまで話が広がりました！

Q-scalaはよくコンパイルに時間が掛かると言われていると思うのですが、実際に導入してからは気になりませんでしたか？

加藤: 確かにScalaのコンパイルは遅いとよく言われますが、私はあまり気にはならないですね。というのもコンパイル自体そこまで頻繁にはしないということもありますし、そもそもIDE上で考えている時間のほうが圧倒的に長いので。

しかもフルビルドをする機会もさほど無いと思います。例えばユニットテストを書いた時とかでも１つか２つのクラスをコンパイルするだけで終わってしまうので、それなら時間もさほどかからない。なのでコンパイルの遅さ自体は余り気になってはいません。

衣笠: この間のScalaMatsuriで細かく構成を分けることでコンパイル時間を短縮しているとおっしゃっていましたよね。

加藤: そうですね。ライブラリを幾つか分割してS3にホスティングして、コンパイル時にダウンロードしてくることによってコンパイル時間を減らしているといった工夫はしています。

あとコンパイルとかCIの待ち時間を減らす奥の手としては、金で解決するって方法もありますよね（笑）高性能なマシンならばビルド時間も少なくて済みますから。

瀬良: 確かにフルビルドはそんなにしないかな、というのはありますね。あとおっしゃっていたようにライブラリを細かく分けるっていうのも効果的で、うちでも頻繁に開発がされる部分は細かく分けるなど工夫はしています。

お金を掛けて良いマシンを揃えるっていうのも確かにあるんですが、最近の開発用マシンはかなり高性能になってきているので、そこはさほど気にしなくても良いのかなとは思います。確かにDockerとかを使うと結構マシンのリソースを喰ったりするのですが、開発用のマシンであればパワーもありますし、さほど開発に支障が出ることもないでしょう。

衣笠: ネクストビートでも最初はphpのみの開発だったので、Macのスペックが控えめでした。ただScalaに移行してから、現場でマシンの性能不足による不満が続出したんです。僕はそんなこと全く起きていないのになんでかな、と思っていたら、ただ単に僕がIDEを使わずemacsで開発していたからなんの問題も無かっただけだったという（笑）

加藤: 衣笠さんだけIntelliJのライセンスが要らないという話ですね（笑）サムライズムの方々にお伝えしておきます。はい。

瀬良さんがおっしゃっていたように、最近はDockerとかKubernetesとか出てきているんですが、特にKubernetes(minikube)が滅茶苦茶リソースを喰うんですよね。Scalaの何倍もリソースを喰ってる時もあるくらい。でもこれって最近そういう開発シーンが増えてきているだけであって、別にScalaに限った問題ではないんですよね。

瀬良: そうですね。あと、最近はScala自体もかなり改善されてきていますよね。昔はよくコンパイルの際に依存関係を解決するライブラリの機能が良くなかったりして、開発を始めようってときに依存関係の解決でコンパイルが待たされたすることも多くて。そういったことがよくあったので、そのせいで Scala の第一印象がよくないということはかつては多かったです。

でも最近は依存関係を解決してくれるライブラリの性能も良くなってきていますし、プラグインを並列でダウンロードできるようにするプラグインでcoursierとかも出てきていたりしますしね。sbt自体も1系になってから相当早くなったりしているので、初期の頃の不安は今となっては全く感じません。

Q-継続的なバージョンアップが大変だと感じるのですが、どのタイミングであげるべきか等、ご意見を伺いたいです。

近々業務で使っているScalaとsbtのバージョンアップを検討しています。Scalaを2.11から2.12に、sbtも0.13から1系に上げる予定なのですが、私自身バージョンアップの経験が無くて。そのあたりの知見をお伺いできると嬉しいです！

加藤: 実は私の会社も最近一部のプロダクトにおいて、Scalaのメジャーバージョンを2.11から2.12に上げたんです。Scalaやsbtなどのバージョンを上げるにあたっては、まずは依存しているライブラリやsbtプラグインがそのバージョンをサポートしていないと上げられないので、そこのチェックが重要になりますね。

今回の場合だと、sbtは1.0と1.1は互換性があり問題にはならなそうだったので、あとはライブラリがScalaの2.12をサポートしているか調べる、というステップを地道にやっていくといった感じですね。

で、社内ライブラリとかもあるような場合だとクロスビルドしていく方向で変えていかないといけないので、やっぱりsbt職人は必要ですね。せめて移行時期だけでも社内に一人はそういう役割の方を置いたほうがいいのかなって思いますね。

バージョンアップを追っていくというのは確かに大変ですが、例えばAkkaとかは新しい機能が2.12以降でないと対応していなかったりするので、そういったものを追っていきたいならある程度リソースを掛けて継続的にメンテナンスをしていかざるを得ないのかなとは思いますね。

瀬良: バージョンアップの際には、やはりいっぺんにやろうとするのは良くないですね。言語自体のバージョンを上げるのは比較的簡単なのですが、いっぺんにあげようとするとリソースが割けないなんてことにもなりかねないので。ステップバイステップで別々に構築して行くのがいいのかなって思います。

衣笠: 確かに言語自体のバージョンを上げていくのは比較的容易だと思っているんですけど、目を瞑っていかないといけないようなバージョンアップの仕方をしてしまう場面も幾つかあって。例えばEitherとかはその最たる例ですよね。.rightをどこまで消して回って行くか、みたいな問題もありますし。

Scalaのバージョンを上げるよりも工数がかかるのは、やはりPlay Frameworkとかですね。特に2.6系に上げるときなんかは苦労が多かった。そういうときはCTOとか技術責任者が率先してバージョンアップに取り掛かっていって、危険地帯を予め察知しておく、みたいなことは重要になってくるかもしれないですね。

加藤: 確かにPlayのバージョンアップとかはかなり苦労するところが多かったですね。そういう点を踏まえると、やはりベストプラクティスは『一気にやらないこと』ですね。この点は凄く同意できます。

この後トークテーマ②③に続きましたが、こちらは、【NextMatsuriレポート続編を楽しみにお待ちください！