ケント・ベック氏が指摘するクラウドの問題点は「データロックイン」

2009年6月22日

著名なプログラマのケント・ベック氏。現在ベック氏は、もともと自身で開発したオープンソースの単体テスト支援ツールJUnitをさらに改良した商用版のJUnit Maxを開発中です。

AppEngine doesn't fit the needs of startups on the runway

そのJUnit Maxのプロジェクトでは、関係するデータをGoogle App Engineに保存し管理しているとのこと。ベック氏は「全体的には私はGoogle App Engineを気に入っている」と断りつつも、ブログ「JUnit Max」のエントリ「AppEngine doesn't fit the needs of startups on the runway」で、Google App Engineでデータを管理する際に経験した2つの課題を指摘しています。

AppEngine has two attributes that have frustrated my efforts to spin my validation loop for JUnit Max using this data: time limits and owned data.

その2つとは、時間の制限とデータの取得についてです。

データのダウンロードの手段が限られている

ベック氏は1つ目の課題として、Google App Engineに保存したデータのダウンロードの方法が提供されていないことを指摘しています。

First, what's stored in AppEngine stays in AppEngine. There is no general way to download my data set.

例えば、データを検索してJUnit Maxのユーザーの中で何人がUserIDをセットしているか知りたい、と思ったとき、データがローカルにあればすぐに検索できます。しかしデータがGoogle App Engineのサーバの中にあるかぎり、こうしたアドホックな検索がやりにくい、といった例をあげて、データが簡単にダウンロードできない不便さを説明しています。

5秒以上の検索には手間がかかる

App Engine上でアドホックな検索をするとしても、今度は時間の制限にひっかかると、ベック氏は2番目の課題を指摘します。

All processing in AppEngine is triggered by sending a URL and URLs can't take longer than 5 seconds to process.

URLから呼び出せるプロセスは5秒以内で完了しなければならないという制限があるため、ちょっとした検索でもそれが5秒以上かかる場合には答えを知ることができません。プログラムを書いてcronで定期的に実行して、といった手間のかかることをしなければ実現できないとのことです。

ベック氏は"I am emphatically not anti-AppEngine in general."（アンチApp Engineのつもりは全くない）といいつつ、こうしたことは、Google App Engineからデータを持ちだそうとする場合には大きな問題点になりうるだろう、とまとめています。

On the runway, though, its limitations are potentially fatal. I'm now looking for an environment for my data that encourages experimentation and is still cheap and simple to operate. I'm looking forward to the day when moving back to AppEngine is a way to solve my scaling problems.

ケント・ベック氏は、クラウドの強いデータロックインについて警告を発したように思えます。

クラウドによるロックインは非常に強力

クラウドは、大量のデータをスケーラブルに処理する圧倒的な能力を、低価格で提供することが大きな魅力です。例えば国内では東京証券取引所のシステムを運営する東証コンピュータシステムが、取引ログの管理をWindows Azureで行えないか評価を予定しています。またアマゾンのストレージサービスAmazon S3では、大量のデータを受け入れるためにハードディスクを直接郵送できるサービスを開始しています。

しかし、いちど大量のデータをクラウドにアップロードすると、それをほかのクラウドへ移動したり、手元のサーバへ取り戻すことは極めて困難です。例えばアマゾンの資料によると、数テラバイトのデータをクラウドとやりとりするには、100Mbpsの回線を占有しても数日以上かかるためだと説明していますし、上記のベック氏のように、データを移動する標準的な手段がない場合もあります。

データと同様に、アプリケーションのポータビリティも十分とはいえません。Google App Engine、Amazon EC2、Salesforce.com、Windows Azure、そのほかのクラウドを考えてみても、ポータビリティを考慮したアプリケーションを書くことは容易ではありません。

こう考えると、クラウドによるデータとアプリケーションのロックインは非常に強力なものがあります。いちど特定のクラウドで大規模なデータの管理やアプリケーションの運用を始めたら、ずっとそのクラウドを使うことを覚悟しなければなりません。

以前のエントリ「オープンシステムの幼年期の終わり」で書いたように、IT業界はオープンシステムの登場によって相互運用性が実現し、顧客はベンダのロックインから自由になる選択肢を得ることができました。

しかし相互運用性によってシステムの組み合わせが複雑になり、適切なシステム構成が分かりにくくなったり、トラブル時の切り分けが難しくなる、という副作用も生じました。

その複雑さによる副作用を取り除くために、オラクルはサン・マイクロシステムズを買収して総合ベンダーを目指し、一方でクラウドという「全部お任せ」なシステムが登場したのです。

しかし、再び相互運用性を手放してベンダロックインを強めていいものでしょうか？

クラウドの相互運用性を実現しようと「Open Cloud Manifesto」のような動きもありました。また、経済産業省が公表した「高度情報化社会における情報システム・ソフトウェアの信頼性及びセキュリティに関する研究会の中間報告書」でも、クラウドの相互運用性についての重要性が指摘されています。

いまのところクラウドを提供する各社は、相互運用性よりも差別化要因の実現に忙しいようにみえます。発展途上の技術を扱っているので仕方のない面はありますが、クラウドが成熟したプラットフォームになるためには相互運用性は欠かせない要素です。これからクラウドの付加価値としての相互運用性について、踏み込んだ議論と実装が登場してくることでしょう。