Rubyはどこまで大規模な基幹システムに適用できるか---この問いに対する答えを探す，あるいは作る試みが動き出している。
Rubyを大規模システムへ適用しようという原動力となっているのが，エンタープライズ・システムの生産性を向上させたいという企業の要求と，Rubyを使いたいという開発者の要望だ。「Ruby on Railsの生産性はVBscriptの倍，PHPの1.5倍ではないか」」(カカクコム 事業開発本部事業開発部システム担当部長 宮島壮洋氏)。「COBOLやVBに比べ4割から5割生産性が向上しそうだ」(テクノプロジェクト 代表取締役専務 吉岡宏氏)。
しかし，ビジネスへの本格的な適用が始まったばかりのRubyを大規模で高信頼性が要求されるシステムに適用するためには，いくつかの課題を証明，または解決する必要がある。
その課題とは何か。日本で最大規模の事例であるカカクコムの「食べログ.com」や，松江市役所の高額医療費システム開発プロジェクトから，その課題と解答を見てみよう。
大量データでの性能に苦しむ
 食べログ.com [画像のクリックで拡大表示] |
 食べログのシステム構成 [画像のクリックで拡大表示] |
 カカクコム 事業開発本部事業開発部システム担当部長 宮島壮洋氏 [画像のクリックで拡大表示] |
食べログ.comがサイトの再構築に踏み切った理由は，以前のシステムが拡張に拡張を重ねたためシステムが複雑になり，機動的にシステムの変更ができなくなっていたためだ。「ある箇所を変更すると，どこまで影響が及ぶのか把握が困難になってきていた」(カカクコム 宮島氏)。従来のシステムは2003年，Windowsサーバー上にVBscriptで開発した。「ユーザーの要望に応じてスピード優先で改良してきた」(カカクコム 食べログ.com運営責任者 村上敦浩氏)ことが食べログ成長の原動力だったが，それが難しくなってきていた。
再構築を検討したのは2007年4月ごろ。PHPとRubyが候補だった。Railsをやりたい，というエンジニアが多かったが，時期尚早ではないかという意見もあった。「しかし，楽天やTwitterがRailsを採用したと聞き，検証してみて，Rubyを適用できると決断した」(宮島氏)。
Rubyは初めてという技術者が多かったが，噂に違わず「開発のスピードはかなり速かった」(宮島氏)。食べログの画面数は約200あるが，開発に取りかかって約2カ月で完成した。「VBscriptならこの倍，PHPでも1.5倍はかかっていたのではないか」(宮島氏)。コード量も10分の1になった。VBsciptではコードを再利用する際にコピーしていたのに対し，Rubyではクラス継承により集約でき，変更の際の見通しもよくなった。
しかし，それからが苦労の始まりだった。本番の大量データで動かすと，性能が極端に低下したのだ。少量のテスト・データでの検証では起きなかった現象だった。
自動生成されたSQL文を書き換える
最大の原因は，Ruby on Railsが自動生成したSQL文だった。データベースへアクセスするためのSQL文を生成する機能はRuby on Railsの高い生産性をもたらす特徴のひとつだが，データが何十万件という巨大な規模になった時，そのままでは実用的な性能が得られなかった。「何十万件というデータを全部とってきてメモリーに載せようとする」(宮島氏)。
カカクコムは効率の悪いSQL文を書き換えていった。RailsとMySQLについてのノウハウが少なかったこともあり，この作業に1カ月半を要した。MySQLに詳しいスマートスタイルと，まつもとゆきひろ氏が在籍するネットワーク応用通信研究所に協力を依頼した。
MySQLのバグと思われる現象にも遭遇した。「MySQLの性能が急に低下した。どうやらCPUがクアッドコアで特定のOSの際に起きるバグらしく，バージョンを上げることで発生しなくなった」(宮島氏)。
これらのチューニングや対策のため，開発期間は当初予定の3カ月から6カ月に伸び，新システムの稼働は10月19日にずれこんだ。
再構築したことで「新しい機能をどんどん追加できるようになった。リニューアル前は一回の変更に数週間かかるようになっていたが，昔のように毎週新機能を追加できる」(村上氏)。カカクコムでは他のサイトにもRuby on Railsの採用を広げていきたいとしており，すでに映画情報サイトEiga.comもRailsで動いている。
