【Google App Engine】 Entityとトランザクション

Entity設計について

　GAEではEntityというモデルを定義してJDOを使ってデータを永続化する。Entityはオブジェクトモデルであり画面など実際の業務アプリケーションや外部インターフェースなどを直感的に表現できるという点で優れている。しかし、階層型ということもあり、リレーショナルなモデルとはあまり馴染まない。もしかしたら、これまでRDB的な設計を中心にやってこられた方にとっては苦痛さえ感じるかもしれない。Entityをうまく設計するためには、ひとまずRDB的な頭をリセットしてオブジェクト的な発想をすることをおすすめする。一度慣れてしまうと誰でも簡単にサクサク作れるようになるだろう。逆に、RDBの呪縛から開放されOOに覚醒してしまうともう後には戻れないので注意が必要である。RDBって不要じゃん？とか、これからの時代はOOでKey/Valueだ！などと思うようになれば覚醒した証拠だ。だがこのモデルがRDBにとって代われるかというとそうではない。特に運用面を考えると全く使い物にならないだろう。データ操作はSQLとは比べ物にならないぐらい酷いので、完全移行はそれほど甘くはないと心得ておくべきだ。現時点のクラウドはあくまでXTP（eXtreme Transaction Processing)基盤として考え、RDBはデータウェアハウスなど裏で動く情報系システム用として考えるとよいと思う。モノシリックなアプリはRDBで動作するがあくまで正はRDBであるとする。（このようなハイブリッド方式は、Reflex BDBでも採用している）

　オブジェクトモデルを使ってEntityを設計する方法については実はReflexも同じである。ReflexはGAEが出る前から存在するフレームワークであり、決して真似して作ったたわけではないが、偶然にも非常に似た考え方で設計できるものとなった。具体的には、ZEROからRESTfulアプリを作成を見ていただくと分かるのだが、週報アプリ画面から実際にEntityを作成しながら開発している。

　１．画面のモックアップを作る
　２．モデリングを行い画面のEntity（Model）を作成する
　３．テーブルのEntityを作成する(DAO)
　４．Entityのインスタンスを作成する

　また、Entityはマインドマップなどを使って直感的に生成できる利点もある。下図はReflex表現（画面左）を使ってEntityを定義してマインドマップを生成した様子である。
　Reflex表現さえ作成できればマインドマップを作成できるし、Entityのソースも自動生成できる。Reflex表現は、今流行りのドメイン特化言語のようなものだが非常にシンプルな表現でEntityを作成できることが特長である。Reflex表現の詳細は、Reflex Entity Editorを見てもらえればわかるが、要は、要素の型と多重度、および親子関係を定義するだけである。



ReflexとJDOの共存

　JDOのEntityとReflexのEntityは同じ構造をもてる。例えば、上のマインドマップで、one-to-manyを示すものはReportとactivityであるが、これはReportクラスのListプロパティとしてactivityを定義したものとなる。これはJDOもReflexも全く同じ。Entity定義におけるJDOとReflexの違いは、JDOはデータの永続化のために使うマーカとして、@PrimaryKeyや@Persistentなどアノテーションを使うのに対し、Relfexは主にXMLやJSONなどの出力対象をpublicにするなど、CoC（設定より規約）に基づく考え方で生成することである。（詳細＝＞reflexcore）CoCは規約を覚える必要があり敷居を高くしているがReflex Entity Editorなどの自動生成ツールがそれを補っている。
　また、偶然の産物であるが、両者はお互いに干渉しないため、永続化と外部インターフェースを１つのクラスのなかで表現できるというメリットが生まれている。

Entity Groupsとトランザクション


