LinkedIn は先日，パフォーマンスとスケーラビリティを理由として，同社のモバイル用バックエンドインフラを Ruby on Rails から Node.js にリプレースした。これに対して元 LinkedIn のチームメンバが，何が問題であったのか，自身の意見を表明している。
LinedIn のモバイルエンジニアリング担当ディレクタであるKiran Prasad氏は ArsTechnica に対して，LinkedIn ユーザにモバイルサービスを提供する バックエンドインフラを再検討しなければならなかった理由について説明した。モバイルアプリケーションを利用しているユーザは全体の 7～8%に過ぎないにも関わらず，Ruby on Rails で実装されたバックエンドが深刻なスケーラビリティ上の問題に悩まされていた，というのだ。
LinkedIn では適用可能な３つのソリューションを評価した – Rails/Event Machine，Python/Twisted，そして Node.js である。Prasad 氏によると，多くのメリットがあることから，最終的に Node.js が選ばれたのだという。
- 優れたパフォーマンス – いくつかのシナリオにおいて，Node.js は Rails の20倍以上高速だった。
- サーバ30台の処理をわずか３台で実行できるため，10倍以上のトラフィックを処理する余地が生まれる。
- フロントエンドの JavaScript 技術者をバックエンドコード開発に従事させることが可能になる。この結果，２つあった開発チームが１つに統合された。
LinkedIn がスケーラビリティを理由に Rails を廃棄したことには，Web 関連からさまざまな反応があった。かつて LinkedIn モバイルチームのメンバだった Ikai Lan 氏は，同社の行ったテクノロジ選択とそこで発生した問題について，物語の一部 を公開している。
私たちはスタックとして Ruby on Rails 1.2 を，配信テクノロジとして Mongrel を選択しました。2008 年のことです。Mongrel は当時最先端の Ruby テクノロジでした。Phusion Passenger はまだリリースされていませんでした (これについては後述します) し，Mongrel は FastCGI よりはるかに先行していました。Mongrel の問題ですか？ シングルスレッドであることです。CPU 効率よりも早期にリリースすることのコストが重要だったのではないかと思います。気持ちは分からなくもないですが。... 私たちは Capistrano を使ってデプロイしました。これは nginx の最初の実用例でもありました。 ...
[その後] Rails 2.x+ にアップデートして ... ああ，そうでした，iPhone クライアントを認証するために OAuth を使うと決めたのです。3-legged OAuthですね。それで Rails サーバを OAuth プロバイダにしました。3-legged OAuth を使用した理由ですか？単に他のアイデアがなかったからです。それは認めます。
モバイルサービスに割り当てられたサーバは Joyent でホストされていた。そのため，モバイルアプリケーションの情報が必要な場合には，要求はまず Joyent に達した後に，メインの API サービスが配置されている LinkedIn のデータセンタに転送される必要があったのだ。Lan 氏によれば，
データセンタを跨いだリクエスト，という訳です。シングルスレッドで Rails サーバ (リクエスト毎にプロセス全体がブロックされます) を稼働させて，Mongrel を稼働させて，メモリはリークし放題でした (主な原因は gettext です)。Rails サーバは翻訳や XML から JSON への変換など，いくつかの処理をしていました。他にも，新しいモバイル専用機能のテストなどもありましたが，それ以上多くのことを行った訳ではありません。プロキシよりちょっと重い，という程度です。プロキシの最大並行処理数を決定する要因は，シングルスレッドの Mongrel サーバの実行数にありました。親しみを込めて The Mongrels と呼んでいたのですが，時にはそれぞれが 300MB の RAM を消費するまで肥大化していました。ですので，それほど多くを実行することはできなかったのです。
問題をいくつか指摘した後に Lan 氏は，最終的に "v8 がとんでもなく早い" ことを認めながらも，"次世代の技術として node.js の使用が必須である，とは言い切れません。" と付け加えた。"モバイルサーバで実行しなければならなかった処理に関して言えば，Ruby on Rails より適切であったことは事実です。しかしパフォーマンスの万能薬ではないのです。下位レベルのサーバとフルスタックの Web フレームワークの比較なのです。"
Hacker News では，Rails から Node.js に置き換えた今回の決定についての 意見のスレッド が長々と続いている。