Googleクラウドの理想型は、昼の太陽（ソーラパワー）で電気エネルギーを蓄電し、夜（月は夜の比喩）月の出ているときにデータセンターのCPUを動かし、昼より気温の低い夜の外気でCPUを冷やすのだ。そしてそのコンピュータパワーを地球の裏側の昼の世界へインターネット網を介して送り出す。これがGoogleのMoon Cloudの基本コンセプトだ。
人類のエネルギー革命は、化石燃料からどれだけ効率よく電気エネルギーを取り出すかという歴史と、どれだけ効率よく電気エネルギーをA地点からB地点に運ぶか、ということだ。残念ながら今の技術では、電気を損失させず地球の裏側に送り出すことも無線で送ることもできない。（R&Dの範囲では出来るが実用的でない）なぜエネルギー損失が起きるかというと電気エネルギーがアナログエネルギーであるためだ。音楽がレコード（アナログ）からCD（デジタル）に変わったように、電気エネルギーをアナログからデジタルに変換してしまえば、地球の裏側に1秒以内にエネルギーを送り出すことができる。
～中略～
夜は昼より気温が低い。
たったこれだけの理由だ。」
月を追いかけるGoogleのクラウド – 渡部薫 @sorahikaru : アゴラ
ひたすら壮大な計画ですね。
少し前からGoogleデータセンターの最もコストがかかるものは、近いうちにハードウェアではなく電力になると言われていましたが、ここまで考えているとは。
Googleのサービスは色々あるけれど、私が関心の高いGoogle App Engineを例に考えてみると、この話も納得させられます。
クラウドのベンチマークを取ったら Google App Engineは遅くてスケールしにくいという話があります。
余談だけど、セールスフォースのサーバは全部で3000台しか無いらしいです。凄いですね。
今GAEのデータストレージは調子悪いとか、測定方法による有利・不利もあるかもしれませんが、GAEが遅いと言うのは、現時点では概ね正しい認識なのかもしれません。（コスト当りの性能で算出すると結果が変わりそうですが）
GAEのアプリケーションは、ちょっとでもアクセスが無いとスピンダウンするとかの制限やクセがあり、何も考えずに「Googleのインフラが使えるんだからさぞかし速いんだろう」と思って開発していると、期待を裏切られます。
逆に、データベース・トランザクションはRDBMSの得意技であり、プログラミングの技術も枯れています。
要はプログラムやデータの設計そのものを、今までのやり方と変えないといけないのがGAEのKVSです。
AWSやForce.comがRDBMSによるデータ永続化という既存のパラダイムの延長であるのに対し、GAEとそのデータストレージ、およびデータセンターの設計思想は「圧倒的な規模での全体最適によるコスト削減」なんだと思います。
GAEは既存技術より質がやや劣り、安い。最初はコンシューマ向けだけど、コスト面を武器に、少しずつエンタープライズ分野を侵食していき、最終的に品質面をも追い越して、既存技術を駆逐してしまうとすれば、イノベーションの典型的な特徴と符合します。
どっちが良い・悪いという議論には余り意味は無いけど、好き・嫌いでいうと、やっぱりGAEの方が好きだなぁ。
slim3 で、既に存在するModelクラスのStringフィールドに、文字列を沢山保存しようとすると
IllegalArgumentException が発生して保存が出来ませんでした。
これはApp Engineの仕様で、通常Entity オブジェクトにプロパティとして格納される Java 文字列は 500 文字まで、となっています。長いテキスト文字列(500バイトより大)は Text 値として保存することができます。
これを私が忘れていただけでして、当然Slim3でもjava.lang.Stringでは500文字以下じゃないといけません。
で、ここからが本題なんですが、Slim3 Datastore では、長いテキスト文字列を Text 値として保存する場合、Stringフィールドを定義するときに @Attribute(lob = true) アノテーションをつけておけば、内部的にText型に適宜変換してくれる様です。
つまり、
private Text bodyOfPage;
こう書くこともできるし、
@Attribute(lob = true)
private String bodyOfPage;
こう書くこともできる。
後者の方が、バリデーションチェックのコードとかを直さないで良いので楽だな、と思ったものですから、当然、「@Attribute(lob = true)」を追記しました。
すると、org.slim3.controller.HotReloadingRuntimeException が発生して、アプリケーションが動かなくなってしまい、暫くオタオタしました。
これも冷静に考えれば判る話でして、既に存在するModelクラスで定義されたデータが、データストレージに存在する訳ですから、型の不整合が起こる訳です。
今回はローカルでの話でしたので、データストレージ
war/WEB-INF/appengine-generated/local_db.bin
war/WEB-INF/appengine-generated/datastore-indexes-auto.xml
をさくっと削除して、解決しました。
忘れないように、メモしておきます。
GAE 上でWordPressを動かす – ＠IT
意欲的な取り組みですね。
GAEでWordPressを動かす必要性については兎も角、こういった試みはGAEユーザの裾野を広げる事になると思うし、個人的に好きです。
DBをMySQLからSQL4Gに変更するにあたり、WordPress側で若干のコード修正が必要。
また、日本語表示は出来ない。
WordPressにでは日本語を含む場合リソースファイルとして別ファイルに持つ形式になっているそうな。知りませんでした。
それはそうと、GAEのデータストアの負荷が上がっているらしい。
Google App Engine Blog: Datastore Performance Growing Pains
現在タダで使わせて頂いている身なので偉そうに言えませんが、Google信者として今後もGAEの普及・啓蒙に努めますし、いつの日かWEBサービスをヒットさせたりしますから、中の人にはがんばって頂きたい。
Nakajiman Software Blog: OpenSocial Pages という新しい取り組みの紹介です
OpenSocial Pages は Google App Engine for Java 上で動作する OpenSocial コンテナです。OpenSocial Pages は App Engine 上のアプリケーションに OpenSocial を組み込んだり、OpenSocial の上にアプリケーションを構築する、その元ネタとして提供するものです。
OpenSocial Pages は App Engine 向けに実装した完動品です。ソースコードを提供していますので、手元の環境でソースコードをビルドして App Engine にデプロイするだけで、その動作を確認できます。OpenSocial Page のソースコードは、次のサイトからダウンロードできます。
ざっと概略が書いてありますが、何やらよさげな感じがします。
これは時間ができたら是非試してみたいです。
これから作るWEBサービスに OpenSocial をどう取り込んでいくか。
これはこれで、面白い取り組みですね。
備忘録としてメモ。
頑張って欲しい気持ちでいっぱいです。
Kotan の開発状況 – やさしいデスマーチ
１つはローカル環境でのデータ作成、主にテストデータを簡単に作成したいという所から開発を始めています。
２つ目の用途としては本番環境のデータを引き抜いて、ローカル環境のDatastoreにコピーすることです。
kotanデモサイト
kotanプロジェクトサイト