Scala Days 2011に行ってきた
どうも、鹿島和郎（かしまかずお）です。前回のコラムを書いたのが例の大震災直後だったので、約3ヶ月ぶりとなりますが、皆様はいかがお過ごしだったでしょうか。私の方はというと、地震直後は何となく気分がそわそわして仕事にあまり集中できず、4月くらいからようやく落ち着いてきたと思ったら、今度は仕事で忙しくなってしまい、ずるずると6月になってしまいました(正直ネタが切れてたのもあります)。
さて、突然ですが、この原稿は羽田空港でサンフランシスコ行きの飛行機を待っている間に書き始めたものです。6月2日～3日の2日間、アメリカのスタンフォード大学で開催されたScala Days 2011というイベントに参加するためです。
本コラムを読んでくださっている方はご存じかもしれませんが、昨年の9月に思い立ってScalaというプログラミング言語を勉強し始めて半年以上が経ちました。Scalaを勉強し始めて1週間も経たないうちに参加したScala座というイベントでは2010年のScala Daysに参加した方の発表があって、それ以来Scala Daysには興味は持っていたのですが、今回仕事でちょうどキリが良かったということもあり、思い切って参加することになりました。
2日間に渡って開催された本イベントのうち、個人的に興味のあるセッションを中心に紹介したいと思います。プログラムはこちら。
■Keynote by Martin Odersky
○実用段階に入ったScala
Scala Days 2011は、Scalaの作者であるMartin Odersky博士のState of ScalaというタイトルのKeynoteで始まりました。まずScalaの歴史を簡単に紹介して、その後現在のScalaの状況と今後の展開について話しました。去年も同じような内容の話を少ししていましたが、去年に比べてScalaが使われている場面が随分増えてきて、実際、スライドで紹介されていたScalaを使っている企業のリストには、今までこの手の話では必ず取り上げられていたfoursquareなどに加えて、VMwareやAmazon.comなどが加わっていて、Scalaが今までより一般的になってきたように見えます。
彼のScalaを作ったキッカケの1つが、関数型プログラミング(FP)とオブジェクト指向プログラミング(OOP)を1つの実用的な言語として実現させる事だったという話がありましたが、ここ数年で注目を集めている新しい言語の中でも、とりわけScalaは「実用的」という部分に大きな重点を置いているように思えます。
○並列化という大きなトレンドの中でのScala
本Keynote、そして今回のScala Daysの他の発表を見ると「並列化」というのが1つの大きなキーワードとなっています。今世紀初頭まではHWのCPUクロックの上昇という形で処理性能力の向上が進んできたのですが、ここ数年で一気にマルチコア化という方向にシフトしてきており、マルチコアをいかに効率よく使っていくかというのが、現代のコンピュータ言語に求められている大きな要件の1つとなっています。
OOPが今のように広く使われるようになった理由の1つとして、GUIという領域に対する問題解決の手法として、それまでの方法よりもOOPの方が優れていたというのがあったのですが、FPに対する並列コンピューティングというのがまさにOOPに対するGUIにあたり、今後、並列コンピューティングの重要性が増すにつれてFPの重要性・利用シーンが増してくると話していました。
これからの並列化に対するアプローチとして挙げていたのが、メッセージパッシングを使用したActorモデル、エージェントモデル、Software Transactional Memory（とスレッドの併用？）の3つで、従来のスレッド+共有リソースに対するロックという方式は、今後はあまり使われなくなると話していました。
並列化関連ではScala 2.9で取り入れられた「並列コレクション（※）」に加えて、「分散コレクション(distributed collections)」という単語も出てきました。本機能のリリーススケジュールは未定との事でしたが、実現すれば興味深い機能だと思います。
※JavaでいうListやMapに対する処理を並列で実行できるもの。例えば、Listのすべての要素に対して何かの処理をする際、Javaであればfor文で各要素に対して処理しなければいけないが、Scalaの並列コレクションでは、Javaのfor文の中で行うような処理を並列化できる。
○Scalaのさらなる普及のために
並列化以外にもいくつかの話が出ていて、開発環境の重要性などについても触れていました。開発環境は、Scala利用者の多くから出ていた不満の１つで、ここ最近ではScala開発チームが多くのリソースをEclipseのScalaプラグインに投入していて（※）、実際、最近のベータバージョンではかなり安定して使えるようになっているので、今後が期待できると思います。
※別のセッションでの質疑応答によると、Scala開発チームなどが元となって立ち上げたTypesafe社のリソースの約半分を投入しているそうです。
また、本Keynoteの最後で質疑応答がいくつかあったのですが、日本人の水島さんが
「日本では関数型言語は難しいという印象を持たれているが、それに対してはどう考えているか」
という質問をしました。それに対するOdersky博士の回答の中で、
「FPが難しいという意見は別に日本に限った話ではなく、世界中で聞かれる事だ。FPはパラダイム・シフトだから(多くの人には)難しく見える。OOPがでた時も同じような意見が出たが、それはOOPもパラダイム・シフトだったからだ。」
というようなことを言っていました。
■TT Session 4: Scala enterprise experiences
今回のScala Days 2011で「並列」と共に大きなキーワードとなっていたのが「enterprise」で、Scalaが研究者やプログラミング言語のファンのためだけでなく、実際に企業でどう使っていくかという内容のセッションがそれなりにありました。
2日目最後のパネルディスカッションのタイトルが「Scala in the Enterprise, What will it Take?」でしたので、「実用的な言語」としてScalaを企業でどう使っていくのか、というステージに入っているという点が昨年とは違うと感じました。
○Scala on Android: Real-world Experience at Bump Tehnologies
まずはBumpという人気のスマートフォンアプリのAndroid版がScalaを使っているようで、実際にどう使われているのかという話をtipsや問題点などと絡めて紹介していました。
「なぜScalaを使うのか」に関しては、開発者の生産性の向上、そして優秀な開発者を雇うため、という2つを挙げていました。シリコンバレーでは優秀な開発者を雇うのが非常に難しいそうですが（※）、新しい技術・言語を使う事が、それらの技術・言語に興味のあるレベルの高い技術者を集めることにつながると話していました。
ただ、実際にScalaでAndroidアプリを作るにはいろいろ厄介な問題もあるようで、Scalaはしばらくはサーバサイドを中心に使われていくものと思われます。
※実際に、企業に所属しているプレゼンターの殆どは、「We're hiring.」という内容を最初か最後のスライドに含めていました。
○Pedestrian Scala: Applying Scala to Performance Challenges in the Cable TV Industry
2番目がケーブルTV会社向けのシステムでScalaを使ったプロジェクトの話でした。ここの会社ではCATV向けの広告配信のシステムでScalaを使ったとの事です(視聴者の属性に合わせて広告を配信するような感じでした)。それまで使っていた、Java, Groovy, Hibernateを使った「レガシー」なシステムではパフォーマンスに関する問題があったそうですが、Scalaに切り替えたことによってそれは解消されたとのこと。
また、Scalaを使ったシステムに切り替えたことによるメリットを、顧客からの立場と技術的な面の2通り説明していました。
顧客の立場からのメリットとしては、以下が挙げられていました。
- 要求された時間内に処理が完了するシステムができた
- (処理速度向上により)ハードウェアコストを下げられた
- Javaに比べてコードの行数が減ったため、開発コストを下げられた
- メンテナンス性が増した
技術的なメリットとしては、以下を挙げていました。
- Scalaの並列関係の機能を使うことによるパフォーマンス向上
- Javaのようにスケーラブルで、かつ、Groovyのように素早い開発速度
- ビジネス課題の数学的な部分に対する解決の為のFPの適用
- 開発者の熱意が得られる(enthusiasm)
最後の質疑応答では、
「Hibernateは何に置き換えたのか」
という質問に対して、
「ORマッパーをいくつか検討したが、結局生のJDBCを使うことにした」
と回答していました。一応補足すると、ScalaからもHibernateやJPAは使うことができるのですが、どうしてもコードがJavaっぽくなってしまうと思うので、Scalaで違和感なく使えるORMが出てくるのを期待したいところです。
また、どうやって上司を説得したのかという話が本編中でも質疑応答の時にも出ましたが、彼の場合は直接の上司が保守的でOKしなかったため、その上のマネージャーに話を通して、OKしてもらったそうです。また、プロジェクトの結果が上々だったので、その上位のマネージャーが現在では会社内でScalaのサポーターになってくれていて、他のプロジェクトにも使おうという動きになっているそうです。
我々技術者は(組織に属している場合は特に)、新しい技術を使うことで何をもたらすことが出来るかというメリットを明確に提示しつつ、必要に応じてこうした根回しもする必要があると再認識させられました。
また、社内の技術者で抵抗する人はいなかったのかという質問に対しては、チーム全体にScalaの使用を強要するのではなく、Scalaに興味のある人を集めてチームを作ったのでそうした抵抗はなかったとのこと。先程の上司に対する根回しもそうですが、開発リーダー・マネージャ層がうまくプランを練って導入することが成功の秘訣だと感じました。これは新しい技術の導入に限った話ではありませんが。
○Scala at Bizo
3番目が、Bizoという会社でのScalaを使ったプロジェクトの話でした。Google Analyticsのような広告関連のプラットフォームだそうです。毎月2-3百万のリクエストを捌いていて、また毎年400％のペースで増加しているとの事ですので、データの規模としてはかなりの規模と言って良いと思います。
プログラミング言語はScala, Ruby, Java, JavaScriptを適材適所で使っているそうですが、インフラはすべてAmazon Web Services上に載せているとの事でした。
必ず聞かれる「Why Scala?」に対しての答えとして、生産性、そして並列化(が容易にできる事)とパフォーマンスの3つを挙げていました。
最初はRubyでプロトタイプを作ったのですが、本番のシステムをScalaで書き換えてからは約15倍高速になったそうです。ただ、これはScalaに限った話ではなく、JVM上で動作する言語であれば、大体同じような結果になると思われます。
使っている技術に関しては、従来通りivyなども使っていて、必ずしも一度に全てを新しい技術に置き換える必要はないと言っていました。これは他の発表や、去年のScala Daysの発表などでも聞かれた話で、各組織の状況に応じて柔軟に進めていく必要があるという事だと思います。
JavaとScalaの相互運用性に関しての話も出ていて、ScalaからJavaのコードを呼ぶのは全く問題がないとのことで、これは自分も同感です。JavaからScalaに関しては色々面倒なようで、彼らは基本的にはthriftを間に挟んでRPC経由でScalaの機能を使っているようです。
その他、 Scalaの標準ライブラリにバグがあった時の対処方法については
- その機能を使うのを避ける
- 同等の機能を自分で実装する
- ライブラリの問題点を修正する(そして開発チームにパッチを送る)
- Typesafe社から有償サポートを受ける
という選択肢を挙げていましたが、彼らは自分たちで修正するという選択肢を選んだそうです。その修正が必ずしも本体のソースに取り込まれてリリースされるとは限らないため、彼らは独自でScalaのライブラリをビルドして使っているそうです。このへんはearly adopterならではの悩みという感じがします。
■終わりに
長くなりましたので、今回はここまでにします。次回は分散関連の機能が大幅に強化される予定のAkkaについてのセッションを中心にレポートします。話を聞いた限りではかなり期待できそうで、分散処理が必要なシステムを開発しているのであれば、Scala + Akkaは検討すべき選択肢だと言えます。
それではまた。