　GAEでは、全てのentityはentity groupに所属しており、entity group単位でトランザクションを実行できる。先ほどのReportとactivityの例のように親子関係をもっているものは、同じentity groupとみなされ同一トランザクションのもとに扱うことができる。以下の例は1対多の関係を持ったEntityの場合であるが、1対1の場合についてもListの代わりに単独のクラス名になるだけで同様に考えることができる。(追記：親子関係については嵌りやすいので注意＝＞JDOから直接JSON、XML

Owned_One_to_Many_Relationships

import java.util.List;

// ...
　　@Persistent
　　private List contactInfoSets;

また、子から親へのパス（双方向パス）をつけたいときは、@Persistent(mappedBy ="employee")のように、子のキーを示すアノテーションを親のクラスに追記すればよい。

import java.util.List;

// ...
　　@Persistent(mappedBy = "employee")
　　private List contactInfoSets;

　トランザクションは、以下のように、PersistenceManager(シングルトン）を使いpm.currentTransaction()を呼び出すことで、txコンテキストを取得する。tx.begin();でトランザクションが開始、tx.commit();でコミット、tx.rollback();でロールバックとなる。以下の例では、tx.begin();で開始、ClubMembersのインスタンスをキー”k12345"で取得して、インスタンスのカウントを足した後、pm.makePersistent(members);で永続化、tx.commit();でコミットしている。

import javax.jdo.Transaction;

import ClubMembers;　 // not shown

// ...
　　　　// PersistenceManager pm = ...;

　　　　Transaction tx = pm.currentTransaction();

　　　　try {
　　　　　　tx.begin();
　　
　　　　　　ClubMembers members = pm.getObjectById(ClubMembers.class, "k12345");
　　　　　　members.incrementCounterBy(1);
　　　　　　pm.makePersistent(members);
　　
　　　　　　tx.commit();
　　　　} finally {
　　　　　　if (tx.isActive()) {
　　　　　　　　tx.rollback();
　　　　　　}
　　　　}

　これは楽観的ロックの仕組みであり、tx.begin();の後でもロックがかかっているわけではないので注意が必要だ。つまり、他のプロセスが同じインスタンス”k12345"を読むことができるが、使用中の場合は、java.util.ConcurrentModificationExceptionが発生し、JDOはJDODataStoreExceptionかJDOExceptionをスローする。また、JDOは１回しかトランザクション処理を行わないため、何回か繰り返し実行してコミットできたら抜けるように、アプリケーション側（以下参照）でフォローしてあげなければならない。
ちなみに、同一トランザクション内で複数のentity groupを更新しようとしても、JDOFatalUserExceptionが発生してコミットできないようになっている。

What Can Be Done In a Transaction

　for (int i = 0; i < NUM_RETRIES; i++) {
　　　　　　pm.currentTransaction().begin();

　　　　　　ClubMembers members = pm.getObjectById(ClubMembers.class, "k12345");
　　　　　　members.incrementCounterBy(1);

　　　　　　try {
　　　　　　　　pm.currentTransaction().commit();
　　　　　　　　break;

　　　　　　} catch (JDOCanRetryException ex) {
　　　　　　　　if (i == (NUM_RETRIES - 1)) {
　　　　　　　　　　throw ex;
　　　　　　　　}
　　　　　　}
　　　　}

関係を持たない複数のEntityのトランザクション

　関係を持たない複数のEntityをEntity groupとすることで１つのトランザクションとして実行できるようになる。それは、以下のように、keyBuilder.addChild（）を使って、一方のEntityのキー生成を他方のキー生成と結合させることで行う。
　
Creating Entities With Entity Groups

import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import com.google.appengine.api.datastore.Key;
import com.google.appengine.api.datastore.KeyFactory;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class AccountInfo {
　　@PrimaryKey
　　@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
　　private Key key;

　　public void setKey(Key key) {
　　　　this.key = key;
　　}
}

// ...
　　　　KeyFactory.Builder keyBuilder = new KeyFactory.Builder(Customer.class.getSimpleName(), "custid985135");

　　　　// AccountInfoのキー生成をCustomerのキー生成と結合させる
　　　　keyBuilder.addChild(AccountInfo.class.getSimpleName(), "acctidX142516");
　　　　Key key = keyBuilder.getKey();

　　　　AccountInfo acct = new AccountInfo();
　　　　acct.setKey(key);
　　　　pm.makePersistent(acct);

また、Entity group内の親キーにアクセスするには、以下のようなアノテーションを追記すればよい。

// ...
　　@Persistent
　　@Extension(vendorName="datanucleus", key="gae.parent-pk", value="true")
　　private Key customerKey;

ちなみに、関係を持たない複数のEntityを、Entity Groupとして定義すると、分散ネットワークの同じ場所に格納される。これは、あるトランザクションで遠くにあるentityが関係すると大量のネットワーク通信が発生し性能が落ちてしまうのを避ける目的がある。Entityがあちこちのサーバに散らばってしまうのはまずい。

ただ、What Can Be Done In a Transaction

Every entity belongs to an entity group, a set of one or more entities that can be manipulated in a single transaction. Entity group relationships tell App Engine to store several entities in the same part of the distributed network.

によれば、分散ネットワークの同じ場所とあるだけで、それがBigTableの同一row（行）なのかTabletなのか、あるいは、その両方でもないのか、不明である。（昨日のクラウド研究会でGregor Hohpeさんは、EntityはRow単位で、いろんなところに格納されるといっていたような気がする。資料＝＞ProgrammingCloud）

BigTableの行(row)

　１．名前は、任意の文字
　２．1行のデータへのアクセスは、atomicである
　３．行は、データを格納する際に、自動的に作成される
　４．行は辞書式順序で並べられている
　５．通常、行は1台または数台のマシン上に、辞書式順序の近い順番にまとめられる

BigTableのTablets

　１．大きなテーブルは、行の境界で、タブレットに分割される
　２．タブレットは行の連続する範囲を維持する
　３．クライアントは、局所性を達成するために、行のキーを選択できる
　４．1つのタブレットあたりの100MB~200MBが目処

総括

　１．Entity設計はオブジェクト設計を元にする必要がある。また、ドメイン特化言語を利用することで生産性向上を期待できる。

　２．BigTableなどBASEを元にしたGoogleの基盤技術を使うGAEであるが、トランザクションの機能を使うことでConsistency（整合性）が保証されるアプリケーションを組むことができる。ただし、１UOW（Unit Of Work）＝ Entity Groupとなる。
　
　今でもモヤモヤしているのは、Entity Groupの粒度をどうすればいいかという点。かなり強引だけどSCAに当てはめて考えてみる。Entity GroupはSCAでいうところのComponentに相当するのだろうが、さらにCompositeで括ったときのトランザクションがどうなるかわからない。今の流れからして、2phase commitはやるべきではない、ということにはなりそうだが。



＜関連＞
JDOから直接JSON、XML
JDOから直接SOAP、ATOM。それからDeep Copy
AJAX CRUDサンプルとJDO代替ライブラリ
Pagingをどうやって実現するか
RESTfulアプリのCRUDサンプル　－Servlet編－
RESTfulアプリのCRUDサンプル　－Modeling編－
Entityとトランザクション2

【クラウドコンピューティング】 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は非常に重要である。しかしクラウドに載せるのは簡単ではないだろうと私は思う。

【クラウドコンピューティング】 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、広告モデルといった組み合わせによって実現できるとしたら圧倒的にコスト的に有利である。
大規模なシステムであればあるほどコストメリットは大きくなって競争力がつく。電力などを含めコスト削減努力を極限までやったところでないと生き残れないのだろう。

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

【Google App Engine】 RewriteServletを使ったBloggerカスタムドメイン移行

　GoogleAppEngine for Javaの調査もかねて、RewriteServletというものを作ったので公開する。このアプリはHelloWorldよりちょっとだけ長いが、GAEアプリとして最初に作るものとしてはちょうどよいサンプルになったと思う。ソースや作り方は以下の資料にある。GAEforJavaのチュートリアルになるように作成してみた。

資料＝＞ダウンロード

追記：2009/5/1
web.xmlに修正があります。資料P12

　１）　/feeds/posts/defaultや/feeds/posts/default?alt=rssをrewrite対象にする。
　２）　targetの最後の/を取る
　３）　skipの最後の/を取る

【クラウドコンピューティング】 弱者連合とスケーラビリティ

　年初にクラウド予想2009をやった。これはだれでも容易に予想できる内容ではあるのだが、3ヶ月経った今では、「１）コストダウンは急速に進む」、「４）大手ITベンダはクラウドの大合唱」は言わずもがなとなった。
　コストダウンに関しては、Amazon S3は昨年11月に値下げして以降、一括支払いでさらに値下げ、SimpleDBを使えば6ヶ月間無料になるという話があり、その急激な値下げには驚かされるところとなった。
　「大手ITベンダはクラウドの大合唱」は予想通り自社製品のクラウド化が進んでいる。具体的な中身は、SunによるSun Open Cloud Platformの発表や、国内ではKDDI クラウドサーバサービスの発表があった。またIBMやCISCOなどによる、Open Cloud Manifestoなどの標準化の話も出てきた。
　そして、「５）OracleやMSは自己矛盾には陥らないが苦戦する」予想は、MSがAzureでかなり善戦しそうな感じを受けるもののSDSでの混乱ぶりがニュースとなっており今後どうなっていくか注目である。＜関連＞Azureに思うこと

　概してクラウドはコンサルがミソクソな話をしだしていることもあってバズワード化に拍車がかかっているのは否めないところである。だが、ここでクラウドの特長であるスケーラビリティの観点から話を整理すると重要なポイントが見えてくる。

　先日、ある大手ITベンダーのクラウド製品/サービスの説明があった。そのサービスがスケーラブルかどうかの質問が挙がったが、担当者はスケールアウトはしないがスケールすると答えていた。VM技術はつかうものの必要に応じてハイエンドの製品も使う。これは自社製品を無尽蔵に並べるサービスを提供することを意味していた。まあ、スケールアウトしなければ困るような大規模トランザクションなんてそうないだろうからそれでもいいのだろう。

　しかし、その話とスケールアウトしない話は別である。スケールアウトしないがスケールするというのはコストを無視した考えである。お金にいとめをつけないからクラウドでよろしくなんていう太っ腹な企業は別にして、コンシューマ相手では、このご時勢もあって相当な低価格でないと競争に生き残れないだろう。そして、それはタダ同然のレベルだと思う。

　先日、Google App EngineのJava対応が発表された。これを受けて、makers-hubという試みもはじまっている。「製造業向けネットサービスは無料に出来るんです。」だそうだ。

　こういったなかで生き残れるのは、GoogleやAmazonといった2強と、日本では、はてなぐらいじゃなかろうか。彼らに共通するのは、コモディティサーバを束ねてスケールアウトできる技術をもっているということ、それから、広告モデルという別の収入源をもっていること。コモディティサーバとOSS、広告モデルが競争力の源泉。とにかくお金をかけないでサービスを運用する技術とノウハウは大変なものである。そういう意味で、SQLServerを並べる戦略に転換したMSのAzureの競争力には疑問が残る。その運用コストは決して安くはないだろうから、しばらくは太っ腹を相手にしながら、スケールアウト技術を開発して競争力をつける戦略なのだろう。MSでさえ競争力に疑問が残るのだから他のベンダはなおさら厳しそうである。Open Cloud Manifestoが弱者連合と揶揄されるのはわかる気がする。しかし、新規の顧客開拓は厳しい一方で既存顧客の囲みこみは成功するとは思う。クラウド要求に応えられない大手ITベンダーはもっと苦戦すると思われるので、何かしら出さざるを得ない状況なんだろう。先の担当者が、「GoogleやAmazonとは真っ向勝負する気はない」といっていたのが印象的だった。

【クラウドコンピューティング】 AzureSDSに思うこと

先月MIX09で発表されたAzure SDSが物議をかもしている。実際に参加されたM先生のメールにはこうある。

昨年のPDCでは、まず、Partition Keyを必須とするSDSを提供して、その後に順次、Relational型をサポートをするというロードマップを持っていたのですが、今回は、まったく逆に、最初に、SDSとして、クラウド上のRelationalデータベースを出してから、その後に、Partitionの特徴を追加するというように、大きく路線を修正しました。

たしかに、ホームページにもAzure SDSはSQL Serverをベースにしていると書いてある。

Microsoft® SQL Data Services (SDS) is a cloud-based relational database platform built on SQL Server® technologies.

一方、今までのSDSの中核だったWindows Azure Storageは、ACEモデルの、EntityがProperty BagでKey/ValueベースのTableである。

なぜ２つのアーキテクチャーが存在するのか。ゼータの鼓動。SQL Data Servicesにみるクラウドデータストレージの現実解によれば、次のように説明されている。

誤解を恐れず簡単に説明するならば、Azure Storage Servicesがいわゆるクラウド的なアーキテクチャであり、SDSは従来のRDBMS的なインタフェースを提供する役割を担っている。＜中略＞従来のソフトウェア資産を活かしながら、最終的に完全なクラウド対応でスケーラビリティのメリットを享受するステップとして、SDSを利用したクラウド側の運用に移行できることは、ユーザー企業にとっても、ソフトウェアベンダーにとっても現実的な落としどころではないだろうか。

先生も次のようにおっしゃっている。

概して好意的で歓迎していた人いわく、「今までの資産と開発技術が、そのまま、クラウドで使える」　確かに、Azureのしたたかなところは、そのOn Premiseとの共存や、開発者のスキルの温存といった現実主義にあったわけで、データ・モデルの部分だけが、大きな飛躍を含んでいたわけですので、こうした反応が出てくることは、理解できないわけではありません。

現実主義・・・私はここにMSの文化を強く感じてしまう。ちょっと話がずれてしまうかもしれないが、IBMと繰り広げたOS戦争でも同じことが起きていたように思う。OS2はWin3.1互換モードなどを搭載していたが重いOSにPC側の性能がついていかず敗北した。実はNTもほぼ同じ問題を抱えていたが、Win3.1、Win95などでユーザをつなぎとめつつNTの改善を図り、やっとWin2000で移行に成功したのである。

Windows NT系(wikipediaより抜粋)

しかし、初期のWindowsは見た目はGUIではあったが内部的にはMS-DOSを土台とし、また16ビットのメモリの壁、マルチタスクの不完全さ、ネットワーク機能の欠落など課題が山積していた。
ビル・ゲイツは一から作り直すことを決断し、＜中略＞サブシステムで致命的な問題が起きてもクラッシュと呼ばれるシステム全体の破綻を起こさない、当時のPCで動作するOSとしては画期的なシステムであった。
＜中略＞
当初は重いOSにPC側の性能がついていかず、デスクトップ用の業務用OSの後継にしようというマイクロソフトの目論みは失敗した。
しかし、NT 3.1、NT 3.5に続いて発表した NT 3.51において、時をほぼ同じくしてリリースしたWindows 95をクライアントとしたサーバOSとしての性格を強調するマーケティングを行い、NetWareの牙城であったNOSの市場に足場を確保することに成功した。
バージョンアップを重ねる際にマイクロカーネル概念の一部を放棄してWin32サブシステムやグラフィクス・デバイスドライバの論理層などをカーネル空間に展開してスループットを向上するなど、重いオペレーティングシステムという汚名を払拭する為のいくつもの改修が行われた。
＜中略＞
その後もマイクロソフトはデスクトップ用の業務用OSの後継としても売り込みを図るが、一部のITプロフェッショナルを除いては市場に浸透せず、2000年にリリースしたWindows 2000に於いてようやくデスクトップOSとしても市場に認められることとなった。
Windows 2000が認められたのは、Windows 9xシリーズのプラグアンドプレイやACPI等の電源管理機能、USBへの対応などユーザビリティの高い機能を実装したことと、この頃にはハードウェアの性能がNT系OSの重さを問題としない（つまり重たくない）レベルにまで向上していたことによると考えられる。
Windows 2000は業務用のデスクトップOSとして歓迎されたが、一般家庭向けの市場でNT系OSが普及するのは次のWindows XPまで待つことになる。

　16ビットOSから32ビットOSへの移行は実に10年近くかかっている。このようにアーキテクチャーの変更が伴う移行は長い月日を必要とする。これはクライアントOSに限らずクラウドも同様だと私は思う。

　話を戻して、なぜSQLServerが求められるか。

　ホストを中心としたプロプライエタリな世界を開放してくれたのは、RDBの成功にあったといっても過言ではない。RDB中心のアーキテクチャーは90年代初期のダウンサイジング以降インターネット時代の今に至るまで変わっていない。その間すべてのアプリケーションはRDBを中心に作られている。実はホスト時代のストレージはRDBではなくkey/valueに近いものであったのだが、そこからRDBへのアーキテクチャーの変更が可能だったのは、パラダイムシフトによりUNIXやWindowsといったオープン系OSにまるごと変わってしまったからである。ホストからのデータ移行もそれほど問題にはならなかった。
　
　Azureの事例をみてもわかるように、今後、key/valueへの移行が進むとしても、クラウドデータにおけるUIを担うのはやはりSQLだろうと思う。ACEモデルに限ったことではないがSQLより優れた操作性をもった言語を開発することはとても難しい。またSQLには既存の多くの開発者スキルもある。スケールできるという理由だけでRDBをkey/valueに移行するとは到底思えない。

　となると、内部的なアーキテクチャーはkey/valueでインターフェースがSQLになるのが理想なのだろう。Azure SDSが今後どのように進化していくのか、楽しみである。