devsumi2009 : クラウドのプログラミング（パラダイム）

今回のDevelopers Summit 2009ではクラウドでのプログラミングに関するセッションがいくつかありました。
ここではそれを一気にまとめてみたいと思います。
　なお、ここでのクラウドとはGoogleやWindows Azureのような大規模コンピューティングリソースを活用するPublic Cloudを想定しています。もちろんこれに類するPrivate Cloudも含まれます。
　単に仮想化をしてコンピューティングリソースを統合するような小規模なPrivate Cloud（といっていいかどうか）はここでの想定外です。
　Amazon AWSについてはGoogleやWindows Azureとは異なる部分がありますので、ここであげられる全ての制約事項が当てはまらないかもしれません。Amazon AWSに関してはそれを利用する個々人の宿題とします。

クラウドによるソフトウェア開発パラダイムの進化
Programming the Cloud / クラウドをプログラミングする
パネルディスカッション：クラウド時代のプログラミングスタイルを語り合おう
　　＝＞　セッション詳細(2/26追加）

１．N-tierは最適解ではない
　Webアプリケーションなどでは3-tierなどが当たり前になってきていますが、クラウドではこれはけして最適解ではありません。
　いったんN-tierは忘れたほうがよさそうです。

２．完全性よりも可用性
　ACIDの定義が変わります。
　従来のACID
　A : Atomic／C:Consistent／I:Isolated／D:Durable
　クラウドでのACID
　A: Associative／C:Communicative／I:Independent／D:Distributed

　一般的にクラウドでは可用性を極大化するために完全性が犠牲になっています。ですから従来の2 phase lockやトランザクションという考えではなく、1行（もしくは1ステートメント）だけのトランザクションしかないと考えたほうがよいようです。
　さらにデータの完全性については次の点も考慮が必要です。
　Memcacheなどを活用しているため、データストアとの差異が発生する可能性がある。

　このことからデータベースもRDBというものは最適ではありません。ほとんどがkey-valueのようなデータ形式になっていきます。これもデータベースの可用性を考えた結果です。これはデータベース設計から開発パラダイムが変わるということです。ER図の定義は一般的ではなくなります。

クラウドのアーキテクチャとしては
　広範囲に分散／疎結合／多量のコンピューティングパワー／標準化
という理想がありますが、実装面から見ると考え方を以下のように変えなければなりません。

• NO Stack Call 　
• NO Transaction 　
• NO Promise 　
• NO Ordering Constraints 　
• NO Assumption

これらのことから言えるのは銀行・証券のようなミッションクリティカルなシステムはクラウド化できないということです。

クラウドにはクラウドに向いたシステムを構築するべきで、従来のものがすべてクラウド化されるわけではないということも理解する必要があります。

データベースに関してはGoogleでもAzureでもSQL Queryのようなインターフェースを用意していますが、上記のような制約があることを理解した上で利用すべきです。従来の完全性が保証されているわけではありません。
アーキテクトや開発者はこうした制約事項をしっかりと理解しましょう。

タグ：devsumi2009 クラウド・コンピューティング 開発パラダイム Google App Engine Windows Azure