【クラウドコンピューティング】 Scaleするかどうか、それが問題だ

エンドユーザにとってクラウドデータベースで嬉しいことは何もない？


　クラウド時代のデータベースという記事には、「戯れ言を垂れ流してみます」といいつつ、本質的なことが書かれている。

key-value型のインスタンス群に対して集合操作ってのは、例えばJoSQLみたいなのもあって、いやいやそもそもデータ量がねって話に対して、でもGAEってクォータきつくないっけ？（これもよく分かってないんですけど、調査不足で書いちゃって申し訳ないです）ってことを考えると、 BigTableが使えるって言ってもほんとの意味で大量データをブン回せるわけでもないのかな、とか、いやそもそも集合操作無用でござるっていうなら、 HTMLのフォームをPOSTされたらそのままテキストファイルとして保存しちゃってLucene頑張れってほうが良くね？　とか、そもそも何だよその「明細」ってスキーマ（クラスでもテーブルでもエンティティでも呼び名はどーでもいいけどさ）はよぉ、とか色々と思うのです。

クラウドデータベースといえばBigTableでkey/valueである。たしかに、エンドユーザからみれば、実際のところクォータがきつく大量データが使えるわけでもない。JOINすらままならないkey/value操作で何かよいことがあるわけでもない。クラウドデータベースって一体何が嬉しいのか、まったくもってわからない、となる。

Google側のメリット


　ところが、クラウドを提供する側であるgoogleの視点で考えると話はがらっと変わってくる。大幅な運用コスト削減のため、googleは、マシンの台数やN/W、ハードディスク容量などの物理リソース各ユーザごとに管理することはしない。１つの論理的な大規模なマシンを管理するだけである。そしてそれをエンドユーザに開放し、彼ら自身の手によるリソースの割り当てを可能にしている。

なぜBASEなのか


　このような論理的に大規模なマシンに必要なのはBASEを元にしたScale-outの仕組み。これまでのデータベースのプログラミングは小規模なACIDの世界で十分であったが、クラウドのプログラミングではBASEという別の世界で動作する。BASEは分散処理技術を元にしたScaleする世界の概念である。
　Googleは、つまり、ScaleさせたいからACIDをやめてBASEにした。それがBigTableでありkey/valueになってしまう理由である。

BASEについて、M先生曰く。

Cloud上のデータベースでは、従来のACID ConsistencyをBASE Consistencyに切り替えようという話があります。ACIDは、たいていの人知っていると思いますが、BASEは、Basically Available, Soft state, Eventually consistentの略ですね。

eBayのDan Pritchettという人の、BASE -- An ASID Alternative という論文です。

彼、面白いです。理論的だけど実践的で。

頭固くしていると、BASEは、「Basicallyが気に食わない」とか、「Softってなんだ」とか、「Eventuallyじゃどうしようもない」と、Initialごとに反発しそうですが、多分、BASE概念、重要です。

ACIDが理想的で、BASEは、何か欠けているものと考えるのは、おそらく間違いです。古典論が、量子論をなかなか受け入れなかったのも、それが統計的にしか未来を予言できないことが、心理的な障壁になりました。

ACIDは、小規模システムの局所的な原理で、Scaleしません。BASEは、大規模システムの原理です。局所的には、ACIDの成り立っている領域を、大域的に接続していくと、システム全体としてはBASEなシステムが出来上がると考えればいいんじゃないのかしら。

ACIDを諦めるというトレードオフ


　ではなぜ、小規模システムのACID原理が大規模システムに通用しないのか。それは、「それぞれの段階を通り抜ける際、我々は、何かを失う」とした、「複雑さにおける基本的な飛躍」に答えを見出すことができる。ScalabilityとAvailabilityのP18

　CORBAの失敗は単なるインターオペラビリティの問題だけではなかった。もしそうであるならSOAPで成功しているはずである。密結合のモデルをそのままインターネットに適用しようとしたことが失敗の原因であったのだ。同様のことがクラウドでもいえる。インターネットのような大規模システムでは「信頼できないマルチマシン」を前提とした新たな原理を適用しなければならないのである。

　信頼できないマルチ・マシンたちへ：誰を信ずることが出来るか分からない難しい状況の中で、我々は信頼を失う。


なぜScale-Outしなければならないのか


　クラウドデータベースは、先に述べたように、ユーザから見たときは、自由にJOINできないなど、時代に逆行しているかのような機能の少なさや不便さを感じてしまう。その不便さに耐え切れず、エンドユーザの強い要求に屈したのがMSのAzureである。結局、エンドユーザの人数分のSQLServerを用意すればいいじゃん、ということをやってしまうのだろうが、そうなると管理運用コストがかさばってくるのは明らかだ。まあ、これはこれでScaleするといえなくもないが、客のデータセンターをMSのクラウドに移動しただけと実質的にはかわらない。

なぜScale-Outしなければならないのか。その第一の理由は、大規模なデータを扱う際にも、パフォーマンスが落ちないないからである。

　エンドユーザには完全なSQLを提供しつつ、内部的にはBASEだなんてものを出してきたら話は別だ。そりゃすごいことだが、「複雑さにおける基本的な飛躍」でも説明したように、これはとても難しいと思う。SQLは最高なんだけれども、ACIDである限りScaleしない。ACIDシステムを使っている限り、データ量増大に起因するパフォーマンス劣化に対しての抜本的な解決策はないと今は考えられているので、増え続ける顧客データに対して、いつまでも耐えられるものではない。
　（２年前に構築したECサイトも実際問題としてデータ量に起因するパフォーマンス劣化を起こしている。どんなにデータ量が増えても未来永劫サクサク動くシステムはできないものか。それが私がクラウドに魅せられる要素のひとつである）

　これに対してGoogleでは、ある一定量以上になると課金されるものの、基本はBigTableであるからスケーラビリティはまったく問題ない。アプリも同様に我慢してGQLを使う限りにおいては理論的に無限の顧客データに対応でき、パフォーマンスを落とさずにスケールできる。
　ただし、我慢しきれずにGAE上にDerbyなどのJavaRDBを載せてしまうと、せっかくのスケーラビリティは崩れ、AzureSDSのSQLServerと同様の問題に直面することだろう。パフォーマンスに問題ないからといって安易にRDB化するのは問題を抱えてしまうことになるので要注意である。パフォーマンスに問題がなく、かつ、データ量がそれほどない場合に限り、JavaRDBを使うという選択肢も使えると思うが、いずれにしても何とかGQLを使って頑張るべきだと私は思う。

第二の理由は、前記事でも述べたように、コストメリットであると思う。BASEによる大規模システムを、コモディティサーバ、OSS、広告モデルといった組み合わせによって実現できるとしたら圧倒的にコスト的に有利である。
大規模なシステムであればあるほどコストメリットは大きくなって競争力がつく。電力などを含めコスト削減努力を極限までやったところでないと生き残れないのだろう。

　エンドユーザにとってみたら、コンピュータリソースをタダ同然のように利用できるのだからとても幸せなことである。将来はクラウドも、電気やガス、水道といったインフラと同じように、蛇口をひねればすぐ使えるぐらいの手頃なインフラになっていくかもしれない。