Database as a Serviceについて議論
この前、ひょんなことから、友人と「Database as a Service」というのはいったいなんなのか、という話になった。
巷を賑わせつつある、プラットフォームレイヤーのサービス化。それもデータの永続化というレイヤーにフォーカスしたサービス。具体的には、Amazon SimpleDB *1, Facebook DataStore, Salesforce Database (force.com Database) のそれぞれの違いはなんなのか、という話。
「サービスとして提供されるデータベース」の分類の仕方として、いろいろ着眼点はあるけれども、もっとも自分が面白いと思っている分類の仕方に、それがデータベースホスティングから由来しているのか、それともWebサービスAPIの拡張なのか、という観点がある。それぞれHosted Database 型とExtended Web Service型として分類してみようと思う。
実はこれらはそれぞれデータの持ち主が誰なのか、という点で大きく異なる。この「データの持ち主」という言葉は、ちょっと既存の常識と異なっているように取られるかもしれない。ひとつ言っておくと、ビジネス上の規約や法的な根拠の話ではない。もっとシステム的な考えに基づく分類だとおもってほしい。
Hosted Database型
まず３階層のWebシステムのアーキテクチャを見てみよう。APサーバが後ろのOracle(mysql)につながるのに、接続するアカウント／パスワードはscott/tigerだ。この場合、データベースに入っているデータの「持ち主」はscottユーザ、つまりAPサーバ自身になる。
前者（Hosted Database) に分類されるサービスとは、このDBの部分をインターネット上にそのまま構築しなおしたような物を指して言っている。それがプロトコルがHTTPでRESTで、XMLやJSONがメッセージになっていたとしても、アクセス主体が「scott」、つまりアプリケーションプログラム自身である限りは、本質的に変わらない*2。同等のものと考える。Amazon のSimpleDBはこれに該当するだろう。
Extended Web Service 型
翻って、最近のWebサービスAPI、しかもパブリックでなくアクセスコントロール付きのサービスを考えてみる。
マッシュアップアプリケーションなどがアクセス制御がかかったWebサービスを呼び出すときは、エンドユーザのユーザ名／パスワードの情報をHTTPヘッダ、あるいはメッセージの中の要素に入れて、ターゲットのWebサービスにリクエストを投げる。ユーザ名／パスワードを第３者に渡すのはセキュリティ的にまずいというので、最近ならOAuthのような仕組みを使って、トークンの受け渡しでWebサービスにアクセスができるものもある。
ともかく、この場合、Webサービスとしてアクセスするリソースの「持ち主」は、エンドユーザになる。マッシュアップサービスは、あくまでエンドユーザの持ち物であるデータに限定的にアクセスすることを許してもらっているにすぎない。
このWebサービスが、単なる固定されたサービスとしてのAPIだけでなく、任意の構造化データを取り扱えるように拡張されていったのが、後者(Extended Web Service型)に分類されるデータベースサービスである。Facebook Data StoreやSalesforce Databaseなどはこれに該当する。
この２つの分類を、インフラサービスからのボトムアップなのか、アプリケーションサービスからのトップダウンなのか、という見方をしても面白いかもしれない。それぞれ、既存のビジネスの背景をよく活かしている。
混乱しやすいのは、後者（Extended Web Service型）では「データ」の持ち主はエンドユーザであるが、「データ構造の定義」は、3rd Party開発者の自由になっている点。ここが間違えられやすい。従来のWeb+DBな開発では、通常データ構造もデータもすべて開発者の管理下にあり、開発者は全権を持っていた。なので既存の開発者には前者（Hosted Database型）の方がなじみやすい。後者では少なくともデータに関しては権利をそがれてしまうので、それを不自由だと思うかもしれない。ただし、それでも開発者はスキーマを自由に定義できるので、存分に自分が作りたいアプリケーションを作ることができる。
比較
とりあえず、自分が考える開発者から見たそれぞれの特徴を比較してまとめてみる。
| Hosted Database | Extended Web Service | |
| エンドユーザ | アプリケーション開発者側が個別に獲得する | データベースサービス側が保持しているユーザベースを利用できる |
| 一般公開サービス | 可能 | 基本的にデータベースサービス側が保持しているユーザ空間に閉じる |
| アプリケーション間のデータおよびデータ定義の共有 | 完全に分離 | データ、データ定義ともに共有可能 |
| エンドユーザ間のデータアクセスコントロール | エンドユーザを保持しないため、アプリケーション開発者側の責任 | データベースサービス側が提供 |
| 全ユーザデータの統計／分析 | すべてのデータにアクセス権があるので、可能 | データはそれぞれユーザの所有物であり、不可能 |
| サービスの例 | Amazon S3 | Facebook DataStore, force.com Database |
後者(Extended Web Service)をさらに言い換えると、「エンドユーザアクセスコントロールが組み込まれたデータベース」というのが最もよく言い表せていると思う。これは、今までのアプリケーションプログラム側でのアクセスコントロールの実装が当たり前の開発者から見たら不自由さを感じるケースもあるだろうが、めんどくさいことを考えずにアプリケーションが作れるというメリットを感じるケースもあるだろう。
蛇足ながら付け加えておくと、これはすでにエンドユーザを保持しているサービスだからできることである。さらにアクセスコントロールの元になる情報が既にある場合が多い（e.g. Facebookはソーシャルネットワーク情報、Salesforce は企業内の組織階層／グループ）
どっちが流行る？
開発者が慣れているのはHosted Databaseの延長型の思考だろう。もし今後日本のSIerがこういうサービスをやるとして、おそらくこちら側に走るに違いない（彼らはエンドユーザを抱えているわけではないから、後者をやるにはちょっと無理がある）。ただ、データベース部分のホスティングだけで開発者が得るものはやっぱり少ない。運用が外に出せるのは重要だけども、どうせならアプリケーションホスティングまで含まれていないと、データベースの運用だけでは、もしかしたら魅力を感じないかもしれない。ということで、たとえばSimpleDBであればEC2と併せて採用されていくような気がする。
一方、Extended Web Serviceの場合は、データベースサービスのプラットフォームに強くロックインされるので、そこがアプリケーションの提供戦略とあわない場合は、どんなにそれが魅力的であっても考えるだに値しなくなる。Hosted Databaseの場合はプラットフォームに何を使っているかを隠すことができるが、Extended Web Serviceの場合は隠せない。ということで、これらはあくまで既存ユーザに対する主サービスの拡張というところからじわじわと広がるだろう。
まとめ
現在個人的に興味があるのは後者。
