楽天テクノロジーカンファレンス2007という催しがあったようです。
＠ITの記事によると

2007年11月24日、「楽天テクノロジーカンファレンス2007」において、Ruby言語の開発者で楽天技術研究所フェローのまつもとゆきひろ氏は、開発中の大規模分散処理基盤「Roma」（ローマ）と「Fairy」（フェアリー）のコンセプトを語った。研究段階ではあるものの、米グーグルなど世界トップクラスのネット企業だけが持つ大規模分散処理技術に真っ向から挑戦する試みだ。
(中略)
Romaの応用として、巨大セッションを保持するコンテキスト基盤などを考えている。Romaの技術的な位置づけは、米グーグルの「GFS」（Google File System）、米ヤフーの「Hadoop」（ハドゥープ）、米オラクルの「Coherence」（コヒーレンス）、米アマゾンの「Dynamo」（ダイナモ）など大規模分散ストレージ技術と似ている。楽天技術研究所代表の森正弥氏によれば「特にDynamoに位置づけが近い」とのことである。
(中略)
楽天取締役常務執行役員 チーフプロデュースオフィサー開発・編成統括本部長の杉原章郎氏は、カンファレンスの狙いについて「楽天のテクノロジーを知ってもらい、社内外への刺激としたい」と話す。「現在、楽天社内と協力会社を含めて1100人規模の技術者がいるが、3年後には3倍といったスケール感で数を伸ばしていきたい。当然、東京の開発者だけでは足りない。すでに全国主要都市に開発拠点を立ち上げつつあるが、海外拠点を作ることもありうる」

楽天というと、「古い・遅い・使いにくい」というイメージがあります。特に楽天ショップはいくつものアプリケーションが混在していて、キメラのようなサービスです。外部向けにAPIなどを昨年やっと公開しましたが、いまだに楽天ポイントなどの連携はCSVファイルをFTPアップするといった仕様が残っていたりと、「技術的に時代遅れな会社」という実情です。

こういったカンファレンスを開くのは、「楽天＝ネット技術のリーダ」というブランドイメージをつくるためだとおもいます。

さて、タイトルでは楽天OSとつけましたが、「Roma」は実際にはどうなのでしょうか？

プラットフォーム開発ナメンナよ！

Romaの詳細を読む前の第一印象です。
分散ストレージは、いくつもの会社がH/W、S/Wに莫大な投資をしてディスクシステムとしての信頼性とパフォーマンスを向上させています。H/W製品の開発もしたことのない会社がつくるソフトウェアアプローチの分散ストレージシステムなんてオモチャだろう・・・と常識的に考えれば一笑にふすところです。

記事内容を少し読み進めると・・・

まつもと氏は、Romaのコンセプトについて「CPUやネットワークに比べてハードディスクの速度は上がっていない。メモリ上にデータを保持し、マシンを大量にネットワーク上にばらまいたら、そちらの方が速い」と説明する。「単にメモリを分散するだけならmemcached（注：大規模Blogサイト LiveJournal.comの性能向上のために作られたオープンソースの分散キャッシュ・システム）でいいと思うかもしれないが、マシンを1000台並べ、そのうち1台が壊れても止まらない信頼性と一貫性を確保することを考えると、より高度なアイデアが必要。ただしその分、実用化までには壁がありそうだ」（まつもと氏）。

Dynamoに近いシステムで上記のような仕組みを考えているそうなので、P2Pアプローチのキーとオブジェクトをペアリングできる巨大なハッシュテーブルだということがうかがえます。

かわいそうに・・・技術者の玩具に、技術をわからない経営層が踊らされている

巨大なストレージシステム(現在だと100T Byte以上)を構築する場合、一般には集約型で構築します。集約型のメリットは管理コストが安い点にあります。そのかわり、ストレージにアクセスが集中するためパフォーマンスをだすために、分散型キャッシュを導入するようになります。特に、大企業などでいろいろ地域に業務拠点をもっている場合は、ネットワークのレスポンスも配慮して、各拠点にキャッシュが保持されます。また、巨大なストレージシステムはH/Wコストは高くなりますし、導入コスト・時間などもかかります。

これに対して、パソコンは安いから、みんなのパソコンに少しずつファイルを置かせてちょうだいよというのが分散型ストレージシステムに根底にある思想です。ファイルデータを細切れにして、いろいろなパソコンに多重に配置して、一番負荷の少ないパソコンから、ファイルデータを読み出してくるという仕組みです。

これね・・・読込み(Read Aaccess)特にランダム読込みはそこそこ性能いいんだけど、書込み(Write Access)の性能がでないんですよ。理由は下記の図をみてください。

もう1点致命的な設計思想上の欠落としては、「メモリ上にデータを置いた方が早い」という点です。そりゃ、早いよ、でも全データなんてメモリに置けません。いま、一番廉価な価格帯のPCサーバだと4GByteのメモリを載せるのがコストパフォーマンスがよいですが。1000台=4T Byte用意するために2~5億円必要です。(分散サーバなので冗長性分やOS利用分を配慮しないといけませんが・・・省略します)
これに対してNECのiStorageですと、S1850ATでも16Gが最大ですが1~3000万円くらい。コスト差20倍です。

単一のアプリケーションで4TByteものファイルデータをメモリにおく需要なんてほとんどありません。もし4Tもファイルがメモリ上に展開されていないとパフォーマンスが発揮できないのだとしたらアプリケーションのアーキテクチャが悪いのです。

その中でどうしても単一のアプリケーションで巨大なファイルを利用する必要があるのがDBです。うっかりしているとDBファイルのボリュームが100GByteを超えることがあります。
おそらく、各社の分散ストレージの開発者達は、DBのファイルの利用を前提に考えているかとおもいます。そうなると、インターフェイスはファイルシステムではなく、SQLをインターフェイスにした、分散DBシステムをつくったほうが需要があります。

この場合、完全なシンメトリっくなシステムにするのではなく、クエリのコンパイルスケジューリングをするノード、インデックスを管理するノードと、データエンティティを管理するノードを別のグループとして設定し、ノードのキャッシュデータを局所的に同期するような工夫があるとすごくうれしいですね。懸念としては、行ロック情報の同期負荷を軽減するために、ロックエスカレーションがおきやすくなるのではないかという点です。

DBは既存品を使ってファイルシステムレイヤーのソフトウェアの工夫だけでDBのパフォーマンスを向上させることができれば大変素晴らしいのですが、DBの場合Insert、Updateのコミットデータのキャッシュ同期だけでシステム全体をブロックしてしまうので、分散ストレージは読み込みのためにしか機能しません。それだったら、DBレプリケーションをしっかり設計した方がシステムとしてはずっと安定性が高いというものです。

開発者の方は反論あるでしょう、GoogleのGFSという実績もあります。
ですが、Romaというシステムが楽天のメインストリームサービスで利用されることはないと予測します。

たんなるブランド形成なんでしょうねー。でも楽天の迷走感のほうが表にでてるなぁ・・・。