【クラウドコンピューティング】 RDBをクラウドに載せるべきか

グーグルはリレーショナルデータベースをクラウドに乗せるかというおもしろい記事を見つけた。ビジネスアプリケーションを載せてもらうことを本気で考えているのであればAzureのようにGoogleもRDBを載せるんじゃないかと。

コメント欄には次のようにあった。

RDBを実装するということが、ACID対応バッチリなミッションクリティカルなデータをホストするということであれば、それはやらないんじゃないかという気がします。

それに対して、

これ、異なる二つの方向性が同時に考えられる話だと思います。

「クラウド」の概念は漠然としていますが、方向として

1.ひとつのサーバーに載らないほどの超巨大データテーブルを、分散コンピューターで扱う
2.互いは独立した個別DBを仮想化されたサーバー環境でホストする

前者は、BigTable など、Googleの方向性で、処理場のキーは、個別操作での並列製を失わないためのMap/Reduce 的な仕組み
後者は実は、可用性に配慮しつつ増大するサーバーパワーを背景にパーティショニングを進め、ホスティングコストを低減させること。つまり、ディスクリートなDBの集合を単一環境で複数走らせて並列性を上げること。

おそらく、Azure で考えられているのは、後者の方向なので、一貫性などへの処理も個別には局在化できることで、実装にそれほど困難はないとおもいます。
また、ビジネスで必要とされるDBはかつては巨大とされたものでも、高々テラバイトです。単一サーバーに収まらないサイズではありません。また、局所分散環境(マルチコア)での、性能のリニアさを向上させる　Transactional Memory などの技術も出てきています。

一方、超巨大テーブルでの一貫性処理に関しては、レイテンシーという大きな壁があり、並列性を大きく低下させる可能性があります。また、ニーズもそれほど明らかではありません。

おそらく、両者は組み合わされて使われるのではないかと思います。この観点から言えばGoogleが実装することにもそれほどの困難さは無いと思います。

すばらしい意見なのだが後者の論理には重要な点が見過ごされているのではないかと感じる。
それは以下の4点だ。

　１．ビジネスアプリが動作する条件としてハイエンドなマシン（マルチコア構成でメモリも十分なもの）が要求されていたとするとクラウド側でも単一サーバーとして同等以上の能力を用意する必要があるのではないか。
　２．マルチコアのサチュレーションを考慮するとTransactional Memory を使っても向上に限界があるのではないか。また、（特にアプリの）アーキテクチャー変更が必要になるのではないか。
　３．組み合わせて使用した場合、BigTableでの一貫性処理に関するレイテンシーの壁は、その上で動作するRDBも免れないのではないか。
　４．そもそも、ムーアの法則が成り立たなくなった現在において「可用性に配慮しつつ増大するサーバーパワー」なんて幻想なんじゃなかろうか。

「互いは独立した個別DBを仮想化されたサーバー環境でホストする」ことは別に難しい技術ではないが、高々とはいえテラバイトのデータをVMを使って簡単にはホスティングできないだろう。これまでのビジネスアプリは、Scale-upによるアーキテクチャのもとで進化してきた。少なくともVMの1区画は、これまで単一サーバーで出していたパフォーマンスと同等以上の能力が必要となるのではないか。そうなると高価なサーバ構成をとらざるを得なくなる。安価なサーバを使うためには、Scale-outアーキテクチャへの変更が必要となるが、「ACID対応バッチリなミッションクリティカルなデータをホストする」ためのRDBを使っている限りScale-Out変更は望めない。
　たしかにビジネスアプリにとってRDBは非常に重要である。しかしクラウドに載せるのは簡単ではないだろうと私は思う。