Don'tStopMusic

_ [Rails] Ruby on Railsのスケーラビリティ強化製品、続々？

Ruby on Railsのスケーラビリティ強化製品、続々 − ＠ITという翻訳記事がありました。どうも雑多な記事ですがちょっと読んでみます。

その生産性に開発者から全幅の信頼を寄せられているRuby on Railsだが、人気の高いこのWebプラットフォームに対しては、高負荷に対応するスケーラビリティが低いという批判の声も多く出ている。そのような中で、単にRailsとも呼ばれるRuby on Railsの可用性を高めようと、一部の新興企業が事業を展開している。

Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT

ということで、Rails は生産性は高いがスケーラビリティが不足しているという問題があり、それを解決しようとするベンチャー企業が現れ始めているという内容です。

こと日本では「Rails はスケーラビリティが不足している」という認識はもっぱら twitter によってもたらされている気がしますが、

最近は多数のエンタープライズアプリケーションにも採用され始めた。だが、相応の成功を収めているにもかかわらず、Railsを使った開発プロジェクトはエンタープライズスケーラビリティの理想形を95％までは具現化できるのに、負荷の大きい環境でアプリケーションを使用するにはほかの言語の力を借りなければならないという苦言も、しばしば聞こえてくる。

Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT

ということで、エンタープライズ分野での採用も進んでおり、そこで問題となっているようです。とはいえ、昔 Martin Fowler が Martin Fowler's Bliki in Japanese - エンタープライズRails で言ってたように Rails の「コア機能」はエンタープライズ向けというわけではなくて、plugin など周辺で補おうという考えですから、一口で「エンタープライズアプリケーション」と言っても分野は限られていると思いますが。具体例がほしいですね。

負荷の大きい環境でアプリケーションを使用するにはほかの言語の力を借りなければならない というのは、この間の「twitter が Rails 使うの止めるよ騒動」で Evan Williams が言った「twitter はすでに多くのコードがRailsではない」を思い起こさせます。

Ruby は、速度が要求される部分は C で書いて拡張ライブラリにしちゃえという技が比較的容易なので、ほかの言語の力を借りて済むならそれでいいのではと思います。ただ、ボトルネックが Rails そのものにあった場合には、Rails のようなフルスタックのフレームワークのボトルネック部分だけ C で書き直すというのも現実的とはいえないですね。Ruby 処理系や Rails に手を入れられないという前提ならアプリのロジックやアプリケーションサーバ（apache/lighty/mongrel/thin）、物理サーバでパフォーマンスの確保やスケーリングさせないといけないことになります。

で、スケール問題に対するソリューションの一つ目として紹介されているのが New Relic です。

New Relicがサブスクリプション形式で販売するRailsパフォーマンス管理ソリューション「RPM」は、開発者によるリアルタイムでのアプリケーションパフォーマンス問題検出、診断、修復を迅速に、かつ低コストで実現すると、New Relicは説明している。同SaaS（Software as a Service）は現在、限定的な顧客にプライベートベータ版として配布されているが、間もなくRuby on Railsコミュニティ全体に向けた一般提供が始まる見込みだ。

Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT

ということですが、この説明ではよく分からないので、TechCrunch Japanese アーカイブ » New Relic、Ruby on Railsアプリのパフォーマンス・モニタ開発へを読むのがいいでしょう。

稼動中の Rails アプリのパフォーマンスモニタリングをして、ボトルネックを発見できるサービスですね。「Hoge コントローラの foo アクションが遅い」といったことが一目で分かるので、そういったボトルネックを解消していくことでパフォーマンスの問題を解決できると。まあ、「スケーラビリティ強化」に対する直球の回答ではないですけれども。

MySQL のエンタープライズ版は、MySQL Enterprize Monitor というツールが利用できます。MySQL サーバの稼動状況を多くの項目で網羅的に監視できたり、最適な設定を提案してくれたりします。

New Relic や（いずれ現れるかもしれない）その競合が育てば「Rails Enterprize Edition」のようなサポート付きのサービスというのも生まれるんじゃないかと思います。特に日本では金払ってサポートしてもらうのが好まれますけど、NaCl や CTC あたりがやったりしないですかね。

