2011年4月9日土曜日

だからRubyは遅くて、という悪評のもとにならなければいいけど。

このエントリーをはてなブックマークに追加
Pocket

Ruby作者のまつもとゆきひろ氏が、こんな呟きを残すニュースが伝わってきた。

ITMediaが、Twitterが検索フロントエンドをRuby on RailsからJavaに切り替えた結果、検索結果の待ち時間が1/3になったと報じている。Twitterでは、2011年春から以下のようにシステムを改善しており、(2)から(3)への移行で速度が大幅に改善したようだ。

  1. Ruby on Rails ⇔ MySQL
  2. Ruby on Rails ⇔ Lucene(Java)
  3. Ruby on Rails ⇔ Blender(Java) ⇔ Lucene(Java)
  4. Blender(Java) ⇔ Lucene(Java) ※予定

1. RubyからJavaに乗り換えて速度向上の理由

公式ブログを見ている限り、3倍の応答速度と、10倍の同時接続が可能になった理由は、非同期I/Oに依存する所が大きいようだ。

上述のBlenderはJava/Thrift/Nettyで書かれたアプリケーションの名前だ。Blenderは、検索がリクエストされると、検索結果の構築に必要なバックエンド・サーバーへの問い合わせを複数に分割して平行実行するが、全ての通信はノンブロッキングI/Oが用いられる。

ノンブロッキングI/Oを用いると、リクエスト数が多くてもメモリ利用量を削減する事ができ、コンテキスト・スイッチを抑える事ができる。Apache 2.xなどの従来型のウェブサーバーは、プロセッサに余力があっても、スレッド生成に必要なメモリー不足が発生し、大量のリクエストを同時に処理できない(C10k問題)。ノンブロッキングI/Oを効果的に用いると、C10k問題を解決できる。

現状でノンブロッキングI/Oを実現しているのは、TomcatやJetty等のJavaアプリケーション・サーバーと、JavaScriptのnode.jsなどが知られているが、その中で既にTwitterで使われているJava/Nettyを選択したようだ。

2. Rubyは遅いの?

まつもと氏も「いや、遅いんだけど十分に速いんだよ、通常は」と言っているが、何とも言い難い感じだ。Apache 2.xの拡張モジュールとして動作している間はノンブロッキングI/Oの実現は難しいが、Ruby自体の実行速度はバージョン1.9系で大幅に改善した。

しかし、TwitterのようなC10k問題が深刻になる、大規模コンシューマ向けサービスには向かないだろうが、大半のサービスのパフォーマンスでは問題が出る事は無いはずだ。遅いと言うより、特定状況に対処しきれないと言う方が適切かも知れない。

追記(2011/4/9 12:30):RubyもEventMachineを用いる事でノンブロッキングI/Oが可能なので、RubyがC10k問題に対応できないと言うわけではない。

3. Javaの応用分野が拡大?

大規模コンシューマ向けサービスではPHPが使われる事が多かったのだが、今回のニュースでJavaの採用事例が増えるかも知れない。経験のあるプログラマの募集が容易なPHPの利用が揺らぐとは全く思えないが、C10k問題が深刻な場合はJavaの採用が増える可能性はある。

アメーバピグは、ノンブロッキングJavaアプリケーション・サーバーを独自に構築しており(Tech総研)、チャット・システムのLingrはJettyを使っていたが、標準的なTomcatでもノンブロッキングI/Oを使う事は可能だ。

ノンブロッキングI/OではJavaScriptのアプリケーション・サーバーであるnode.jsが注目されているが、Javaがデファクト・スタンダードな地位を占める可能性も少なくない。

0 コメント:

コメントを投稿