Google App EngineのDataStoreインデックスの削除

Google App EngineのDataStoreに一度作成したインデックスを削除するには、下記のコマンドを実行します。
appcfg.py vacuum_indexes [プロジェクトパス名]
例:appcfg.py vacuum_indexes “C:\Users\narita\workspace\sample”
ただしこのコマンドはプロジェクトで作成したインデックスのうち、index.yamlに登録されていないインデックスを、すべて一括して削除してしまうので注意が必要です。

Google App EngineでCookieを使う

Google App EngineでCookieを使う場合には、Pythonの提供するCookie関連クラスを使うことは出来ない。変わりに「self.request.cookies」と「self.response.headers.add_header」を使うことになる。
Cookieの書き込みには「self.response.headers.add_header」を使用する。以下のようにheadersコレクションを直接に追加する以外に無いようだ。

myCookie = 'name=%s; expires=Tue, 1-Jan-2030 00:00:00 GMT;' % myName
self.response.headers.add_header('Set-Cookie', myCookie )

Cookieの読み込みには「self.request.cookies」を使用することが出来る。以下のようなコードで読み出すことが出来る。

myName = self.request.cookies.get('name', '')

Google App Engine 習作、オセロゲーム

Google App Engineを使ってみながら、オセロゲームを作ってみた。本当ならソースコードもと思ったが、弄ったり、戻したりを繰り返した汚いコードなので非公開です。
URLから適当に名前を入力してログインすると、対戦相手が現れるまでの待機画面になります。ほかの誰かがゲームにログインすると、見慣れた升目が表示されて、ゲームスタートです。

Google App EngineでのセッションID生成

意外なところで嵌るものだ。
Pythonでは乱数生成用のエンジンを何種類か積んでいる。Wichman-Hill(WichmannHillクラス)と、メルセンヌツイスタ(randomクラス)、OSの提供する乱数ジェネレータ(SystemRandomクラス)から選ぶことが出来る。セッションIDに使用するなら、予測不可能でビット数の多い乱数を生成できるSystemRandomクラスを選択したいところなのだが、Google App Engineでは対応していないらしい。セキュリティ上重要なハードウェア乱数が提供されていない辺り、本当に片手落ちだと思う。
デバッガ上だと普通に動くので、気が付くのが遅れた。
・・・と言うわけで、メルセンヌツイスタ(randomクラス)で生成する以外の方法はないようだ。

「クラウドはメリットよりリスクが大きい」…

「クラウドはメリットよりリスクが大きい」、IT専門家の45%
うん、まぁ、そうだよね。
PaaSやSaaSに限れば、サービスの継続性について、他社に依存する事になる。サービスが中止されたときに他社のサービスに移りたいと思っても、アーキテクチャに互換性が無いため、設計レベルからやり直さなければならない。これってかなり大きなリスクだよね。
HaaSやIaaSについては他社へのサービスの乗り換えも可能だけど、これだってクラウドのスケーラビリティの高さに依存した設計をしていたら、クラウド以外の環境には逃げようがないのだ。自前でハードウェアを用意してもいいけど、損益分岐点は跳ね上がってしまうもの。
結局のところ、短期集中でスポット的に利用するシステムじゃないと、なかなか業務でクラウドに載せると言う訳にはいかないよね。

Google App Engineの弱点はバックグランドの処理を作れないこと

Windows Alureの開発経験はまだないけど、セミナーなどで聞いている限りでは、Google App Engineの最大の弱点はバックグランドタスクを作れない事だなぁ・・・と実感する。
Google App Engineにも定周期で処理を起動するcronはあるのだけど、最短でも一分周期が限度。基本的にはCGI経由で呼び出されるのと同じなので、1~2分以内に処理を完了しないと異常終了してしまう。したがってUIに相当する処理と、バックグランドで動作する処理を即時に連携させるような事はできない。
これがWindows Azureならバックグランドで処理をするプロセスを常駐させておき、UIに相当する処理と通信させることができる。
この差が結構大きくて、ログインしている複数のユーザ間でリアルタイムのデータ交換をおこなうようなアプリケーション・・・具体的に言うとゲームとかチャットとか・・・を実装しようとすると結構な問題になる。Data Store上の一つのエンティティにデータを集中させて、そこでトランザクション制御をおこなうぐらいしか手が無い。もちろん、こんな事をすればスケールアウト出来るメリットを放棄する事になるし、ユーザー数にも大きな制限を受ける事になる。
これがWindows Azureならバックグランドで調停をおこなうタスクを複数常駐させて、UIに相当する処理からの要求を順番に調停しながら処理する事も出来るのになぁ・・・。それとも私が見落としているだけで、Google App Engineなりの良い実装方法があるのだろうか?