New Relicは、30〜60日以内に新製品をリリースするという。同社のプライベートベータプログラムには約50社の顧客が参加しており、各社は同製品を利用してRailsアプリケーションのスケーラビリティ向上に役立てている。同社はさらに、RPMの実働用バージョンを補完する開発者向けのソリューションを提供する予定

Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT

蓄積されるノウハウがコミュニティに還元されると嬉しいですね。Rails Conf でセッションするとかで。

さて次に紹介されているソリューション？はプラットフォームです。

Rails実装プラットフォームプロバイダのEngine Yardは4月29日、先日リリースされた、分散化バージョン管理システムの「GitHub」サービスと、人気の高いバグ追跡アプリケーション「Lighthouse」をサポートすることを明らかにした。Engine Yardのスケーラビリティの高いプラットフォーム上でGitHubおよびLighthouseをホスティングし、Rails開発者のソースコードとチケットトラッキングの両方を安全に使用できるようにすると、同社は述べている。

Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT

Engine Yard は Rails が稼動するサーバを提供するサービスをしているところです。詳細は例によって、TechCrunch Japanese アーカイブ » Benchmark、Ruby on Railsに賭ける―「Engine Yard」に$3.5Mを投資を参照ください。New Relic も Engine Yard も同じ Benchmark が投資しているんですね。Rails に期待しているのかな。しかし、Engine Yard は別に「スケーラビリティ強化製品」じゃあないですね。

続けて読んでいくと、

Engine Yardの最高技術責任者を務めるトム・モーニニ氏は、eWEEKに対し次のように語っている。

「Railsのスケーラビリティに根本的な問題はないと、われわれは考えている。それでもこの点を批判する人々は、効率性とスケーラビリティを混同しているのだろう。RubyとRailsは、ランタイムにおける効率性こそ従来のプラットフォームに劣るが、これはほかの新しい開発プラットフォームすべてに言えることだ。Javaも登場した当時はひどく遅く感じられたのを思い出してほしい。Rubiniusなどの新たなRubyランタイムは、ネイティブコード生成といった、Javaでも多用されているのと同じ最適化技術を採用しており、効率性の向上を実現してくれる。現在われわれは、一月あたり数百万人ものユニークビジターが使用するRailsアプリケーションを、わずか数台の最新サーバ上で運用しており、ビジター数が数千万人になっても、将来的に数億人になっても大丈夫だという自信を持っている」（モーニニ氏）

Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT

なんとスケーラビリティ問題はないということです。ただ、Java を引き合いに出している件を注意深く読むと、「問題はないが気にする人も今後はより良くなるので心配しなくて良い」という読み方と、「サービスを提供している以上問題があるとはいえないが、やはりこの辺が良くなってほしい」という穿った読み方がありそうです。どちらにしても改善すべき点は存在するわけですね。JVM の進化と同様の進化が Ruby にも必要ということなのでしょう。

Ruby1.9(YARV)、JRuby、Rubinius、MagLev と VM ベースの Ruby 処理系はいくつかありますが（MagLev はまだ実物ないですが）、VM の利点として捉えられているのはやはりパフォーマンスです（今のところ Rubinius はちょっと違いますけどね）。YARV の目的はパフォーマンス向上でしたし、JRuby の Charles Nutterが事あるごとに書いているのは、Java とのシナジー効果などというものではなくパフォーマンスです。MagLev もインタビュー記事ではスケーラブルというキーワードでパフォーマンスについて語っています。

Ruby 処理系のパフォーマンス競争で現時点で先頭にいるのは Ruby1.9 ですが JRuby が急速に迫りつつあります。将来的にはいずれかの処理系が、ハードウェア性能を勘案した相対的な速度では、現在の Java に追いつくかもしれません。でも、それまではやはりパフォーマンスが「問題」として取り上げられ続けるのでしょう。

元記事最後の DHH 御大の台詞については割愛。

ところで、Ruby on Railsのスケーラビリティ強化製品、続々 − ＠ITですが、結局「スケーラビリティ強化製品」なるものは、せいぜい New Relic の RPM くらいしか上げられてないですね。続々というのは一体なんだったのでしょう……原題は「Making Ruby on Rails Scale」なので単なる誤訳というのが結論？