注意: これは同時翻訳の記録等からそのまま起こしたもので正式なものではありません。コメント等で詳細を補足して頂けると助かります。
- パネリスト（五十音順）:
- 加藤（ChatWork 株式会社、@j5ik2o）
- 瀬良（M3, Inc.、@seratch & @seratch_ja）
- 丹羽（Twitter, Inc.、@niw）
- 福原（株式会社サイバーエージェント）
- 吉田（株式会社ドワンゴ、@xuwei_k）
- 同時翻訳: Eugene Yokota（Typesafe Inc.、@eed3si9n & @eed3si9n_ja）
- 司会: 岡本（@okapies）
- 横田: 今回のパネルディスカッションのテーマについて説明したい。テーマである "Scaling Scala" の「スケーリング (scaling)」には、性能のスケーリングと、大きなチームのスケーリングの両方の意味がある。
- 岡本: では、パネリストの皆さんから自己紹介を。
- 吉田: ドワンゴの吉田です。Scalaz や sbt や ScalikeJDBC や…いろんな OSS のコミッターをやってます。
- 福原: サイバーエージェントの福原です。
- 丹羽: Twitter の丹羽です。
- 加藤: 加藤です。以前は 某G社 でチャットサービス開発のリードをやっていたが、現在は ChatWork で働いています。
- 瀬良: M3 の瀬良です。
- 岡本: では、吉田さんから。
- 吉田: ドワンゴでは Scala を使っているが、スケーリングといっても、実際のところ Scala 自身がボトルネックになることは少ない。だいたい問題になるのはデータベース周り。パフォーマンス計測に Gatling を使ったりはしている。
- 加藤: スケールの文脈は CPU バウンドと I/O バウンドに分けられる。大規模サービスで本当に難しいのは I/O の分散で、プログラミング言語はあまり関係がない。Scala は CPU バウンドにおいては容易にスケールする。
- 加藤: CPU バウンドは
Futureや Akka でスケールできる。一方で、I/O 分散は MySQL をシャーディングするなどして対応しているが、難しい。いかに I/O を減らすかが鍵。I/O を分散するフレームワークが Scala で出てくるとうれしい。 - ？？: Dynamo を使うのはどうか？
- ？？: （※ なんて回答されてましたっけ？）
- 丹羽: Twitter には 2,000 人の従業員がいるが、うち 1,000 人がエンジニア。「Twitter って簡単でしょ？ なんでそんなに人が要るの？」とよく言われる。ユーザが 100 人しかいないなら、確かに簡単。Twitter の最初のバージョンは Rails で、MySQL に status テーブルがあってフォロワーを IN 句で検索して…とかやっていた。
- 丹羽: システムのスケールには、数百万、数億と増えるユーザのトラフィックを捌くことと、システム内部のコンポーネントが増えることの二つがある。どちらのスケーリングも同じ仕組みでできたのは Scala の良い点。
- 丹羽: Finagle を使うと全てを統合できる。Finagle はあらゆるものを
Futureで返す。様々なサービスをFuture経由で呼び出して、ギリギリまで評価しない。 - 岡本: 最近、日本では「マイクロサービス」という言葉が流行っている。Twitter は、Finagle を使うことでうまく組織をスケールさせているように見える。
- 丹羽: マイクロサービスという言葉は、今回の ScalaMatsuri で初めて聞いたが、Twitter ではそれが当たり前だった。最初の Twitter は、"Twitter" というモノリシックな Rails アプリケーションだった。やがて配備で問題が起きてきたので、我々は全てを分割していった。
- 瀬良: 我々のサービスの顧客は医師。医師の数は限られているので、Twitter のような大規模なスケーリングという要件はない。しかし、非同期処理で Java だと大量のボイラープレートを書く必要がある場面でも、Scala だと簡潔に書けて良い。
- 福原: 我々は、広告配信のようなバックエンドサービスに Scala を使っている。最初は◯◯でうまくいくと思っていたが、最終的に
Futureに切り替えた。（※ 補足おねがいします） - 吉田: 私はニコニコのバックエンドを担当している。ニコニコのバックエンドは多数のマイクロサービスで構成されていて、互いのデータを共有するために API で通信するものも多い。そのような場合に
Futureが使える Scala は便利。 - 加藤: 我々も Finagle を使っていた。Finagle の
Futureと Scala 標準のFutureの変換は地獄。しかし、ドメインロジックをFutureを使って書くだけで、CPU の例えば 24 コアを均等に使い切ることができる。あの衝撃は体験しないと分からない。一方で Akka は同期処理を前提にしている。 - 岡本: 会場の方で何か質問は？
- Q. Scala が向いてないと思うところは？
- Q. トランザクションコンテキストを引き回すのはどうやっている？ implicit を使えば良いのだろうか。
- 瀬良: 私は implicit は使っていいと思っている。サーブレットではスレッドローカルを使うこともできる。
- 加藤: DDD でリポジトリパターンを記述する際に Connection/Transaction をインフラ層で制御するが、コンテキストを implicit で引き回すところは議論がある。
- 吉田: 私はコンテキストオブジェクトの引き回しは嫌いだ。ただ、仕事ではおそらく他の人のやり方に従うだろう。Twitter の "Effective Scala" ではコンテキストの引き回しには否定的だったはずだが、どうやっているのか？
- 丹羽: それはプロジェクトによる。いくつかのプロジェクトでは、全てのメソッドが第一引数としてコンテキストオブジェクトをとるようになっていて、implicit ですらない場合もある。Twitter の長いの歴史の中で、全てのプロジェクトにおいてベストプラクティスが徹底されてきたわけではない。だから、理想はともかくとして、それが置き換えようとしているレガシープロジェクトからの影響は避けられない。
- 福原: 私は implicit を使ってきたが、今は Reader モナドを調べている。ただ、まだよく分からない。
- 吉田: Reader モナドはいいと思う。ただ、モナド変換子 (monad transformer) を十分に理解していないとハマる可能性が高い。
- Q. implicit を増やすとコンパイル時間が増えるが、それを気にしてコードを書いているのか？
- 横田: scalac の implicit 検索や string interporation の実装がよくないので、コンパイル時間が長くなってしまう。
- 加藤: 私はあまり気にしない。
- ？？: フレームワークを使う上ではあまり気にしない。（※ 瀬良さん？）
- 丹羽: システムが肥大化してくると、言語はあまり関係がない。例えば、Google は "Google" という名前の巨大でモノリシックなプログラムを開発している。Facebook も同様のはず。彼らは、C++ で書かれたコードを数時間かけてリンクし、ギガバイトクラスのバイナリを生成している。つまり、たった一行の修正を加えただけでも、そのコンパイルに数時間かかる。それに比べれば、Scala のコンパイル速度はそんなに悪いものではない。
- 吉田: コンパイル速度を改善するためにコードを修正しようとするよりも、速いマシンを買った方がいい。
- Q. IntelliJ を使っているのだが、メモリを 16 GB 積んだマシンでも、動作がどんどん遅くなっていってつらい。
- 吉田: IntelliJ は、まだ正確さに問題がある。私は Vim を使っていて、それで大きな不満はない。
- 丹羽: Twitter では、皆 IntelliJ を使っている。ただ、IntelliJ はコンパイルエラーでない所をコンパイルエラーとして指摘してきたり、
scalaパッケージをインポートしようとしてきたりする。後者については、import scala.Someのような行を自動的に削除する git hook を仕込んでいる。 - 丹羽: とはいえ、大きなコードベースにおいて IntelliJ は非常に有用。我々はビルドツールに pants を使っている。pants には IntelliJ サポートがあって、いくぶん確立したプロセスがある。いくつか欠点はあるが、現在はこれが最も良いと考えている。
- Q. Scala を使うプロジェクトでチームの規模が大きくなってくると、Java や Ruby のように出身の文化が違う開発者同士のデザイン原則をすり合わせる必要が出てくる。どうやっているのか？
- 加藤: 私は、トレイトを使って全体の方針を決めるようにしている。全体の方針が分かるようなトレイトを書いて、例となるユースケースを実装する。方針から外れるものはレビューで指摘して、考え方を浸透させていく。
- 加藤:
varは甘え。Java から来た開発者はvarに戻りたがるが、そこを正しい方向へリードできる人物が一人いると良い。(性能のための最適化で局所的にvarを利用するといった正しい使い方であれば問題はない) - 瀬良: 私は、Java から来た人と Ruby から来た人の両方と一緒に働いている。担当者ごとに、この機能は Java っぽいとか、この機能は Ruby っぽいとかはどうしてもある。とはいえ、「このやり方が正しい」ということを言い出すと論争になりがち。その時々でチーム内で合意を形成して、これでいこうとリーダーシップを取る人がいると良い。「正しい答え」というものはない。
- 丹羽: Twitter には Ruby から来た人や Java から来た人が数多くいる。ある開発者がどちらなのかは、スタイルが全く違うのでコードを見るとすぐに分かる。どちらかというと、Ruby の人の方が Scala っぽいコードを書く。
- 丹羽: コードレビューの不毛な戦いを避けるには、時には諦めることも大事だ。ガイドラインはあるが、実際には
XXXFactoryを見かけることは珍しくない。Twitter のようなアメリカの会社でも「空気を読む」のが大事。既にあるコードに合わせて自分のスタイルを変えるのが、実践的な態度だと思う。 - 福原: 新しいプロジェクトでは、アーキテクトがリードする余地がある。我々は、社内で "Functional Programming in Scala" の読書会を開催している。全ての章を読んだわけではないが、読書会を通じて、例えば参照透明性の考え方を共有することができた。
- 岡本: 時間です。パネリストの方々、ありがとうございました。