ビジネス分野でのRubyの利用が徐々に増えてきている昨今ですが、
Ruby採用のきっかけは"志の一致"
- Q： まず、
御社のシステム開発にRubyを導入することになった経緯を教えていただけますか。 A： 主なきっかけは2つあります。ひとつは、
2006年下期あたりから楽天技術研究所 （楽天技研） の活動を本格化させようという動きが社内でありまして、 その中で、 どういったことをやっていくか、 まつもとさん [1] とディスカッションを行ったんです。 楽天側としては、
これから国際展開を強めていくうえで、 「日本発の技術で世界へチャレンジする」 というまつもとさんの姿勢に弊社の三木谷 [2] が強く共感するものを持っていたようです。一方でまつもとさんからしても、 日本を元気にしようという弊社の姿勢に共感してくれたそうで、 両者の志に共通するものがあったんですね。 もうひとつのきっかけは、
当時ちょうどRails の人気がではじめたころで、 弊社のエンジニアからもRails を使いたいという声が多数挙がっていました。前述のまつもとさんとの関係もあり、 それならRubyを使って実験的に何かサービスを作ってみようということになったんです。その話がまとまったのが2006年11月で、 2007年3月に最初のサービスをリリースしました。 - Q： その試験期間では、
どういう点を重視してRubyの検証を行ったのでしょうか。 A： ポイントは4つあります。1つは生産性です。弊社の場合はPHPかJavaでの開発がメインですので、
その2つの言語については共通ライブラリなどがたくさん作られていました。そういう過去の資産やノウハウを利用できるぶん、 開発効率では有利なんです。ですので、 Rubyでも同じようにできるかというのが1点。 2つめはセキュリティです。Rails で開発した場合、
本当にテスト段階でセキュリティホールやバグを発見できるのか、 と。 3つめはパフォーマンス。Rails がどの程度の規模のシステムまで耐えられるのか未知数だったので、
やはりこの点は懸念がありました。 4つめは運用管理面の問題です。社内で使っているさまざまな運用監視ツールが、
Railsで作ったサービスに対応できるかどうか。もし対応できない場合、 専用のツールを作らなければならないので、 運用面で不便が生じてしまいます。 - Q： 検証の結果、
4つのポイントは無事通過できましたか。 A： 生産性については、
一応の目安として工数とソースコード量の比較を挙げています。これは、 およそ1. 3倍効率が上がったと当時は言われていました。 セキュリティについては外部の監査を無事通過しています。その際にも、
Rails だからという理由でのマイナスな要素は特に見つかっていません。 パフォーマンスについては、
トランザクションしだいなので一概に評価するのは難しいですね。ただ、 最初に実験的に開発したサービスもそれなりにトランザクションは多かったんですけど、 特に問題にはなりませんでした。今では日に200万とか、 多いものだと600万くらいのトランザクションが発生するシステムで使っていますが、 すべて問題なく稼動しています。 運用管理については、
当時の段階ではまだ機が熟してくるのを待つ段階だという判断でした。一応社内のツールでも対応できないことはなかったんですが、 まだ不十分だということで。 全体としてはRubyでいけるという手応えを得たので、
社内向けの共通ツールを開発するチームを設けるなど、 本格利用に向けた取り組みをスタートさせました。 - Q： 現在、
御社のサービスの中では何％くらいがRubyで作られているんでしょうか。 A： おおよそですが、
5％くらいですかね。Javaが40％、 PHPが40％で、 ほかにもいろいろな言語を使っているので、 それが残りの15％くらいといった感じです。 - Q： 御社で開発に使用する言語として満たすべき要件みたいなものは決まっているのでしょうか。
A： 特にこれという明確なものはないです。弊社の場合、
基本的には技術をセレクトする主導権がエンジニアにあるんですよ。ですので、 まず開発者が使いたいと思っていることが大前提ですね。 というのも、
インターネットサービスというのは一度作ってそれで終わりというわけではないじゃないですか。リリースしたあとにも、 サービスの成長やユーザのニーズなどに合わせて保守していかなきゃならない。弊社の考え方は 「サービスを作る」 ではなく 「サービスを育てる」 ですので、 ちゃんと保守ができるかどうかという点が非常に重要です。だから、 エンジニアが保守したいと思う言語が一番適切なんです。 その中で、
規模が大きいものや社内での利用が増えたものなどについては、 共通ライブラリなどを作って生産性を上げるようにしています。結局、 どんな技術が適しているかというのはエンジニアが一番よく知っているんですよ。プログラミング言語にしても、 言語ごとの特性をよくわかってますから。 - Q： 実際にRubyを導入してみての社内での反応はいかがでしたか。
A： もともとRuby使いたいという要望が多かったので、
仕事で使えてうれしいという声はよく聞きますね。 それから、
2007年というのは楽天の創業10周年にあたるんですね。それで開発の現場でも、 10年の節目に何か新しいことをやりたいという機運が高まっていました。新しい言語を取り入れてチャレンジしよう、 と。結果として、 自分たちで始めたプロジェクトがうまくいったので、 大きな自信につながったと思います。
大規模サービスでも問題なく稼動中
- Q： 現在、
具体的にはどういったサービスの開発にRubyを利用しているのでしょうか。 A： 社外的に情報がオープンになっているものとしては
『my Rakuten』 があります。このサービスは毎日200万のアクセスがありますが、 問題なく稼動しています。あと、 サービス名は公開できないのですが、 前述のように毎日600万アクセスという規模のサービスにもRailsが導入されています。 そのほかには、
サービスの内部ツールでRails を利用しているケースもあります。たとえば、 あるサービスでは画面編集ツールをRails で開発しました。CSVファイルを画面にドロップすると、 テンプレートに基づいてHTML ファイルとRSSファイルを出力するといったものです。このツールはページの更新作業を大幅に短縮するのに役立っています。 - Q： 確かに、
そういったツールをサクッと作れてしまうのがRails の強みですよね。my Rakutenなどはかなりサービスの規模も大きいと思いますが、 Rails を使うことで問題になった点などはありましたか。 A： 技術的な部分で困ったことは、
これといって特に思い当たりません。ただ、 これは弊社だけでなく一般的な話になりますけど、 世の中にRails を使いこなせている人は、 実はそれほど多くはないんですよね。前職で使っていたという人はほとんどいません。ですので、 そういった人材の確保という問題はあると思います。 - Q： パフォーマンスの面ではどうでしょうか。
A： パフォーマンスも当然ベンチマークで要件をクリアできていることを確認していましたし、
実稼動後も特に問題になったことはないです。興味深い点としては、 RailsとCakePHPを比べたところ、 高負荷時にはRails のほうが大幅に応答性能が高いという結果が出たことですね。これは200リクエスト/秒くらいからPHPの応答性能が急激に下がるのが原因です。Rubyはそれほど大きくはパフォーマンスが落ちないんです。 それからRailsのほうがCPU使用率が低いという結果も得られています。ですので、
Rails のパフォーマンスに関してはまだまだ限界を引き出していない、 まだまだ余裕があるなと思っています。 - Q： 今後もっとアクセスが増えたとしても対応できる、
ということでしょうか。 A： そうですね。ただ、
楽天の場合は大規模といってもトランザクションが多いという意味なんですよね。ですので、 ボトルネックになるのはほとんどがデータベース部分で、 フロントの言語はそれほど影響しないという面もあると思います。 言語としてはまだまだ余裕がありますし、
今のところはCPUのほうが先にネックになるという感触です。そしてそれ以上にネックになるのがデータベースです。 - Q： お話を伺う限り、
大規模サービスでも拍子抜けするほどすんなりとRubyを導入できたという印象を受けます。だとすると、 Rubyのパフォーマンスに対する不安の声はどういった部分から生まれているのだと思いますか。 A： うちで使っているケースで言えば、
画像解析などのツールはC言語で書いた場合に比べて格段に遅いです。当然だとも言えますけど、 そういう処理系自身のパフォーマンスではやはりC言語などに分がありますよね。ただ、 それがシステムとしてのパフォーマンスに影響するかというと、 必ずしもそういうわけではないということです。
分散環境をサポートする『ROMA』と『Fairy』
- Q： 大規模システムへの対応については、
楽天でもRubyコミュニティと協力しながら大量データの処理という観点から 「ROMA」 「Fairy」 といったプロジェクトを進めていますよね。これらの試みがスタートした経緯について教えてください。 A： 最初はまつもとさんから提案があったんです。大量のデータを処理するミドルウェアやフレームワークを、
Rubyでも持つべきなんじゃないか、 という。それを代わりにやってくれる人はいないか、 という話でした。 一方で楽天技研としても、
当時抱えていたテーマのひとつに大規模分散処理というものがありました。そこで2007年5月にまつもとさんを研究所のフェローに迎えて立ち上がったのが 「ROMA」 と 「Fairy」 です。 - Q： 現在の進行状況はどのような具合でしょうか。
A： ROMAについては2009年の8月に正式リリースしていて、
10月にはオープンソース化もしました。現在ではすでに楽天社内のいろいろな事業で使われていますし、 オープンソースになっているので社外でも使われ始めているのではないかと思います。 Fairyのほうも、
限定的ではありますが一部のサービスにすでに導入されています。こちらはまだオープンソースにはなっていませんが、 近い将来オープンソース化する予定です。 - Q： これらのプロジェクトを進める中で、
特に問題になったことなどはありましたか。 A： 問題というわけではないのですが、
ちょうどROMAで採用しているKeyvalueストアのブームが来て、 類似の競合システムがたくさん生まれました。その中でROMAのオリジナリティを出すことには特に頭を使いましたね。 たとえば冗長性を高めるか、
パフォーマンスを優先するかという話では、 ROMAは両方とも維持する姿勢を取りました。また耐障害性が高いというのもROMAの強みと言えますね。 「ホットスケール」 というしくみで無停止でノードを追加できますし、 バージョンアップも無停止で行うことができます。 - Q： Rubyならではという機能はありますか。
A： ホットデプロイのプラグイン機構はRubyならではと言えますね。この機能のおかげで、
ROMAでは運用向けのプラグインなども無停止で追加できるのですが、 これはRubyの動的拡張性があってこそ実現できたものです。 このプラグイン機構を持っていることで、
ROMAは要件の異なるさまざまなケースに柔軟に対応できます。楽天の場合、 事業やサービスごとにシステムの要件が大きく異なっているので、 そういう立ち位置にROMAはぴったりとハマったと思います。
動的言語としての価値は大きい
- Q： 御社の中でのRubyの利用率は5％ほどだとのお話でしたが、
これからも増えていくと思われますか。 A： 流行などもあるのでなかなか読めない部分もありますね。ただ、
あくまでも感覚的にというところですが、 今までPHPで作っていた部分をRailsに置き換えるケースが増えてくるんじゃないかという気配はあります。たとえばロジックを作り込もうとしたときなどは、 PHPよりもRubyのほうが可読性がいいんですよね。これまでのコード量であればPHPでよかったかもしれませんが、 今後より複雑になった場合にどうするか。実際、 そういう理由でRubyやほかの言語にリプレースされたケースはあります。 - Q： 逆に、
Rubyを試してみて採用を諦めたというようなケースはありましたか。 A： それは特にないんですけど、
実はROMAなどは、 構想の段階では最終的にRubyではなくなるだろうって言われてたんですよ。パフォーマンスが出ないだろうから、 プロトタイプの実装はRubyでやって、 現実的にはほかの処理系を入れて最適化していくことになるんじゃないか、 と。それが最後までPure Rubyでいけてしまったというのは、 逆の意味で驚きでした。 それから、
今試験稼動させている分散ファイルシステムについても当初Rubyでやろうという話があったんですけど、 これは結局Erlangが採用されました。理由は、 Erlangのほうがマルチスレッドプログラミングが比較的容易だからです。システム上どうしてもマルチスレッドを使う必要があったので、 そこで変なバグに嵌は まらないように。実際、 ROMAやFairyでもマルチスレッドが問題になったことはありました。 - Q： 今後、
楽天としてRubyに関連して何らかのアクションを起こすような計画はありますか。 A： Fairy のオープンソース化など課題は残っていますが、
そのほかの新しい活動についてはエンジニアしだいと言えます。先ほども言ったように楽天の場合は使う技術を選ぶイニシアチブがエンジニア側にあるので、 その点で会社全体としてのコンセンサスのようなものは強くはないんです。ただRubyをガンガン使いたいというエンジニアは確かに増えているので、 そういう人たちが個人でコミュニティに参加して積極的に活動するという動きはあるかもしれません。 - Q： 楽しみですね。最後に、
Rubyのエンジニアや、 これからRubyを採用しようと考えている企業に対してに何かメッセージをいただけますか。 A： ROMAをやっていて実感したことなんですけど、
そうやってRubyでなければできないことを意識して、Rubyは何よりも動的言語としての価値が大きいということです。特にこれからのクラウド時代には拡張可能性というものが非常に重要になります。そのときに動的言語という点は非常に大きなアドバンテージになるはず。 実現していくことが大切だと思います。
―ありがとうございました。