あなたがCRubyではなくJRubyを使うべき理由
こんにちは、＠IT編集部の西村賢（@knsmr）です。先日、地域Rubyコミュニティの「Asakusa.rb」の花見に参加しました。世界でただ1人のCRubyとJRubyの双方のコミッタである中村浩士（@nahi）さんに「CRubyではなくJRubyを採用すべき理由は？」という話をお聞きしました。中村さんの指摘で興味深いのは、本当はJRubyを使うべき人々が、その良さに気付かないままCRubyを使っているのではないか、という点です。
以下、お花見気分がほとばしる動画（背後で子どもたちも走りまわっております）で、若干音声が聞き取りづらい部分もありますが、中村さんのお話の動画をお届けします。CRubyではなくJRubyを選ぶべき理由について説明しているほか、CRubyとJRuby、Rubiniusの関係についてもご意見をいただけました。
中村さんの指摘をまとめると、
- CRubyのライブラリは処理系をブロックするものが少なくなく、Webアプリをスケールするのに工夫がいる
- プロセスを分けるなど自分で問題を同定して工夫ができるハッカーがいるなら、CRubyでもいい
- しかし、RailsもRubyのライブラリも最近はスレッド・セーフになりつつあるので、WebアプリでリクエストをさばくのにJRubyのスレッドを使ったほうが、CRubyでアプリケーションサーバを複数並べるよりも良いのではないか？
- そのメリットとはJVMにシグナルを送れば、すぐにスレッドのダンプを取ったり、パフォーマンス解析ができるツール群があるから。Nginx＋Unicornクラスタでもいいかもしれないけど、監視や分析ツールも自作するんですか？
というところかと思います。
JRuby採用の自明な理由について中村さんは述べていませんが、ちょっと付け加えておきます。
JRuby採用の理由として大きいのは、元々Javaを使っている人々が、より記述力が高くて変更に強いRubyを併用するというケースでしょう。例えばLinkedInのBaq Haidriさんの以下のプレゼンが非常に参考になります。Haidriさんいわく、JVMは素晴らしい、その上、JRubyを採用してSinatraベースの独自DSLによって開発生産性が向上したといいます。LinkedInでは、すでに構築済みの認証モジュールなどはJavaのままで、それらを組み合わせて画面を作るロジックをDSLで書いているそうです。
さて、CRubyではなくJRubyを使う理由として次に大きそうなのはライブラリです。Ruby／Railsのライブラリの世界も十分に大きいのではないかと私は思うのですが、例えばExcelファイルを読み込んで何らかの処理をする、というときにどの程度「使えるライブラリ」があるのかを比較すると、Javaの世界のほうが有利だということを指摘する人もいます。JRubyではJVM上の資産が使えますし、JRuby1.6からはCRuby向けのCエクステンションすら、インストールコマンド一発でコンパイルしてFFIで呼び出せるようになっていて、両方の世界の資産が使えるので、その意味でもJRubyにメリットがあるということかと思います。
今のところRailsではCRubyを採用するケースがほとんどでしょうし、その理由はいろいろあると思います。でも、そろそろJRubyの採用事例も増えてくるのかなという気もしていますが、いかがでしょうか。
そうそう、Rackspaceでは、RubyベースのDSLを使って、ホスティングサービス業務のオートメーションをやっているといいますが、この際、JRubyではなくCRubyを採用したといいます。その理由をRackspace関係者に聞いたのですが、CRubyなら普通のUNIXのプロセスなので、問題があったときに何をすればいいのかよく分かっているし、コミュニティのサポートが分厚いからという回答でした。結局、CやPOSIX、UNIXの世界の住人ならCRubyのほうが馴染みやすいという、ある意味当たり前のことかもしれません。JRubyは起動が遅いので、スクリプティング用途には使いたくないというのもあるかもしれません。
あ、もう1つ付け加えておきます。Windowsサーバにデプロイする案件というのも世の中には少なくないようですが、この場合、JRubyが手っ取り早いというのも良く聞きます。JRuby guysの1人、チャールズ・ナッターさんは去年、JRubyのサイトにJVMを含むWindows向けバイナリインストーラを用意したら、もう圧倒的なダウンロード数でビックリしたという感想を漏らしていました。