前出さんとの出逢いはシリコンバレー
－－ 今回は前回の前出さんからのご紹介でChatWorkの大村さんです。アメリカでの大村さんとの出会いがリアクティブへ方向転換するきっかけになった、というのがご紹介いただいた理由でしたよね。
前出：はい、そうです。
－－ 前出さんと出逢う以前からアメリカで活動されていたということですが、当時の話をお聞かせいただけますか。
大村：前職で2012年の5月にアメリカ赴任が決まって、次に技術開発をするべき新規技術の開拓・調査と、協業できるパートナー会社をシリコンバレーおよびアメリカ全土で探すというミッションの元、現地法人で活動していました。
そこで、GoogleやFacebookやTwitterなどがどんな技術に注目して使っているのかの調査をしていました。
日本にいる時に「プログラミングScala」を翻訳する機会に恵まれたこともあって、当時Scalaを業務では使っていなかったのですが、アメリカにいる時も興味をもって引き続き使ったりトレンドを追いかけたりしていました。
前出さんとはSIerでの先を考える同志のような共感を持ちました
－－ 前出さんと大村さんの出逢いでどんなお話をされたのでしょうか
前出：Scalaをエンタープライズで広げていく事を考えて、プログラミング言語で広めていく以外でどんなことが出来るのかを模索していました。
そういう中で、弊社もシリコンバレーに現地オフィスがあり渡米した時のことです。
現地のメンバーに「シリコンバレーでScalaの事を調査していたり取り組んでいる人っていないですか？」と聞いたところ、大村さんを紹介してもらいました。
「日本で同じSIerとして早い段階からScalaの本を翻訳されている方の話を聞いてみよう！」ということになって訪問し、その時にやっていた取り組みを打ち明け、そこでリアクティブの話になりました。
大村：もともと私はAkkaに興味を持っていたのですが、周辺で変化がおき始めた事に気づきました。Typesafe（2016年3月10日にLightbendへ改名）が会社になり、リアクティブという言葉を使い出したり、WebinarやカンファレンスでC10K問題を例にしてサーバサイドのアーキテクチャにおけるパラダイムシフトの必要性を話していました。具体的には1リクエストに1スレッド割り充てるようなモデルではだめで、Akkaのような固定のスレッドプールでイベントベースで処理するようなモデルが適しているという事でした。
私もそれに共感し、Akkaを追い続けていたこともあり、前出さんには「SIerでエンタープライズのシステムで取り組むといった時に、今までのアーキテクチャを前提にしていると行き詰まりますよ。」「新しいパラダイムとしてリアクティブという考え方がイケています」と言う話をした覚えがあります。
前出：これが転機になってリアクティブで推していくアプローチに変え、問題解決の糸口の一つとして活動を続けていくことにしました。
大村：私とはミッションが少し違ったんですね。私は海外拠点にいて、人員も限られていたので、調査業務や報告業務が主で、新しい概念や理論、原理などが実現可能であることを示すため活動である、POCのような事が充分に行えず葛藤していたところ、同志のような前出さんがいらして、やりがいや気苦労など共感したのを強く覚えています。
－－ シリコンバレーで同じような境遇の方が集まるような場ってあるのでしょうか？
前出：2ヶ月ほどシリコンバレーにいて感じた事は、毎日のようにMeetupが開催されていて、興味のあるエンジニアが自然と集まるという印象を受けました。日本人の集まりというのもありました。
大村：日本人のみが集まるmeetupがあったり、Scalaというテーマでは北と南で大きな2つのmeetupがあります。SF ScalaとScala Bayが存在し、毎月開催で100人程度が集まります。サンフランシスコで開催されるSF ScalaはAlexy Khrabrovさんがオーガナイザーで、ScalaMatsuri 2016でも来日されコミュニティについて発表されていました。Scala BayではVlad Patryshevさんがオーガナイザーで型システム、圏論に関連するScalaの話題が多い印象です。
－－ 出会いが多いシリコンバレーにいると会社を移るきっかけも多そうですね
前出：シリコンバレーで新しい技術にチャレンジするという環境に個人的な憧れを持っているのですが、それをやめてまでChatWorkに移った経緯ってあるのでしょうか？
大村：新しい事を調査するのは刺激があって楽しいのですが、エンジニアとして立ち戻った時に、もっとモノを作ってみたいという思いもありました。ChatWorkは東京と大阪にオフィスがあるのですが、実は社長は日本にいなくて、一人でシリコンバレーにいます。シリコンバレー駐在時に社長と知り合って、アメリカで開かれたRe:InventにChatWorkのScalaの開発者メンバーも来ていて一緒に話をして、情報交換会をしたのが繋がりの最初でした。
前出：SIerからWebサービス会社に移った大村さんに聞いてみたいことがあります。
SIer在職者視点になりますが、サービサーに行くという事はそのサービスをずっとやっていくことになりますよね。私はそれが自身の事になるとあまりイメージできなくて、SIに対する様々な意見はありますが、自分がいいと思った技術で、色んな会社の色んな業種・規模のシステムやサービスに関わり貢献できる所に楽しさを感じています。大村さんは「チャットワークという１つのサービスをずっとやっていくんだ」みたいな感じで移る事を決心したんですか？
大村：技術的なマッチングもあったのですが、創業者である社長の魅力に惹かれた部分も大きいです。ChatWorkの「やらないこと14条」があって、ちょうど私が入る頃に、「他人の資本をいれない」「株式公開しない」という2つを外した時があり、「なぜ外したんでょうか？これからタガが外れていくんですか？」と聞いたところ、「そうではない」と返事がありました。
ChatWorkには会社の「Make Happiness」といういい理念があって、その理念に共感してくださらないお客様とは取引しないくらいに徹底しており、すごくいい会社だなと思ったのが大きく、ただ単にWebサービス企業に行きたかったわけじゃなく、人とScalaという技術で次に行こうという姿勢でした。
また、お話を伺う中で、Slackが台頭してきている中で、ただ巨象を追いかけるだけでなく、ChatWorkとしての立ち位置をしっかり見据え、戦略を持って成長しようとしている所がいい会社だなと思って、ご縁もあり決めました。
前出・浅野：おぉぉ、いい話ですね。
－－ という経緯があって、ChatWorkさんでScalaで大きくシステムのリプレースをしようとしている取り組みの一環もあり、入社されたわけですね。
大村：はい、2015年8月頃の話です。入社後はすぐにScalaのプロジェクトに入ってアプリケーションのコードを書いたり、AWS周りの事に取り組んだり、Akkaを使ったプログラミングもしています。
Akkaをプログラミングする時にスレッドプールのチューニングはやっぱり悩みます
－－ 入社してプロダクションでAkkaを使ってみてどうでしたか
実はまだプロダクションでAkkaを使えているわけではなく、まだ開発中です。ただ開発の中で、竹添さんのインタビューでも言及されていましたが「Akkaを使った時に難しくなるのはスレッドプールのチューニング」と言う事は実際にあって、私もそう思いました。ブロッキングするコードがあるとスレッドが詰まってしまうので、できる限りブロッキングにしないようにする大事さを体感しています。
－－ どうしてもブロッキングしないといけない時はどうされていますか
大村：この問題はずっとChatWorkでも課題にあがっています。ScalaMatsuri 2016の時に来日したAkkaのメインコミッターでもある Konrad Malawskiさんに「負荷テストをしたらスレッドが詰まって困っている」と相談したところ、「ブロッキングIOをするアクターには専用のたくさんのスレッドプールを割り当て、詰まるかどうかは負荷テストの中で調節しなさい。それしかないと思います。」との回答をいただきました。
－－ 突発的にSNSやメディアに掲載されたりしてバズった場合のようなケースで、リクエストが急激に増えるような場合にすぐに対応はできるものなのでしょうか？
大村：すぐには難しいかもしれません。スレッドプールがギリギリになったらダメですね。Fork/Joinプールを使うとスレッドを増やす事はできるのですが、そうしてしまうと今度は逆にOutOfMemoryで落ちることもあるので、難しい問題だなと思います。
－－ 今のユーザ数や増え方であれば現在の使い方で問題なく運用していけそうですか？
大村：そうできるように現在取り組んでいます。
－－ 開発中のシステムの中でリアクティブは取り入れていますか？
大村：sprayとAkkaを使って良さを引き出そうとしています。ただ、完全に非同期にアクタープログラミングまでにはしていないので、完全にリアクティブかと言われれば微妙ですが、部分的にリアクティブであるとは言えるかもしれません。
ネットワークを介するマイクロサービスは考える事も多い
－－ リアクティブシステムという面で見た場合はマイクロサービスが前提である事が推奨される一方、マイクロサービスの面で現状を見た場合には最初からマイクロサービスにすると失敗するケースもそれなりにあり、最初はモノシリックに作り、徐々に切り出していくというアプローチも良いという声も聞きます。
そういう中で、リアクティブとマイクロサービスを一緒にやったら、どれくらいうまくいくものかという事に興味があります。マイクロサービスというキーワードが関わった時に熟練度との関係など実際どうなんだろう？というのが以前から気になっていました。
というような、マイクロサービスに関する話をお聞かせいただけますか。
大村：例えば、1つのマイクロサービスでWebサービスを提供していたらそれはモノリシックと言えます。マイクロサービスは幾つかサービスがインタラクションするのが前提になりますので、インタラクションして繋ぐ所が、ひとつ大事になってくるところだと思います。
ネットワークを介してやりとりするので、エラー処理をしたりタイムアウトもありえます。サービスディスカバリも考えないといけないので、マイクロサービスは簡単ではありません。マイクロサービスを呼び出す時にはCircuit Breakerのような障害の連鎖を防ぐ為のような仕組みが必要だったり、同じようなリクエストを束ねるような仕組みも必要だったりします。
サービスディスカバリという側面で言うと、私が好きなNetflixのOSSライブラリの中でEurekaというライブラリがあります。通常、ロードバランスする時は一つのリバースプロキシが処理を振り分けるのですが、Eurekaでは発想を逆転させ、どこで動いているかを覚えているサービスを立てておき、クライアントはどこで動いているかだけを問い合わせし、クライアント側でロードバランシングをします。
外部に公開するサービスだとこの方式は難しいのですが、内部でサービス同士をスケーラブルに繋ぐ場合はこういう技術も大事になってきます。ただし、たくさんでているOSSを組み合わせて、マイクロサービス間を繋いで全体として、レジリエントかつスケールするシステムに仕上げるのは、言うほど簡単ではないと思っています。
着目点を疎結合以外に目を向けてみよう
－－ DIを使ったMVCフレームワークがメインの頃のシステムより、リアクティブ+Netflixが提供しているようなOSSを組み合わせたシステムの方が複雑度は高そうに感じます。
大村：そうですね。複雑度は増していますよね。
－－ インタビュー冒頭で、「このままでは今までのアーキテクチャでは行き詰まるのでリアクティブにしていかないと」という話題になりましたが、開発規模・複雑度を踏まえ切り替えるタイミングや交差する起点ってどのあたりになるんでしょうか？どういったチームや環境にあっているかなど、そういったお話が聞ければと。
大村：以前に前出さんとディスッカションをした事があるテーマですね。リアクティブシステムを作る時にはメッセージ駆動が中心になります。今までのアーキテクチャはサーバーを並べた時にスケールしているのですが、捌けると思っていてもよく見てみるとスレッドってブロッキングIOですごく遊んでいる事が多いのです。
そこをメッセージ駆動で置き換えていくと、CPUリソースを限界まで使い切ることができる所に、メリットがあるのではないかと思います。リアクティブと今までのアーキテクチャの交差点というより、プログラミングモデル以外のそこに気づくかどうかじゃないかと思います。今の巨大なエンタープライズのお客様でもServletのシステムモデルで30台〜300台で運用しているところを、ノンブロッキング実行モデルで書き換えると実はそこまで台数が必要なく、よりスケーラブルになる可能性が高いのではないでしょうか。
着目点として同じリクエストが捌けるけど、コストがどれくらい違うのかという視点ができそうですね。
－－ こうやって二人はよく会ってディスッカッションしているんですか
前出・大村：いやぁ〜。どうでしょう（笑）
大村：リアクティブの勉強会やイベントには都合がつけば行っているのでそこで会った時にお話をするという事が多いですね。
Scalaの型システムの強力さに惚れた
－－ そんな大村さんがTypesafe以外のところで注目したり面白いと思っている事はどのあたりでしょうか
大村：RxJavaが生み出したプログミングモデルも面白いと思っています。少し前はFinagleがScala界隈で流行っていて、それはServerをRequestからResponseのFutureを返すというモデルで抽象化したのですが、RxJavaはRequestの流れからResponseの流れへの変換がサーバーであるとした所が面白いですね。
－－ Scalaをやっている時の楽しさはどのあたりでしょうか
前出：大村さんが好きになった理由はなぜか記憶に残っています。（笑）
「Scalaの型システムの強力さに惚れた」でしたよね？
大村：はい、最初にScalaへ興味を持ったのは型システムの柔軟さです。JavaのGenericsでもすごいと思っていたのに、Scalaを勉強した時にVariancesという概念を知った時と、Context BoundがないScala2.7の時代になりますが、View Boundは革命的だと思いました。それはソフトウェアの変更に対する考え方で「Open-Closed Principle」があり、Open-Closed Principleの意味が示す、「拡張に対しては開いており、修正に対して閉じている、そしてコンパクトである」というコンセプトを具現化できている事に魅力を感じました。
その後Context Boundという文法がでてきて、Open-Closed Principleをさらに綺麗に具現化できることになってまたまたすごいなと思いました。
楽しさはそのパワフルさを感じながらコードを書いているときですかね。（笑）
－－ コードを書いて開発している時はどういう感じでやっていますか
負荷テストやスケールさせるようなものはクラウドにのせていますが、それ以外はローカル環境で確認しています。負荷テストは日常的に回せるようにしたいねという話をしていたります。
単体テストなどはCIなどでやっており特別変わった事はしていませんが、Scala Checkを要所で使ったりはしています。
Akkaでマイクロサービスを実現するという仮説は面白いアプローチ
－－ 前出さんから大村さんに現時点で聞いてみたい事はありますか？
前出：マイクロサービスの話で私が持っている仮説があります。サーバーがリモートなのでエラーが発生することを考えないといけなく、分散処理という難しさがあるのはAkkaでも同じと考えています。ということは、最初からマイクロサービスで作らなくても、Akkaで分散できるようにアーキテクチャを作っておけば、そこからマイクロサービスに移行するのはハードルが下がるんじゃないかと思っています。
もし「これからマイクロサービスをやっていかなければ」となった時に、マイクロサービスというアーキテクチャにハードルを感じるのであれば、「まずはAkkaで分散という風にやっておけば必要な時にすんなりと移行できる」という仮説です。この仮説に意見をもらえないでしょうか。
大村：いいアプローチだと思います。マイクロサービスとなるとHTTPとなりがちですが、昔からRPCがあったりAkka-Remoteもありますし、必ずしもプロトコルがHTTPじゃなくてもいいのでは。
前出：Circuit Breakerの仕組みがAkkaに入っていますので使えるとは思いますが、大きいサービスを意識した時に設計のポイントになりそうな所はどのあたりでしょうか。
大村：マイクロサービスの繋ぎ込みのところで、Akka-Remoteを使う時にハードルになるのは、スケーラブルにどうやって繋ぐかという点だと思います。Akka-Remoteだとアクターがどこで動いているかを知らないと透過的に呼び出せないので、その時に使える機能としてAkka Clusterの中に「cluster-aware routers」というものがあります。
これを使えば、Akka Clusterの中であれば、あるアクターから役割を持ったアクターの集合に対してスケーラブルにルーティングしてくれるので、そこにCiruit Breakerも仕込めるし、クラスターだとロールも持てるので、それを活用すれば、うまく繋げ、エンドポイントも分けれるんじゃないかと思います。
仮説がうまくいけばですが...
－－ 仮説検証の結果をどこかで聞いてみたいですね！
大村：そうですね！
Akka Clusterは難しさもありますが、便利そうです。
前出：レジリエンスを担保していきたいのであれば、この流れになるんじゃないかとは思います。
大村：分散システムではレジリエンスは一番大事な性質で、ScalaMatsuri 2016でJonas Bonérさんも言っていた「レジリエンスがなければなにもないのと同じ」というフレーズも記憶に新しいです。
マイクロサービスを呼ぶ時に、呼び出し先が落ちてて呼ぶ側も一緒に落ちちゃったら意味がないので、フェイルオーバー用のサンプルの値を返す事ができれば、サービス全体と考えた場合に画面全てがエラーになるのか、例えばオススメ表示部分だけ1件も表示されないだけなのかは大きく違いますね。
Webサービスの企業だとサービス自体が収益元なので、稼働率はものすごく気にする必要があり、そういう意味でもレジリエンスが重要になり「落ちない、落ちてもなんとかして戻ってくる、どこかが落ちてもなんとか動く」という性質は大事だと思います。
Akka Clusterを使ってマイクロサービスを実現するアイデアは面白く、できる気がしてきました。
早くAkka HTTPがStableになって欲しい！
－－ 他にも何か前出さんから聞いてみたい事がありそうですね。
前出：はい。私はプロダクションよりもPOC的なことをやる仕事が多くなっているので、実際に今プロダクションを作られている大村さんに、エクスペリメンタルなモジュールの採用をどう捉えているかを聞いてみたいです。
大村：方針としてはエクスペリメンタルなモジュールは気軽には使っていこうとはなっていません。早くAkka HTTPがStableになって欲しいです！
でも、魅力的なモジュールが多いですよね。
これからAkkaをやってみようという人に向けて
－－ 大村さんはScalaやAkkaが手になじんでいるとは思いますが、これから入っていく人にステップとしてどうやっていくのがオススメですか？
大村：パッといいアイデアは思いつかないですが、Scalaはドワンゴさんや、はてなさんが公開しているテキスト（ドワンゴさん「オリジナル新卒エンジニア向けの研修資料」、はてなさん「はてな教科書」）をやってみるのがいいんじゃないかと思います。
前出：アジャイル開発の例になりますが、ラボのようなところに入門すると、アジャイル開発を進めるにあたって必要なロール毎にメンター役がいて実際のシステムを一緒に開発することでアジャイルを身につけ、次からはメンター無しでアジャイル開発ができるようになって巣立っていくというようなサービスを聞いたことがあります。単に困っていることの相談にのるだけのコンサルではなく、このようにチームの一員として一緒に苦労してScalaやAkkaでそういう枠組みが実現できるといいなと思っています。
大村：よく知っている人の弟子になってScalaやAkkaを学んでいければという感じですね。学ぶ方も楽しいし面白そうですね。
大村：私がAkkaを学んだ時にやったことなんですが、Erlangの本でプログラミングErlangという書籍の例題で、「アクターでリングを作ってメッセージをリングの中で回して計測してみよう」というものがあって、それをAkkaで最初にやって学びました。応用として、リングを壊すときもリングの頭にメッセージを流すと順番にストップのメッセージが流れていって、アクターが全て綺麗に終了するというようなものです。
そこで、計算させようとすると例外が発生したりもするので、自分で色々シナリオを膨らませる事もできて、ノードが勝手に落ちた場合に復帰させたい時には、スーパーバイザーやデスウォッチの仕組みが必要になったりするので、小さい課題の題材としてよかったです。
単純すぎるのでわかった気になるのは早すぎですが、入り方としてはちょうどいいかもしれません。他の言語にも応用できるので新しい言語でアクターを学ぶ時は私はいつもこの題材をやっています。
最後に一言
－－ 最後にこれからについて一言お願いします
大村：ChatWorkに転職した目的でもありますが、Scalaという技術を使って次世代のチャットワークを作っていきたいというのがあるので、ScalaとAkkaを使ってチャットワークが成長していく時に支えれるようなバックエンドを実現できるように、日々学びながらも仕事に活かしていければいいなと思います。
前出：国内でも貴重な会社だと思うので是非頑張って欲しいです！
－－ 次回に繋げていきたいので、今日の話した大村さんや前出さんがお話が聞いてみたいと思う方ご紹介いただけないでしょうか
大村：私と親交が深い、Deeplearning4jの開発やScalaMatsuriのオーガナイザーをされている麻植さんをご紹介します。
－－ では、本日は長時間どうもありがとうございました。
出席者
- インタビューイー ChatWork 大村
- インタビューワー アットウェア 浅野、 TIS 前出