クラウドエキスポ
今月12日から14日まで東京ビックサイトで開催されたクラウドEXPOへいってきた。
参加企業も来場者も多く、早々と秋の第2回目が決定したようである。やはり「クラウド」というキーワードは勢いがついており、ようやく日本でもビジネスレベルでのクラウドが始まるなという感じであった。
その反面、クラウドという言葉が非常にあいまいな定義であると同時に、サービス化が進んでいる英語圏とではだいぶ開きがあるという日本の実情も垣間見えた。
何をもってクラウドとするかといえば次々と言葉が出てくる。「仮想化」「伸縮性」「所有から利用へ」等など。しかし、「ASPと何がちがうの？」といわれると、言葉が少なくなる。既存のサービスで、「データの保存先にAmazonが選べるようになりました」といわれても、正直困る。
「所有から利用へ」というフレーズはASPの時代のまんまなのでそのままにしておくが、「仮想化」がクラウドだといわれると、何かひっかかる。本当に仮想化がクラウドの本質なのかと。
確かに、仮想化はクラウドの中核技術である。それによってもたらされるコストカットもユーザーの最大の関心事だ。しかし、コストカットは仮想化によってもたらされたというよりも、技術的な部分も含めて「企業努力」の賜物だ。別に仮想化でなくてもできる。要は仮想化が「サービス提供側の理屈」に聞こえるのだ。
質問を変えよう。「ASPではできなかったことは何か？」
やはり大規模なインフラと仮想化を駆使した「伸縮性」だと考える。特にコンシューマー向けのソリューションはアクセスの予測が難しい。アクセスが増えれば仮想化を使ってスムーズにリソースを伸縮し、莫大な初期投資をかけずとも、従量制の料金でサービスが開始できるという点では利用者側のメリットも大きい。
EXPOでIaaSのサービスを提供している企業をいくつか回ったが、EC2のような自動でリソースを伸縮するようなサービスを提供している企業は皆無だった。コストカットはもちろん、機器の調達が要らない、数分でホストを追加できる等、仮想化のメリットはあるにせよ、その追加自体が手動ということはアクセスの状況に注視し続けなければ対応できない。
よく、クラウドを3つのレイヤーに分ける。英語圏では既にそれぞれのレイヤーに巨人がいる。SaaSでは、Google Apps、Office Live、SalesForce等、PaaSではGoogle Apps Engine、Azure、IaaSではAmazonなど等。「仮想化」だけではとても太刀打ちできそうにない。仮想化とコストカットだけに安易に向かうと、自らの首をしめるような結果にならないか。
クラウドはまだこれからだ。その「成長ののりしろ」もたくさんある。クラウドと称した「安価な専用サーバー」も有効なソリューションのひとつではあるが、「クラウドらしさ」を活用した次のステップが重要だと感じさせられた。
Google Apps Marketplaceのよくある勘違い
Google Apps Marketplaceは、今年3月にGoogleが発表したGoogle Apps向けのアプリケーションやサービスを販売するサイトだ。
アプリケーションをクリックひとつで自社ドメインのGoogle Appsへインストール・統合することができ、今後のサービス販売の場としても注目するべきサイトのひとつであろう。
Google Apps Marketplaceのよくある勘違いとして、「Google Appsに統合されるわけだからGoogle Apps Engineで開発する必要がある。」というのがある。（私もはじめはそう勘違いしていた・・）
結論から言えば「Google Apps Engineである必要は全くない」のである。それどころか、サイトを検索するとGoogle Appsとは一見関係のないようなものから、インストール代行などアプリケーションではないものも売り出されている。（関連サービスということなのだろう）
Googleのドキュメントによれば、Marketplaceに登録するには以下の要件を満たしてくれとある。
- OpenIDによるシングルサインオンを実装してください。
- アプリケーションマニフェストを書いてください。
- ユニバーサルナビゲーション（Google Appsのページ一番上にあるメニュー）をつけてください（どうやらオプションのようだ）
- Google Appsのメールやカレンダーと連携する場合はGoogleDataAPIを使ってください。
以上である。
３と４はオプションなので実際は１と２が必須項目である。
言い換えれば「自社のサービスにOpenIDを実装すれば、すぐにMarketplaceに出展できる」のである。
もちろん、OpenIDの実装のほかにもマニフェストで設定するページやそのたGoogle Appsとの連携などに若干の開発は必要であろう。
要は、すでにユーザーに提供しているASPやサービスがあれば、ある程度の開発だけでMarketplaceに出展できるということだ。
わかりやすい例として、ZoHoがある。
SOHO向けの機能（本当にたくさんある）をクラウドで提供する会社だが、彼らのサービスはMarketplaceでも販売されている。彼らは既にあるサービスをOpenID化して、Marketplaceに提供しているのだ。試してみると（無料版もある）、認証や管理はGoogle Appsと連動しているが、実際のサイトでは彼らのもともとのサービスと全く代わりがない。（それはそれでGoogle Appsとの連動が薄いと評価されているが）
整理すると以下のようになる。
Google Apps Marketplace
- Googleが決済代行をするGoogle Appsユーザー向けのアプリケーション及び付帯サービスのコマースサービス。
- 認証の連動など、いくつかの条件がクリアできれば、稼動要件などは問わない。
- 提供するサービスはアプリケーションである必要もない。
Google Apps Engine
ここまで書くとお分かりだろうが、Google Apps Engineで開発したアプリはMarketplaceですぐ使えるというものではなく、あくまで「自社ドメインで稼動するWebアプリをGoogleのインフラで作った」という位置づけである。
Marketplaceとはあまり関係ないというか、むしろ別のサービスと考えたほうがすっきりする。
Google Apps Engineは独自ドメインのSSLが不可（いろいろと組み合わせれば回避可能だが）だったり、メール送信や外部のURLアクセスに件数制限（有料設定でコントロール）があるなど、サンドボックス的な制約も多い。しかしながら、数百万ユーザーのアクセスでも耐えるであろうGoogleのインフラを考えれば非常に魅力的だ。
専用サーバーなどを自由にカスタマイズして作るWebアプリも魅力だが、ユーザーの増加が読めないコンシューマー向けのサービス等では、拡大に伴うコストは非常に高くなる。そういう場合の選択肢としてGoogle Appsなのだと考える。（過去にサービスを立ち上げる前から「100万ユーザーでも耐えられるようにつくってくれ」と頼まれたことがある。まだサーバー2台で稼動しているが・・）逆に言えばアクセスや用途が限定されているのであれば専用サーバーのほうが有利なケースも多い。
実際の落としどころで言えば、「用途や内容によってGAE、AWS、専用サーバーを組み合わせて実装する」というところであろう。（言語の選定やライブラリ・フレームワーク等は非常に悩ましいところだが）
P.S. AMAZONでもメールの送信数には制限があるようですね。やっぱりそうだよね（笑）
app-engine-patchの終了とDjango-nonrel
Google AppsでDjangoを使うためのパッチ集であるapp-engine-patchが、バージョン1.0.2.3をもって開発終了した。
といっても完全になくなったわけではなく、Google Apps +Djangoの別のプロジェクトであるDjango-nonrelへ引き継がれた。
django-nonrelではapp-engine-patchのように「djangoがGAEで動くようにパッチを当てる」という方向性とは違い、「Djangoで非リレーショナルDBをサポートする」というプロジェクトで、そのDBの中のひとつにGoogle Apps Engineのモデルが含まれているというもの。GAEのモデルのほかにもMongoDBやAmazoneのクラウドサービスのひとつであるSimpleDB等がサポートされる予定である。
実装方法としてはbackendtemplateと呼ばれるデータProxyのような役割を果たす低レベルAPIのレイヤーをモデルに入れるという方法。パッチがでかくなりすぎてしまったapp-engine-patchよりは正しい方向性だと思われる。
まだ実装されたばかりでこれからという感じだが、GAEだけでなくAWSでも使えるとなれば「Django LOVE！」な人は要チェックだ。
April Fool
ネット上のあちこちでApril Foolネタが掲載されているが、KLabのニュースリリースは大笑いしてしまった。
GAEでの言語選択
リリース当初は様子見という感じでみていたGAEも、そろそろ本気で取り組もうということでこの1ヶ月、改めて最新バージョンの検証やテスト等をおこなってきたが、現時点での結論は以下のとおりだ。
「Apps Engineに最適化されたPythonのフレームワークをつかえ」
おのずとKayフレームワークなのだろう。（腕に覚えのあるひとならフレームワークをつくってもいいのだが）
Java使いであればいろいろとフレームワークを使いたいだろうが、はっきりいって「遅い」のである。得てして重量級のフレームワークが多い中、選択肢としてはSlim3くらいであろう。このあたりに関してはその作者でもあるひがやすを氏もブログで述べている。id:higayasuo:20100319:1268984735
ひが氏が指摘しているようにJavaはその構造上、SpinUp, SinDownでインスタンスを生成するまでの時間がかかることがネックとなっている。
上記の理由からも、現時点でGAEJ＋jRubyやGAEJ＋Quercus(PHP)は論外ということになるだろう。（Amazonへどうぞ）
誤解のないように言うが、Javaが使えないのではなく「GAEでJavaはまだ発展途上だ」と考えている。速度や安定性の問題は今後GAEJがアップグレードしていくなかで解決されていくだろう。フレームワークもひが氏がSlim3を中心にGAEにコミットしている（と勝手に煽る）ので、今後改善されていくだろう。
djangoの記事でも書いたが、SpinUp+SpinDownの時間の問題や、データモデルが根本から変わるなど、クラウド開発ではこれまでとは違う「常識」が必要になるとあらためて感じさせられた。
GAEJ + Struts2
GAEJでStruts2を試してみようと環境構築。
用意した環境は以下のとおり。
・Eclipse3.5
・Google Plugins for Eclipse (3.5)
・Struts 2.1.8
Eclipseはそのままインストールで展開。
起動後に「ヘルプ」「新規ソフトウェアのインストール」、ダイアログの作業対象に以下のURLを入力。
http://dl.google.com/eclipse/plugin/3.5
あとはWizardにしたがって進めるとインストール完了。
Eclipse再起動後、新規プロジェクトでGoogleAppsのプロジェクトを作成。
Strutsで必要なライブラリをwar/WEB-INF/libへコピー
・commons-fileupload-1.2.1.jar
・commons-logging-1.0.4.jar
・freemarker-2.3.13.jar
・ognl-2.6.11.jar
・struts2-core-2.1.6.jar
・xwork-2.1.2.jar
上記6つが最低限必要。コードビハインドを使うならstruts2-codebehind-pluginも追加。
簡単なアクション、JSPを書いて実行してみる。
JSPにエラーが発生している。そうか、JDKが必要なんですね。JDKをインストールして
JAVA環境を設定。
今度はXalanがないというエラーが発生。Apacheプロジェクトからダウンロードしてきて
Xalan、Xercesのライブラリをlibへ追加。
ようやく動作確認。
久しぶりにJavaを触って、頭がすっかりLLになってしまっていることに気がついた。
Google Apps Marketplace
Googleが開発したGAEのソリューションを販売できる仕組み「Google Apps Marketplace」（以下GAM）を開始している。
Google Appsを利用しているユーザーはクリックしてドメインを入力するだけでGmailやGoogle Calendar等と高度にインテグレートされた機能を利用できるというもの。
たとえば以下のような機能が販売されている。
myERP.com
CRM, Sales, Projects, Purchasing, Inventory, Accounting
1アカウント29ドル/月、2Userまで無料
eFAX
メールによるFAXサービス
16.95ドル/月
その他ワークフロー関連からビジネスパック、独自ドメインApps環境設置代行まで様々。
利用料金は以下の記事によればアプリの登録に100＄、その後販売価格の20％をGoogleが徴収する仕組みのようだ。
C-NET
Google announces business app store for Google Apps
Developers will have to pay a one-time $100 fee to list their applications in the store, and Google will get a 20 percent cut of all applications sold through the store
iPhone大躍進の理由の1つにAppStoreがあげられると思うが、ソフトウェア開発をワールドマーケットへ直結させた成功パターンがビジネスモデルとして認知され、GAMもその流れできたというところか。App Storeはいわゆるエンタメ系が多いが、GAMはその性格から業務系やグループウェア系等、ビジネス向けのアプリが占める。
日本向けのサービスはまだ探せなかったが、今後増えていくものと思われる。イントラネット系のアプリを開発しているならマーケットとして注目すべきだろう。
