Flex 4の新機能トップ10
今週（2009年6月1日）AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumbo（オクラ）というコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。
News
AppEngineがウェブ開発を簡単にする
作者 Geoffrey Wiseman , 翻訳者 金森 諭 投稿日 2008年4月18日 午後12時44分
2008年4月7日に開かれたCampfire Oneで、GoogleはGoogle App Engine(サイト・英語)を発表した(source)。Googleは、これによりウェブアプリケーションを作ったり稼動させたりスケールさせたりする手間 を省けるという。Google App Engineの要点は、ウェブアプリケーションをGoogleのインフラを使いながらローカルで開発でき、出来た後にはそのインフラへデプロイすることが できるということだ。
現時点のGoogle App Engineはまだプレビューリリースだ。完全な機能はまだ利用できず、ストレージ、CPU、帯域はプレビュー期間中だけフリーで使用でき、またそれらを 制限するクオータシステム(source)が有効になっている。プレビュー期間が終わってもそのクオータ上限まではフリーだが、必要であれば追加のリソースを購入することができるよ うになるだろう。追加リソースの料金はまだ公開されていない（そもそもまだ決まってない可能性もある）。
プレビューリリースでのクオータは、「開発者一人につき3つのアプリ」「1つのアプリにつき500MBのストレージ」「1日（その時点から24時間前まで の）につき2000通のEmail、10GBの下り帯域、10GBの上り帯域、200万メガヘルツのCPU、65万回のHTTPリクエスト、250万回の Datastore API呼び出し、および16万回のURL Fetch API呼び出し」となっている。
テクノロジ：開発環境とAPI
Google App Engineのテクノロジは今のところGoogle認定言語の一つであるPythonをベースにしている。Googleは将来的に他の言語もサポートする ようにしたいと言っている。提供されているPythonの実行環境は、セキュリティとスケールの問題から、基盤となるOSへのアクセスが限定されるセキュ アなサンドボックス内に置かれている。この実行環境は標準ライブラリを含み、モジュールによって拡張可能となっているが、モジュールでC言語は使用できな い。
この実行環境はPythonの標準ライブラリを含んでいます。もちろんソケットを開いたりファイルに書き込みといったサンドボックスの制限を破るようなメ ソッド呼び出しは実行されません。便宜上、モジュールのコア機能に実行環境でサポートされないものを含むいくつかの標準ライブラリのモジュールは無効にさ れていて、それらのモジュールをインポートしようとするコードはエラーを投げるようになっています。
アプリケーションコードはPythonだけで書かれてないといけません。Cで拡張したコードはサポートされていません。
その他に、アウトバウンド通信がGoogleの定めたEmailかURL Fetch APIのみ、インバウンド通信が標準ポートを使用したHTTPかHTTPSのみでしかできない、ファイルシステムへの書き込みができない、サブプロセスを 作ったりrequest-responseループを行うような外部向けのコードは実行できない（例えばバックグラウンド処理やバッチ処理）、などのセキュリティの制限がある。
また、GoogleはDetastoreアクセス、Googleユーザアカウント、URLフェッチ、そしてEmailサービスに関するAPIを提供している。App Engineはsimplified web application framework(source)とDjango 0.96.1（Pythonのウェブフレームワーク）を含んでいる。ただしApp EngineのDatastoreはリレーショナルデータベースではなく、全てのDjango APIで利用できるわけではない。
このDatastore APIの裏側にあるのはGoogleのBigTabtle(source)だが、多くの一般的でシンプルなオブジェクト永続化APIも揃っている（DatastoreはリレーショナルではないとGoogleは言っているが、ORマッピングフレームワークもある）。
さきほどSQLは使えないと言ったように、みなさんの多くにとってDatastoreを使うのにはおそらく少々の慣れがいるかもしれません。これは大きな違いです。しかし、Datastoreを使うといろいろなことが簡単にできるようになるので、しばらくすればDatastoreがみなさんの中で大きく育つだろうと考えています。一例を挙げると、私たちのDatastoreはスキーマレス、つまり事前に全てを設計してスキーマを作らなくても、プログラムを 作りながら自由にプロパティやカラムを作ることができるのです。これは私たちが目指すウェブアプリを可能な限り簡単にするということにつながります。コー ディングを始めれば、データモデルもそれに従って出来ていくでしょう。
DatastoreはSQLとは違ったものですが、旧来のデータベースに対して期待するようなパワフルな機能もちゃんとサポートしています。 Datastoreは単一のプロパティに対しても複数のプロパティに対しても効率のいいクエリをサポートします。クエリの検索結果のソートもサポートし、 これには複数のプロパティを並び替え基準にすることも含まれます。書き込みに対するトランザクションもサポートされ、トランザクショングループを指定する こともできます。大量のエンティティをフェッチしたり作成したりするためのバッチ操作もサポートします。エンティティのプライマリキーを任意に操作するこ とも可能で、より効率のいいクエリを行ったりクエリURLを短くすることができます。
そして、DatasotreはSQLではありませんが、SQLのような問い合わせ言語をもっています。これはGQLと呼ばれ、クエリを組み立てるのを簡単 にします。GQLの考え方はjQueryやFBQLと同じで、基盤となっているのはSQLではないものの、みなさんがしたいと思うほとんど全てのことが出 来るようになっています。
おそらく気付かれたと思いますが、大きな特徴はDatastoreにはJOINがないことです。この理由はJOINが分散システムにおいてパフォーマンスを悪くする原因の一つになるためです。一台のマシンでなく多くのコンピュータや多くのハードディスクに分散しているシステム上でJOINを効率的に 行うのは大変難しいのです。
Datastore APIはトランザクションをサポートしているが、厳しい制限がある上にエンティティグループに縛られている。
全てのエンティティはいずれかのエンティティグループに属しています。これは一つあるいは複数のエンティティの集合で、単一のトランザクションでの処理対象となります。エンティティグループはApp Engineにグループ内のエンティティを分散システム上の同一箇所に集めさせます。トランザクションではエンティティグループに対するデータストア処理 をセットアップし、正常に進めば全ての処理がグループに適用され、エラーが起きた場合は全く適用されません。
アプリケーションがエンティティを作った時、この新しいエンティティの親として別のエンティティを指定することができます。親の指定がされると、その新しいエンティティは親エンティティと同じエンティティグループ内に置かれます。
親エンティティのないエンティティはルートエンティティになります。また、他のエンティティの親となっているエンティティが親を持つこともできます。あるエンティティからルートエンティティまでの親エンティティのチェインがそのエンティティのパスとなり、そのパスにあるエンティティ全てがそのエン ティティの祖先となります。親エンティティはエンティティが作られた時にのみ指定され、後で変更することはできません。
祖先として同一のルートエンティティを持つエンティティは全て同じエンティティグループに含まれます。同じグループ内の全てのエンティティは同一のデータ ストアノードに格納されます。単一のトランザクションでは、単一のグループに含まれる複数のエンティティを変更したり、あるいは新しいエンティティの親に そのグループのエンティティがなることで新しくグループのエンティティを追加したりします。
App Engineは特別な開発方法（例えばデータベースの代わりにBigTableをベースにしたDatastoreを使うなど）を強いるので、GoogleはApp Engine上のアプリケーションはスケールするのが簡単かつほとんど透過的にスケールできるメリットを強く主張している。
ウェブアプリが急に評判になると、トラフィックが急激に増加し、スタートアップ企業であれ大企業であれ、どんな規模のアプリケーションであれ、年に何度もデータベースやシステム全体の再設計するよう迫られます。Google App EngineはBigTableやその他のGoogleのスケーラブルなインフラ資産を利用した自動レプリケーションと負荷分散によって、ユーザ1人の状態から百万ユーザに対応する可能な状態まで簡単にスケールすることができるのです。
User APIはGoogle Account経由でユーザを認証したりログインさせたりでき、ユーザのニックネームやEmailにアクセスもできる。より詳しい情報はアプリケーション によってユーザから直接集めることになり、それらはデータストアに格納することができる。
URL Fetch APIはリモートサーバから情報を検索できる。これはHTTPおよびHTTPs経由でフェッチするが、GET/POST/HEAD/PUT/DELETEをサポートしているためRESTの機能をサポートしているように見えるだろう。
App EngineアプリケーションはMail APIを使ってEmailを送信できる。これは非同期で行われ、もしメールサーバが利用できない時は再試行を行う。
App Engine SDKにはApp EngineのPython実行環境をシミュレートするサーバが含まれていて、次の機能が使える。
- モジュールのインポート制限を再現し、認められたモジュールをインポートするヘッダのみ許可します。またモジュールは標準ライブラリやApp Engine Python環境に含まれるサードパーティのライブラリ、そしてアプリケーションディレクトリから検索されます。
- アプリのキャッシュ動作を再現します。
- ローカルファイルを使ってApp Engineのデータストアをエミュレートします。
- どんなEmailアドレスも受け付けるサインイン/サインアウトのページを使ってGoogle Accountをエミュレートします。
- ローカルマシンから直接URLフェッチを行うことでURLフェッチサービスをエミュレートします。
- 開発者の選択により、SMTPサーバを使う、あるいはSendmail設定を使ってメールサービスをエミュレートします。
見たところ、ほとんどのアプリケーション設定(source)はYAMLを使ってするようだ。
目的と競合
Googleの発表の中には彼らの目的が述べられている。それはウェブアプリケーションをより簡単に作りデプロイしスケールすることだ。
私たちがApp Engineを作ったのは、もっと多くのウェブアプリが作られてほしいからです。私たちが気付いたのは、現時点で一つのウェブアプリを作るのはかなり大変だということで、一番シンプルなウェブアプリケーションでさえデプロイするまでには多大な課題やこなすべきタスクがあります。まず当然のことながらアプリのコードを書く必要があります。
しかしその後にはApacheウェブサーバの設定やスタートアップのスクリプトを書いたり、SQLデータベースをセットアップして全てのテーブルを 作り、パスワードを設定し、トラフィックとログを見れるようにモニタリングシステムを構築し、新しいバージョンのコードをどのようにアップするか、などなどをする必要があります。
これらは技術的な課題です。そしてこれらのシステム管理作業を行った後には、別の課題が持ち上がります。物理的なマシンにしろ仮想的なマシンにし ろ、アプリを動かすマシンを実際に見つけに行かないといけないのです。これにはお金がかかります。ごく小さなアプリであっても、たとえ1週間に数度しか使 わないアプリであっても、それを古臭いホストプロバイダで動かすためには結構な額を前払いしないといけません。
つまりこれは金銭的あるいは物理的な課題です。そして、全てのセットアップと作業が終わり、それをテストする場所を見つけ料金を支払った後、今度はまた別の課題が持ち上がります。アプリが大きくなるのにあわせてシステムに関する全てのことをメンテナンスする必要が出てくるのです。マシンがクラッシュした、 設定に間違いがあった、ハードディスクが壊れた、トラフィックが増大した、データベースのパーティションを区切りなおす、追加のマシンをセットアップす る、などなど。アプリが大きくなるにつれて全てを保ち続けるのは骨の折れることです。
私たちはこういった苦労をApp Engineで失くそうとしています。私たちが良くしようとしているのがこれらの問題なのです。
人々は既に他の目的について思いを巡らしている。多くの人がAmazonとMicrosoftがクラウドコンピューティングとウェブサービスで将来の競合 するだろうと予測していて、特にApp EngineとAmazonのEC2(source)、S3(source)、SQS(source)そしてSimpleDB(source)のウェブサービス群とはよく比較されている。
-
O’Reily Readarではこう書かれている(source)。
Amazon Web Servicesがうまく行き始めた今となっては時間の問題でした（次はMicrosoftだという推測はかなり確実なものでしょう）。App Engineと比較されるのは明らかにAWSですが、この２つは同じ類のものではありません。Amazonは汎用的なコンピューティングプラットフォームに用いることが可能な異なるサービス群をリリースしました。しかし、これらは協同して動作するものの、まとめて一緒には提供されていません。
一方App Engineはほぼ文字通りウェブアプリケーションに動力を提供するエンジンとなっています。App EngineはAWSが提供するのと同じ多くの機能を単一のパッケージにまとめています。S3にあたるストレージ、EC2にあたる自動スケーリングと処理能力、SimpleDBにあたるデータストアが一つになっているのです。またApp EngineはAWSにはないものも提供しています。Pythonランタイム、Google仕様のAPI、そしてなによりサービスをある程度までフリーで使えることが大きいでしょう。
-
VentureBeatは このような記事を載せている：“Google App Engine readies for brawl with Amazon（Google App EngineがAmazonと闘う体勢に入った）”(source)
人々はMicrosoftもRay Ozzie氏のMesh(source)やSQL Server Data Services(source)によって同じ方向へ向かっているが、時既に遅しと考えているようだ。
- Network world：“Google One-Ups Microsoft Again（MicrosoftがまたGoogleに先を越された）(source)
- ZDNet：“Google App Engine: When will Microsoft field a competitor?（Microsoftはいつになったら競争を始めるのか？）(source)
別の視点から見ると、一部の人々は今回のことでGoogleはベンチャーインフラを形成し、企業買収に関して一歩先じたスタートを切ったと考えているようだ。
- Business Weekでは(source)、GoogleとAmazonとの競争という見方で抜け落ちるのは、スタートアップ企業にGoogleのインフラ上でアプリケーションを開 発させることでGoogleが「人々がどのようなアプリケーションを望んでいて、どのような問題を克服しないといけないかということが良く見えるようになるだけでなく、Googleが買収したいと思えるような確実に成功するであろう新しいスタートアップ企業を俯瞰することができるようになる」ことだと述べ ている。
- さらにZDNetでは(source)Googleが買収にかける金額を節約できるようになるだろうと付け加えている。「既にGoogleテクノロジを使っている企業を Googleが買収することになったら、どれだけの時間と労力が節約できるか想像してみましょう。」
- GigaOMでは(source)“GoogleがAmazonのランチを食べる方法”とKevin Kelleher氏が呼んだやり方について「この手の特売サービスはスタートアップ企業をGoogleの待ち構えるドアに誘導し、そのことでGoogle は最も新鮮なアイディアにアクセスでき、いつでも盗み見できる才能ある起業家たちのプールを得るのです」と書いている。
-
Kevin Kelleher氏はそのGoogle投資方法をこう述べている(source)
このインタビューで私が主張した考えは、AmazonはIntel CapitalのようなVC企業がしているのと同じことをしている、つまり、後で役に立つあるいは買収するスタートアップ企業に投資しているということでした。
その役員の反応は、Amazonはそんなことは全くしてない、ウェブサービスではそんなことはできっこない、というものでした。私は口には出しませんでしたが内心こう思っていました。もしあなたがそうしないなら、誰かがそうするだろう、と。
今になってGoogleがそれをやっていると言う人が出てきました。これはGoogleの貴重な社員がデスクを片付け、新しいスタートアップを興した時、 その才能をGoogleに繋ぎ止める唯一にして最良の方法です。そしてAmazonの戦略指向・利益指向のお株を奪う卓越した方法なのです。
フィードバック、分析、参照先
- その他の分析はウェブ(source)やブログ(ブログ・英語)のいたるとこにある 。
- 最近Googleが買収した(source)JaikuはApp Engineを使うと発表している(ブログ・英語)。
- TechCrunch(source)
- news.com(source)
- Farhan Mashraqi氏は、blist（ウェブベースのデータベースおよびフロントエンド）(source)と同じようにPythonを広める後押しになると言っている(source)
- Fuzzmeister氏はApp Engineは大きなインパクトがあり、「このことはウェブサイトをホストし稼動させる方法を根本的に変えてしまうことにつながる可能性がある」とDiggでコメントしている(source)
- Wayne Pan氏(source)はフリーであることが一番のニュースである、またApp Engineが真に牽引力を得るにはPython以外の言語と外部サービスが必要になると述べている
- Nate Koechley氏(ブログ・英語)はGuido Van Rossum氏（Pythonの製作者）がGoogle App Engineのチームメンバであることを指摘している
- FaceReviews(source)にはRobert Scoble氏がPownce（Twitterのようなサービス）の人たちとのトークを行った際に彼らはそれほど凄いことだと思ってないと語ったことを書いてある
- Adnan氏(source)はApp EngineのAPIについて記している
- Technosailorのこの記事(source)を書いた人物は、App Engineに何のイノベーションも新境地も見出せないらしい。どうも疑り深い人のようだ。
- App Engineに関するフォーラムでは既に交流が行われている
- Google App Engineについてより知りたい人には以下のサイトを紹介する。
原文はこちらです：http://www.infoq.com/news/2008/04/google-app-engine-simplifies-web
No comments
スレッド表示 返信