【Google App Engine】 1.3.2の機能強化に見る方向性、それから議論のまとめ

App Engine 1.3.2の目についたところ

1.3.2では、URLFetchやTaskQueueの強化がはかられた（非同期URLFetchは1.3.1で対応済）
MLより

- URLFetch API - We’ve expanded the number of ports you can access with
the URLFetch API. You can now access ports 80-90, 440-450, and 1024-65535.
- Mail API - We’ve expanded the allowed mail attachments to include
common document extensions including .doc, .ppt, and .xls.
- Task Queue API - We’ve increased the maximum total Task Queue refill
rate to 50 per second.

　一方で、エンドユーザに対しては同期的な仕組みを、バックエンドについては実行時間の延長が計画されている。GAEでは、効率よく資源活用しながら、同時に必要なものは充実させていく方針のようである。

http://code.google.com/appengine/docs/roadmap.html

Features on Deck

- SSL for third-party domains
- Background servers capable of running for longer than 30s
- Ability to reserve instances to reduce application loading overhead
- Ability to select different availability vs. latency options for
Datastore
- Support for mapping operations across datasets
- Datastore dump and restore facility
- Raise request/response size limits for some APIs
- Improved monitoring and alerting of application serving
- Support for Browser Push (Comet) communication
- Built-in support for OAuth & OpenID

　特に、Spin up問題を解決する件（Ability to reserve instances to reduce application loading overhead）については、ココにあるように、かなり自信もあるようだ。（Googleの真骨頂！？）

Keeping reserved instances has been added to our public roadmap:

http://code.google.com/appengine/docs/roadmap.html

As far as spinning up
additional instances, there are probably a few good solutions here. We'll be
best off collecting feedback when we ship reserved instances on which
solution works best.

また、MapReduceのような並列実行の仕組みを導入して大規模処理を可能にする予定があるらしい。（参照）

30 sec execution limitation only to web requests or to all requests ?

Yes, queued tasks and scheduled tasks have an execution time limit as
well. You'll want to break your large tasks into smaller pieces. We've
committed to map/reduce support to help make this easier on our
roadmap for a future release.

クラウドの最大の特長は全体最適化

以上をふまえて、また、先日の中島さんとの議論を通じて感じたことをまとめてみる。（御丁寧に、また返事をいただいた。反省：思考はもっと自由に. カオスの奇跡を求めて多様性に飛翔すべし）

GAEでは、 Datastore、Memcache、TaskQueueなど、リソースへのアクセスがすべてNW経由となるのが基本である。疎結合・ステートレスという特長を活かしてスケーラブルにする。だが、WebServicesのAPI（RESTあるいはProtocol Buffers）となるので、この時点でBASEが必然的に導入されることになる。

重要なのは、リソースの占有時間を縮小することで全体最適化をはかること。
資源の有効活用では、物理的なリソース占有時間の短縮を図ることと、アプリの静的な配置から動的な配置（Spin up/down）をオンデマンドで実現することで対応する。

・scalabilityやスループットの高さよりも、すべてのアプリをpartition-tolerantに書くよう強制して巨大インフラに細粒度で集約し、桁違いの全体最適を実現できることが重要と思う。でないと大規模サービス以外はあまり必要ない
＞NoSQLとかKVS（App EngineやNoSQLはスケーラブルだからエラいのではない）

リソース占有時間に関しては、GAEには有名な、30秒（WebRequest）、10秒（TaskQueue起動）、5秒（URLFetch)、5分（インスタンス生存期間）といったタイムアウトルールがあるが、非同期コールが導入されたことで、アプリへの実質的な制限は緩和される。（アプリからみると実質的に同期と同じ扱いにできる）物理的なリソースの占有時間を短縮するという意味では、Spin up/downや非同期コールの目的は同じである。このあたりは、できるだけ相手に干渉しないという非協調性（楽観的ロックなど）と同じ発想のように思う。（参照）
また、MapReduceではTaskを細かくすることで並列実行度を上げているように、Taskを小さくすることで、リソース利用効率は上がる。
ただし、MapReduceは何でもかんでも並列実行できるわけではないし、BASEトランザクションの不完全さは開発コストとして跳ね返ってくるので、注意が必要である。

BASEなどの不完全な部分をソフトウェア技術により補うというのがGoogleの方針なのだが、開発や運用コスト、パフォーマンス、セキュリティなどのトレードオフとはうまく付き合う必要がある。

例えば、外部システムと内部システムの中間領域（厳密には内部システムの範疇、GAEでいうところのGlobal）において、エンドユーザに対して隠蔽するようなフレームワークが重要になってくる。中間領域には、MemcachedといったDHT（分散ハッシュテーブル）と、Queueing Systemがある。（GAEでいえば、MemcacheとTaskQueue）この中間領域のフレームワークにNFRを実装してBASEを隠蔽する。ミッションクリティカルなシステムの Consistencyを満たすようなACID環境をエンドユーザに提供できればよい。

なお、同期型アプリケーションが必要な部分は限定的なので全体アーキテクチャーとはせず、要件に応じてパフォーマンスを優先する（BASE）のか整合性を優先する（ACID)のかを判断する。（そういう意味ではEventually Consistencyのオプションが選択できるのは嬉しいはず）

中島さんとの議論を通じて、「クラウド・プラットフォームの不特定大量のプロセッサー資源をエラスティック(柔軟）にプロビジョニング（配置）して効率よく資源活用することが最大の効果であり、全体の最適化によりコスト削減を実現する仕組みが重要（参照）」ということを改めて認識させられた次第である。

＜関連＞
Scale OutアンチテーゼとeCloud構想：質問
Scale OutアンチテーゼとeCloud構想
Scale OutアンチテーゼとeCloud構想：中島の考え
Scale OutアンチテーゼとeCloud構想：中島の考えを読んで
Scale-outアンチテーゼ 思いついた反論、というか疑問
竹嵜さんの疑問に対するお答え
ホメオトシスぎるお答え
反省：思考はもっと自由に. カオスの奇跡を求めて多様性に飛翔すべし