クラウドってなーに?と言うのを今更ながら整理してみる

クラウドを使ったサービスは知っているけど、クラウドが何なのかわからない・・・という人は多いと思う。要は冗長化した複数のハードウェア上で動作しており、今この瞬間にどのハードウェアで動作しているかを意識しないシステムの事だ。理解を難しくしている理由は、どのレイヤーでサービスするかとか、どの物理ハードウェアで動いているかを何処まで意識させるかによって、さまざまな亜種があり、その境界が明確ではない事だ。
まず一つ目の軸として、パブリックよりか、プライベートよりかという話がある。たとえばGoogle App Engine(GAE)はパブリックなクラウドです。GAEは世界中の何処に設置されたハードウェアで動いているのか、ユーザーはまったく意識できません。Windows Azureはもうちょっとプライベートよりです。Azureはハードウェアがアメリカ大陸にあるのか、アジアにあるのか、EUにあるのか、ある程度意識する事ができます。NTTのBiz Cityはさらにプライベートよりです。Biz Cityのユーザーは何処の建物の中で動いているのか意識する事ができます。もっともプライベートよりのクラウドは、ハードウェアを自分で購入して自分で管理します。自分の作ったアプリケーション以外が動く事はないでしょうけれど、複数のハードウェアに冗長化されており、どのハードウェアで動作しているかは意識しないので立派なクラウドです。
二つ目の軸がどのレイヤーでサービスを提供するかです。よりハードウェアに近い方から、HaaS、IaaS、PaaS、SaaSと呼ばれています。HaaSの場合提供するレイヤーはハードウェアです。仮想化されたハードディスクやCPUを提供します。IaaSで提供するレイヤーはOSです。仮想化されたWindowsやLinuxなどの実行環境を提供します。PaaSで提供するレイヤーはミドルウェアです。GAEの用にクラウド固有のミドルウェアを提供する場合もあれば、EC2の様に既存のミドルウェアを提供する場合もあるし、Azureの様に両方を提供する場合もあります。SaaSの場合にはそれ単体でも完成されたサービスを提供します。
この二つの軸に明確な境界線はなく、様々な切り口でサービスを提供しているので「クラウドとはこういうもの」と言う概念をつかみにくいのです。
cloud_map
クラウドにすると何故コストを下げる事ができるのか?
それはハードウェアの稼働率を限界近くまで高める事ができるからです。一般的なサーバーではCPU負荷が一瞬100%になるかもしれませんが、普段はずっと低い状態が続きます。この間に他の処理を動かせば稼働率が高くなります。同じハードウェア価格で、より多くの作業をさせる事ができれば、単価を安くする事ができます。
従来、故障によって停止する確立を下げるには、フォールトレトランスに対応した効果はハードウェアを揃える以外にありませんでした。故障時には他の正常なハードウェアに処理を移動させる事で、安価なハードウェアでも故障により停止する確立を下げる事ができたのです。
ユーザーとしてクラウドを使うメリットは安いだけではありません。一般にIT投資は固定費なのです。それもハードウェアの減価償却がすむ5年後を見据えて、現在必要なスペックよりも遥かに高いスペックのハードウェアを揃えなければなりません。ところがクラウドなら、必要なときに簡単にスペックの高いハードウェアに置き換える事ができるのです。これはIT投資が固定費ではなく変動費になりうる事を意味しています。店舗が増えて売り上げが増えるとIT関連の費用が増えますが、運悪く店舗が減って売り上げが減るときにはIT関連の費用も減るのです。
私自身はクラウドの本命はHaaSやIaaSだと思っています。PaaSやSaaSの多くは提供業者独自の規格に乗っ取ったつくりが多いのです。この場合、独自にアプリケーションを開発しなくてはならないため初期コストが高くつきます。また、業者が撤退すると開発したアプリケーションを捨てるしかありません。その点でHaaSやIaaSは一般的なOS上で動作するため、将来事業者が撤退しても自前のハードウェア上で動かすなど、どうとでも対応を取れるのです。
ですが残念な事に、今のところHaaSやIaaSよりのサービスは出揃っていません。2010年の秋ごろに、各社サービススタートを予定しているようなので、それまで情報収集しながら楽しみに待つ事にしましょう。

