JRuby on Rails は無理かもしれんね、という話

2018-01-20 23:00

アボストラクト

そもそもなんで今さら Jruby の話をするねん、って話だけど、Rails の Rack サーバーの Puma においてアムダールの法則を考えると、マルチスレッドをフルに活かせる JRuby on Rails には一日の長があるため活用したかったのだが、一月以上のリサーチの結果、なかなか使うのは難しいという結論に至ったので今回 記事を投稿することにした。

JRuby を Rails で使おうとすると何が問題なのか?

  • コンパイルの時間がかかることにより、思考が妨げられる
  • JVM の性格だと思うが、CPU のリソースを CRuby よりも消費する
  • Gem 類の世代が数年遅れ
  • エラー情報が JVM のものなのか、Rails のものなのかがわかりにくい
  • ByeBug という Gem が使用できないため、デバッグが困難

過去

  • Tomcat のような .war ファイルを JRuby on Rails で書き出すことができたため、Ruby をインストールするのが諸事情で難しかった 10 年前の時代ではメリットがあった
  • また CRuby も 1.9 未満の世代では速度に不満がある人も多かったため、JRuby で開発することにも今以上にメリットがあった

現在

  • JVM においてマルチスレッドを活用できる Puma といった Rack サーバーがある現在、相変わらず性能は CRuby のそれよりもアドバンテージがあるが、いまやメリットはコレぐらいか
  • CRuby で使える Gem 群たちが、例えば ByeBug といったのが、利用できないことがある
  • Rails 5.2 が出てきそうな今でおいても、PostgreSQL 版の ActiveRecord は Rails 5.0 世代に対応するのがやっとで、タイムラグが2年ほどある。
  • CRuby に対して JRuby はコンパイルに時間がかかり、更には消費する CPU リソースも高い
  • Docker や Vagrant のように開発環境と実行環境の差異を抑える事が可能となった今、JVM 上で利用する Ruby 環境におけるメリットが薄れてきた
  • JRuby を大々的に利用している企業がそれほどないため、なかなか発展するのが困難
  • そもそも Ruby が PHP には優位に立てたが、Python や JavaScript には後手にまわっている、という話は関係ないか

未来

いつの日か使うことになるであろう (C)Ruby 3 には JRuby もアドバンテージである JIT やネイティブにマルチスレッドを利用できる予定という話なので、(C)Ruby 3 が出るであろう 2020年には JRuby on Rails のメリットもかなり薄れるだろう。また OSS である JRuby の開発者たちのモチベーションがいつまで持つのか不明というのも不安要素である。

まとめ

かつて JVM のメリットとされた ‘Write once, run anywhere’ というメリットも Vagrant や Docker といった仮想環境や、Go言語のように多種の環境に対応したバイナリを吐き出せるコンパイラが出てきた今、それほど JRuby に対するメリットを感じるのが難しくなってきたような気がする。もちろん JRuby のメリットが Embulk のような商用で利用されているのを考えると、これからも JRuby が有用ではあるだろうが、個人的に Ruby は最新の機能を活用したいので、CRuby をメインに使い、性能上の理由で JRuby を使いたい場合には他の言語を選択するだろう。なので多分よっぽどのことがないかぎり、Ruby on Rails を活用する場合には CRuby を使うと思う。

関連記事