Google App EngineでDjangoメモ

Google App EngineではDjangoというWEBフレームワークを使った開発を行えます・・・そのはずです。とりあえず情報収集中で実現できていないけど、そのメモなどを。
Google App EngineでDjangoを使うには、いくつかの方法があるらしい。
1.Google App Engine Helper for Djangoを使う。
2.Use Django on App Engineを使う。
3.Google App Engine SDK標準のDjangoを使う。
4.標準のDjangoをGoogle App Engineで動かすべく自分で設定する。
3.が理想的な気がするが、標準のGoogle App EngineだとDjangoのver 0.96が起動するらしい。ver1.0やver1.1を動作させるには設定を変更すればよいらしい。でもGoogle App Engineに標準でインストールされているDjangoは古くてセキュリティホール持ちらしい。したがって、DjangoまるごとGoogle App EngineにUpしないと実用には耐えないようだ。
よって最新のDjangoを落としてきて、1.のGoogle App Engine Helper for Djangoを使うか、Use Django on App Engineのパッチを充てるのがもっとも現実的な解となるようだ。

Google App Engineで日本語を使う

日本語を有効にする
Google App Engineのソースコードに日本語を記述すると、下記のようなエラーが表示されます。Google App Engine Launcherでは正常に動作してしまうので、はまりどころです。

: Non-ASCII character 'x93' in file /base/data/home/apps/mikahosi-1/1.338233447893773564/helloworld.py on line 11, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details (helloworld.py, line 11)

日本語で動作させるためには、下記の一行をソースコードの先頭に記述します。

# -*- coding:utf-8 -*- 

UTF-8以外の日本語コードはGoogle App Engine RuntimeとPythonの都合で通らないらしいです。
またPythonで日本語定数文字列を記述するには下記のように先頭にuを追加する必要があります。

text = u"日本語を出力"

Google App EngineをDeployしてみる

Google App EngineにApplicationを作る
最初にGoogle App EngineにApplicationを作成します。Google App Engine LauncherのDashbordボタンをクリックしてGoogle App EngineのWEBサイトを開きます。
AppEngine1
Preiewの画面からCreate An Applicationをクリックして新規にアプリケーションを作成します。この時に指定するApplication Identifierは、ApplicationのNameと一致している必要があります。このアプリケーションの例ではmikahosi-1となります。Application Titleも必ず入力しなくてはなりませんが、こちらは任意の文字列で構いません。
Google App EngineにDeployする
Google AccountからApplicationを作成したら、Google App Engine LauncherのDeployボタンをクリックします。下図のログオン画面が表示されますので、ログオンアカウントパスワードを入力してログインします。ここで項目名がmailとなっていますが、指定するのはメールアドレスではありません。Googleのアカウント名(Google Mailと@より前の部分)を入力します。メールアドレスを指定するとログインできません。
AppEngine2
初めて使用する場合には、CAPTCHA認証を要求される場合があります。その場合にはDeployment To Googleのコンソール表示にURLを表示します。ブラウザで指定されたURLに接続して、CAPTCHA認証を行ってください。
AppEngine3
以上で無事にGoogle App Engineに作成したアプリケーションをアップロードできたはずです。Google App EngineのWEBサイトにて割り当てられたURLに接続してみてください。
ちなみに作成した掲示板サンプルは下記のURLにアップロードしてあります。
http://mikahosi-1.appspot.com/