Google App Engine(GAE) Archive

appengine関連でTogetterから議論が巻き起こってますね。最近すっかりappengineをご無沙汰だった自分としては、一連のtweetやblogを読んだおかげですっかり熱が戻ってきました。

議論の発端になったのは以下のTogetter。

Togetter – 「Google AppEngineについて思うところ」

議論を見ていて感じるところがあったので、ざざっと。

• @makotokuwata さんの主張自体は自分はそれほど違和感無かった。ただ表現がキツイ箇所があったのが琴線に触れてしまったのかな。
• 議論から有用なtweetやblogエントリが生まれてきた。これはとても参考になった。
• 意識的にそうしていたわけではないだろうけど、寄ってたかって反論していくのは見ていて @makotokuwata さんが気の毒に感じた。
• @makotokuwata さんがこれまでされてきた活動（Python4PHPer）は素晴らしいと思う（自分もイベントは気になってた）し、これからも続けられると良いのでは。(
  大きなお世話かもしれませんが）
• ちなみに反論していた人には「appengine ja night」な方も多かったけど、自分がイベントに参加した時はアットホームな雰囲気でとても楽しかったです。技術的な内容ゼロの自分のLTも笑顔で聞いてくれたし。別にこわいひとたちでは無い（と思う）。
• ようは、表現が少し過激だったり、ちょっとした言葉の行き違いが原因かと。自分も感情的になるとついつい余計なことを書いてしまうから気をつけないと。
• 多分、飲み屋で同じ話すれば「おまえなにいうてんねん」というノリで軽い議論になるだけで、こんなややこしい話にはならなかったでしょうね。オンラインのコミュニケーションは難しい。。。
• どちらかがどちらかのイベントに参加して懇親会とかで話せば、わだかりも解けると思うんだけどなー。

今回のことでこれまで頑張ってこられた @makotokuwata さんが辛い思いをされているのは、とても悲しいことなので、気にせずに頑張って下さい。

そういえば appengineを追いかけてる時に作ろうと思って放置していたものとかあるから、またやりだそうかな。

appengine について参考になったエントリ

• AppEngineにどんなアプリが向いているのかを知ろう – ひがやすを blog
• Life is beautiful: google appengine に関してひと言

日本国内のパブリッククラウドをざくっと集めてみました。

クラウドがすっかり盛り上がってきました。新聞等ではいわゆるASP的なSaaSのクラウドが良く言われていますが、Webシステム屋としては IaaS / PaaS が気になります。

代表的なのは、Amazon EC2やGoogle App Engine、Azureの海外勢ですが、日本国内でもパブリッククラウドが立ち上がってきています。

2010/07現在で、どういったパブリッククラウドが国内にあるかをざっと並べてみました。

ここもあるよ！これ間違ってるよ！等々あれば教えて下さいm(_ _)m

対象

「クラウド」を謳っているサービスは多数あるのですが、ここでは以下に限定しました。

• Webサイト（サービス）構築目的
• IaaS もしくは PaaS
• ユーザが任意にコントロールパネルでサーバ構成（リソース）を変更できる
• 急激なアクセスに備えてオートスケール機構があれば尚良い

1. NIFTY Cloud

http://cloud.nifty.com/

• NIFTY
• IaaS
• 法人のみ
• 時間 / 月額課金
• 勉強会やTwitter等でのPRが活発
• ソーシャルアプリコンテスト等でサーバ提供を行っている
• オートスケールは今後提供

2. ユニットホスティング

http://www.unit-hosting.com/

• ディノ
• IaaS
• 個人 / 法人
• 時間 / 月額課金
• オートスケール機構は要問い合わせ

3. CUMO

http://cu-mo.jp/

• 沖縄クロス・ヘッド
• IaaS
• 法人のみ
• 月額課金
• ロードバランサーは2010年秋提供予定

4. ホワイトクラウド（シェアードHaaSスタンダード）

http://tm.softbank.jp/business/white_cloud/haas_std/index.html

• ソフトバンクテレコム
• HaaS（IaaS）
• 法人のみ
• 月額課金
• 提供サーバは1種類
• Webからサーバ追加ができるかは不明

5. オンデマンド仮想システムサービス

http://oviss.jp.fujitsu.com/portal/ctrl/top

• FUJITSU
• IaaS
• 個人 / 法人
• 時間 / 月額課金
• API提供アリ

番外. クラウドブースター

http://www.kagoya.jp/option/web/cloudbooster01.html

• カゴヤ・ジャパン
• ホスティング
• 個人 / 法人
• 時間課金
• オートスケール可能なホスティング
• クラウド程の自由度は無いが、実用はこれで十分かも

番外. NOAHプラットフォームサービス

http://www.idcf.jp/services/hosting/noah_p/platform.html

• IDCフロンティア
• IaaS
• 法人のみ？
• 月額課金
• サーバ構成変更のリードタイムが？

番外. True CLOUD

http://www.truecloud.jp/

• アイル（GMO）
• IaaS
• 個人 / 法人
• 日 / 月額課金
• 一日単位でのノード追加プランは2営業日前に申込が必要

番外. GrowServer2010-II

http://www.itcore.jp/growserver/

• ITコア
• ホスティング
• 個人 / 法人
• 月額課金
• 回線トラフィック、ロードバランサー無料

番外. IIJ GIO

http://www.iij.ad.jp/GIO/

• IIJ
• ホスティング
• 個人 / 法人
• 日 / 月額課金
• サーバ構成変更のリードタイムが？

まだ少ない。

EC2のように自由にリソースを変更できるクラウドを想像すると国内はまだまだ少ないですね。

正直、リストアップする前はもっとあると思っていたので、上手く見つけられていないのかもしれません。（教えて下さい！）

個人だとユニットホスティングしか選択肢が無いのが何とも厳しいですね。。。

いよいよEC2が国内に拠点を持つという話も出ているので、国内でも良いパブリッククラウドサービスが増えると良いですね。

「なんでも判定ツクール」へ多数のアクセスありがとうございますm(_ _)m

1月末にリリースした当初は僅かのアクセスだったのですが、Twitterで火が付いてからは一気にアクセスが集まり、気が付けば2月1日〜2月16日で4,000,000PVを超えました。

自分では絶対に考えつかないであろうユニークな判定がたくさんできて、私自身もとても楽しんでいます:-D（面白い発想をする人は世の中にたくさんいるものです）

このサイトはGoogle App Engine(GAE）＋Pythonで構築しているのですが、このアクセス数ならではのGAE上で体験できたことをざざっと書いていきます。

無料？課金？

まずはじめに大事なこと。

「なんでも判定ツクール」ではGAEを課金状態にしています。無料のQuotaではとてもではないですが、このアクセスは捌けません:D

GAE公式サイトには

月間約 500 万ページ ビューに対応できる十分な CPU と帯域幅を、すべてのアプリケーションで完全に無料で利用できます。
Google App Engine について – Google App Engine – Google Code

といった記載があるのですが、少なくともDataStoreを使うような動的サイトでは5,000,000PV/月を無料Quotaで捌くのはかなり難しいと思います。

秒間200リクエスト

アクセスは日によって時間によってバラツキがあるのですが、瞬間最大風速では200超req/s（GAE DashboardのChart上）を記録しました。

この200req/sを記録したのは 2010/02/15 夜だったのですが、ブラウザでサイトにアクセスする分にはそれほど重さは感じませんでした。ですが、実は裏では結構なアクセスをさばいてくれています。

これはGAEの真骨頂とも言える「チャージ金額上限まで自動でリソースを割り当ててくれる」サービスのおかげですね。まさにクラウドです。チャージ上限金額までは負荷に合わせて勝手にリソースを確保していってくれるので、アクセスどんと来いという気持ちになります（比例して財布は少し寂しくなりますが＞＜）

もちろん、これにはアプリケーションの設計も大きく関連します。いくらプラットホームであるGAEがスケールしていっても、アプリケーションがそれを想定していた作りになっていなければアプリケーション側がボトルネックとなります。「なんとか判定ツクール」は業務システムに比べると単純な作りになっているので、このあたりもGAEのスケーリングの恩恵が受けやすいということはあるでしょうね。

1日680,000PV

1日単位で見ると 2010/02/09 に 680,000PV を記録したのが最高値でした。

数値はGoogle Analyticsに記録されたものです。これはPC版の数字なので携帯版を加えるともう少し上乗せされます。

この日は秒間リクエストのピークは160くらいだったのですが、ピーク時以外もアクセスが続いたのでPVが伸びました。PVが伸びた分、課金額も一番です。

この数値を元に単純計算すると 680,000 * 30 = 20,400,000PV/月 はこなせそうです。

DataStoreの総エンティティ数が3,000,000

DataStoreのエンティティ数（RDBMSのレコード数のようなもの）の合計が3,000,000を超えました。

DataStoreにはいくつかのkind（テーブルのようなもの）があるのですが、これは全ての合計です。

中でも一番多いのが判定結果を表すエンティティで、1,500,000くらいです。つまりこれは延べ1,500,000回の判定（！）が行われたということです。（実際は、1,600,000エンティテイあるのですが、初期アプリケーションのゴミデータが含まれるので実質は1,500,000程度。）

これだけのデータがあってもキーを使った読み込みならとても高速に動作します。（これくらいのデータ量ならインデックスが効けばRDBMSでも早いですけどね。）

DataStoreエラー

負荷が上がった際、サイト自体は概ね動いているのですが、実はDataStore周りでいくつかエラーが発生しています。

例えば、平常時は瞬時に返答がある Model.get_by_key_name() でデータを取得するという単純な処理でも高負荷時は DeadlineExceededError が発生する場合があります。

これは避けがたい現象のようなので、クライアント側でリトライ処理を実装するなどして上手く付き合うしかないようです。

bit.ly

当初、判定結果をTwitterに報告する際にURLを短縮する方法としてbit.lyのAPIを利用していました。

これはとても上手く動いていたのですが、アクセス数が伸びるのに従って、bit.ly APIでエラーが発生するようになりました。一度この状態になるとエラーレスポンスが返ってくるばかりで短縮URLへの変換を行ってくれません。数十分経過すると復活するのですが、また負荷がかかると停止してしまいます。

bit.ly API のドキュメントでは1IPあたり同時アクセス数5未満とされているので、制限を超えるアクセスで止められるのは当然だと思います。なのでこれに関しては利用させて頂いてありがとうございますと、ごめんなさいという感じです。

いくらGAE自体がスケールしても、外部サービスに引っ張られて処理できないと元も子もないので、結局短縮URL機能を自作しました。

これには @kis さんとのTwitterでのやりとりが大いに参考になりました。ありがとうございました！

サイボウズさんキャンペーン

サイボウズさんのキャンペーンにて「なんでも判定ツクール」を利用して頂きました。

=>サイボウズコミュニティ – 特集 – 【終了しました】サイボウズ謹製ツバメノートプレゼント！

サイボウズさんにまつわる判定をやって、Twitterで報告するとノベルティが貰えるというキャンペーンだったのですが、多くの方が参加されて盛り上がったようです。

こういったキャンペーンに使えるという視点は当初は持っていなかったので面白かったです。

今後も絶賛募集中ですので、キャンペーンに使ってみたい、という方はご一報頂ければ嬉しいです:D

Google App Engineは使える！

「なんとか判定ツクール」を運営している感覚では、今更ながらですが、やはりGAEは十分に使えるなという印象を持ちました。

なんといってもチャージさえしておけば自動的にスケールしてくれる感覚は素晴らしいですね。これまで突発的な負荷に悩まされた経験がある方なら有難みが特に分かると思います。

もちろんGAEならではの制約（処理時間やDataStore仕様等々）があるので全てのアプリケーションをGAE上で動かすべきとは思わないですが、特性にマッチするアプリケーションであれば検討してみる価値がありますよ。

え、PHPしか書けない？PHP書けたらPython書けます。大丈夫:-D

Google App Engine(GAE)からHTTPアクセスするときのUser-Agentについて。

GAE上のアプリケーションがHTTPアクセスする際にどのようなUser-Agentになるかを調べてみました。環境は、Python2.5.4 + Google App Engine SDK 1.3.1 です。

GAE+PythonからHTTPアクセスするには幾つかの方法があるのですが、urllib2を使う方法とGAEのモジュールであるurlfetchモジュールを使う方法について見ています。

urllib2

urllib2でアクセスした場合のUser-Agentです。

特徴的なのは「AppEngine-Google」が付いているのとアプリケーションIDである「appid: XXXX」が付加されていることですね。アプリケーションIDはGAE上の各アプリケーションに割り振るIDで一意となります。

もしGAE上のあるアプリケーションからのアクセスを制御（許可、拒否等）したい場合は、このアプリケーションIDを見れば可能です。

"Python-urllib/2.5 AppEngine-Google; (+http://code.google.com/appengine; appid: XXXX),gzip(gfe)"

urlfetch

urlfetchでアクセスした場合です。

urllib2と比較すると「Python-urllib/2.5」が無い他は同じですね。

"AppEngine-Google; (+http://code.google.com/appengine; appid: XXXXX),gzip(gfe)"

User-Agentを変更した場合

urllib2でもurlfetchでもUser-Agentを変更することができるので、変更してアクセスしてみました。

# -*- coding: utf-8 -*-
url = "http://www.exaple.com/"

# urllib2
import urllib2
opener = urllib2.build_opener()
opener.addheaders = [('User-agent', 'PHP5.3.2')]
try: opener.open(url)
except: pass

# urlfetch
from google.appengine.api import urlfetch
urlfetch.fetch(url, headers={'User-Agent': 'CakePHP1.2.6'})

結果はどちらも変更したUset-Agentにはなっているのですが、AppEngine-Google以降の文字列が付加されています。もちろんappid:も付いているので、User-Agentを変更していてもアプリケーションIDによるアクセス制御は可能です。

urllib2

"PHP5.3.2 AppEngine-Google; (+http://code.google.com/appengine; appid: XXXXX),gzip(gfe)"

urlfetch

"CakePHP1.2.6 AppEngine-Google; (+http://code.google.com/appengine; appid: XXXXX),gzip(gfe)"

urllib2でUser-Agentを変更しない場合に「Python-urllib/2.5」が付くのは内部的にUser-Agentを設定しているだけの話です。

アクセス制御はアプリケーションIDで

GAEではサーバ環境を全ユーザで共有するので、IPアドレスでの制限はできません。（GAE全体からのアクセスを制限することはできるかもしれませんが。）

ただアプリケーションIDであればアプリケーション固有に付いている値なので、これを使えば特定のアプリケーションに対してだけ制御が可能です。User-AgentへのアプリケーションID付与（appid:）はGAE自体が行うので今のところ信頼して問題無いと思います。

時間が経つ毎に進化していくGAEですが、こういったところも気が利いていますね。

[参考] Apacheでアクセス制限 mod_access – Apache HTTP サーバ

週末にappengine ja night #4とPython Hack-a-thon #3 に参加してきました。

2010年、初勉強会です。

どちらもこれまで参加することの無かったイベントなのですが、こうした場所に参加したくなるのも Google App Engine（GAE）をやり出して興味が広がった効果ですね。

appengine ja night #4ではBT（Beer Talk）もやってきました。

他の方の発表も参加される方の雰囲気も事前には良く分からない状況だったのですが、ほぼ全員の方がはじめましての状況だったので自己紹介も兼ねて話してきました。

いざやってみると、とても良い雰囲気で、突っ込みあり、笑いありですごく話しやすかったです。ありがとうございました。

資料を見てもあまり役に立たない気もしますが、いちおうアップしました。

以下、雑感を。

appengine ja night #4

• 会場はリクルートメディアテクノロジーラボさん。会場もキレイだし、スクリーンマルチだし、無線LANもあるしで、至れり尽くせり:-D
  => ありがとうございました。
• 発表を聞くだけでなく、適時突っ込みを入れるスタイル。
  => 議論が深まって面白かったです。発表者は大変だと思いますけど:-D

• こんなpostやこんなpostがあったりで、このノリ大好きです:-D

• 運営のみなさん、ありがとうございました。
• 次回は来月開催だそうです。みんなやさしい人達だから、興味ある人は参加すると良いですよ。

Python Hack-a-thon #3

• 会場はオラクルさん。マルチスクリーン、電源あり、無線LANあり、飲み物無料、キレイと、こちらも至れり尽くせり。
  => ありがとうございました。
• 両日共にこんなに素晴らしい会場を無料で提供頂けるのは本当にありがたいことです。
• hackathon初参加。
• ワークショップはGAE+Facebookにちらっと参加して、あとはもくもく作ってました。
• GAE+Facebookは連携して、友人一覧が出せたのでとりあえず満足:-D
• その後はTwitterのOAuthを使った検証と新しいサービスの下調べを。
• hackathonの時間はあっという間に終わっちゃいました。
• PHPでも同じようなイベントをやっても良いかも。（関西でやろうかな。）
• お昼やワークショップ、発表を通じて、普段あまり接することのない分野に触れられて刺激的でした。
• 自主性をかなり求められるイベントなので、少し参加する人を選ぶイベントかも。オラクルさんの環境で作業したいがために参加する手もありますけどね:-D
• 運営のみなさん、ありがとうございました。

興味が広がると

冒頭でも書きましたが、どちらも初参加のイベントだったので、初めてお会いする人ばかりでした。両イベントとも著名な方も多く参加されていたので、ミーハー気分な楽しみもありました:-D

新しいことをやりだすとRPGで新たな地図を手にしたように、これまで行けなかったところに行ける楽しみがあります。

また勉強会をやりたくなってきました。GAEの勉強会を関西でやってみましょうか。

自分が死んだ後、Webには何が残るのだろう。

30代半ばになると、いやでも死というものを考える瞬間がある。日頃から常に考えているわけではないけれど、ふとした瞬間に考える。

ある日、何気なく考えた。

「もし、自分が死んだら、Webにある自分はどうなるんだろ。」

blog

まず、このblog。

サーバはレンタルなので、その期限がくれば停止して見られなくなる。

また、1×1.jpドメインも１年経って何も手続きをしなければ失効される。

おそらく死後1年数ヶ月で見ることはできなくなるだろう。

自作のWebサービス

follow okやfindTwitter、hot.hatebuといった自分で運営しているサービスたち。

レンタルサーバに置いているものは、blogと同じく契約が切れれば停止するだろう。

hot.hatebuは GAE（Google App Engine）に置いているので、Googleの気分が変わらなければ残り続ける可能性は高い。最近GAEを熱心にやっているのは、こういう理由もあったりする（別に死後を考えているわけではないけど）。

ただやっぱりドメインが切れると接続できなくなる。

残すことだけを考えるなら、独自ドメインではなく、「*.appspot.com」で公開した方が良い。

Twitter/Wassr/usream等のWebサービス

これはサービスさえ残れば、そのまま残り続けるだろう。

Twitterには思いついたことをすぐにpostしているから、結構生々しいというか、生きている感じがする。

以前、Twitter上で有名な方が亡くなられた。2007年頃からTwitterをやっている人なら知っている人も多いと思う。

最近、何かの拍子にその方を思い出し、その方のTwitterを見てみると、アカウントがそのまま残っていた。

残されたtweetは、ごく自然に発せられたもので、日付が2007年ということを除けば、まるで生きているようだった。

その方はustream配信もされていたので、録画したものがそのまま残されていた。

私はそれほど接点があったわけではないが、何となく気になる人だった。（当時はまだ日本のTwitterユーザ数も少なくて、わりとみんな仲良しな空気もあった。）

彼ほどの影響力は無いにせよ、サービスが残っている間は、何かしらの想いがWebに残り続ける。

問題はドメイン

blogとかは大手の無料サービスを使う、自分が作るサービスはGAEを使う、としておけば、しばらくは動き続ける。

問題はやっぱりドメインで、自動更新の仕組みが欲しいところ。こだわりを捨てられるのであれば、割り当てられたドメインで運営すれば良い。

何かを残したい

生きてきた何かを残したい、という想いにWebは向いている。誰でも発信できるし、多くはサービスが無くならない限りコンテンツが残る。

GAEで最初に作ったアプリケーションは、家族の誕生日にメッセージを送るというシンプルなものだった。

少しでもWeb開発をかじった人なら誰でも簡単に作れるものだし、公開するつもりも無いので操作画面も無い。

ただGAEなら数年単位の未来までは動き続けるだろうから、もし明日いなくなっても、しばらくは送り続けてくれるだろう。（無料で利用できるGAEには「何があっても動き続ける」という利点もある。）

いつも考えているわけではないけど、たまには。

はてブホットエントリーを集計して見るWebサービス「hot.hatebu」を作りました。

はてブのホットエントリーを集計して一覧で見るサービスです。機能をざっくり挙げると以下です。

• 「エントリ」「時間」「タグ」「ユーザ」の集計データを表示
• 日付範囲を指定して、合算した集計データを表示
• パネル機能

詳細については説明ページがありますので、こちらをどうぞ。
hot.hatebu | 説明ページ

ここでは作った経緯や使い方のポイントなどを。

週間はてブホットエントリーを見たい

そもそものきっかけは週間ホットエントリーを見たいというものでした。イベントやネットラジオなどで話す時のネタにホットエントリーを使うのですが、公式サイトでは一日単位で見る方法しかありません。

例えば、先週のホットエントリーをまとめて見る場合は1ページづつページを辿るしかありません。

そこで複数日のホットエントリーを合算して見られるサイトが欲しいと思いました。

あとちょうどGAEを試していたので、何か作ってみたいというのも理由の1つです。

平日は12時台、休日は23時台がピーク

実際にやってみて面白かったのが時間別のブックマーク数です。

平日と休日ではっきりと推移が異なります。

・平日（2009/12/07〜2009/12/11）
hot.hatebu | 2009/12/07〜2009/12/11の時間別

・休日（2009/12/12〜2009/12/13）
hot.hatebu | 2009/12/12〜2009/12/13の時間別

平日はオフィスで昼休みにRSS ReaderやTwitterからブックマーク、休日は家に帰って寝る前にWebを眺めてブックマーク、という使い方が多いのかもしれませんね。

パネル機能

あったら面白いなと思っておまけで付けた機能です。

勉強会やネットラジオをやる時、何となく話すネタが欲しい時ありませんか？そんな時にプロジェクタでこの画面を映して、表示されたエントリーについて話ができれば考えています。

イメージとしてはテレビのバラエティで見るパネルですね。

データは2009/12/01〜

データはまだ2009/12/01以降のものだけです。今後のデータは随時、追加していきます。

DataStoreで悩む

GAE+Pythonで作りました。

悩んだのはDataStore周りの実装ですね。どうしてもRDBMS感覚で作ってしまうので、パフォーマンスが出なかったり、30秒制限にひっかかったりで試行錯誤を繰り返しました。

TaskQueueを使う方法が分かってからは何とか形になりました。色々な制限があるGAEでは、TaskQueueをどう上手く使うかがキーですね。

無料のQuotaを超えて課金をはじめると分かりやすく「リソース浪費=コスト（金銭）の浪費」に繋がります。例えば、ロジックの組み方が悪くてCPUを無駄に使えばその分費用がかかります。これまで以上にチューニングや処理の分散化（ブラウザでできることはブラウザにやらせる）といったアプローチが重要になりそうです。

ホッテントリーは面白い

ホットエントリー、はてなブックマークのデータは題材として面白いですね。自分で作ってみても色々な見方ができて楽しいです。

ホッテエントリーのチェックに、話のネタ探しに、ブックマークの分析に使って頂ければ嬉しいです。

Google App Engine（GAE）で独自ドメインを使う方法です。

GAEに設置したアプリケーションはデフォルトでは、[アプリケーションID + .appspot.com]というドメインでアクセスすることができます。

また、これとは別に独自ドメインをアプリケーションに割り当てることもできます。

独自ドメインを割り当てる方法は知っていないと嵌りやすいので手順を書いておきます。

仕組みと手順

まずは仕組みから。

GAEでの独自ドメイン割り当ては、独自ドメインのCNAMEでGAEサーバを指すことで実現します。よって独自ドメインのDNSが設定できる必要があります。

私はドメイン管理にムームードメインを使っているのですが、ムームードメインではコントロールパネル（Web管理画面）にてDNSの設定ができます。

次に手順。

前提として独自ドメインは既に取得済みとします。

1. Google Appsを申し込む
2. Google Appsでドメイン設定
3. Google App Engineでドメインを割り当てる

1. / 2. ではGoogle Appsにて独自ドメインの設定を行います。Google App Engineではなく、Google Appsなのでご注意を。

1. Google Appsを申し込む

Google Appsにて申込みを行います。

Google Apps

Google Appsには幾つかエディションがあるのですが、ここでは無料で利用できる「Standard Edition」を申し込みます。

画面右メニューから「Standard Edition」を選択します。

次の画面の右メニューから「開始方法」を選択します。

設定するドメインを入力します。既にドメインは取得済みなので、「既存のドメイン名を使用する」タブにドメイン名を入力します。

次に申込者（アカウント管理者）情報入力と管理者アカウント登録を行います。

これでGoogle Appsの申込みは完了です。

Google Appsの管理画面（ダッシュボード）に遷移します。）

2. Google Appsでドメイン設定

Google Appsにてドメインが利用できるように設定します。

Google Appsを申し込んだ直後はまだドメインは利用できるようにはなっていません。(申込みだけで使えるようになってたら問題:-D）ドメインの所有権をGoogleが確認することにより利用が可能になります。

ドメイン所有権の確認を行うには、ダッシュボード画面上部にある「ドメインの所有権を確認」リンクに進みます。

ドメイン所有権の確認には「HTMLファイルをアップロード」する方法と「CNAMEレコードを変更」方法があります。今回、ドメインを取得したムームードメインでは管理画面からDNS設定ができるので、今回はプルダウンで「CNAMEレコードを変更」を選択します。

プルダウンを選択すると、所有権確認用のDNS設定が表示されます。この画面の説明どおりにDNSを設定して、「確認」をクリックすると所有権の確認をGoogleが行います。

たとえばムームードメインなら以下な感じです。

DNSでCNAMEを割り当てると、ブラウザでhttp://googlexxxxxxx.example.com/にアクセスするとgoogle.comが表示されるはずです。

所有権の確認を依頼するとダッシュボードに確認中を示すメッセージが表示されます。「48時間程度」と書いてありますが、私が試した時は数分で確認が完了しました。

3. Google App Engineでドメインを割り当てる

いよいよGAEで独自ドメインを割り当てます。

まずGAEの管理画面にアクセスします。左メニューにある「Application Settings」をクリックして、画面中央の「Domain Setup」にある「Add Domain…」ボタンをクリックします。

Add Domain画面にて割り当てるドメインを入力します。

次の画面の中央にある「新しいURLを追加」リンクをクリックします。

GAEアプリケーションに割り当てるホスト名を入力します。なおホスト名無しのドメイン（Naked Domain）は以前は設定できたようですが、現在は設定できないようです。

最後に入力したホスト名についてDNSの設定を行います。手順はドメイン所有権の確認で行ったのと同じようにホスト名のCNAMEに指示された内容を設定します。

ムームードメインでの設定例です。

最後に画面下の「指定された手順を完了しました」をクリックして設定は完了です。

ちょっと手間。。。

はじめて設定したときは行程に目がくらっとしたのですが、慣れると結構トントン拍子で設定できます。

この方法でドメイン設定を行うとGoogle Appsが独自ドメインで使えるのでそれはそれでメリットになります。例えば設定したドメインのメールアドレスをGoogle Apps上で作成することができます。（要設定）

GAEで独自ドメインを使う時はご参考にどうぞ。

Google App Engine(GAE)でCPU Timeを使い切りました。

GAEは従量制のサービスで、あらかじめ設定した金額内で利用できるリソースが決まっています。これはQuotaと呼ばれていて、CPU、ネットワーク流量、保存データ、API呼び出し回数等々で制限があります。

よく言われる「GAE=無料」というのは、無料（課金しない）なら、そのQuotaが適用されるということです。

GAE+Pythonでとあるサイトの動作確認をやっていたところ、無料分のCPU Timeを使い切りました。

実際に使い切るとこんな感じになります。

サイト

ブラウザでアクセスすると、どのページを見ても503が返ってきて、Googleのエラー画面が表示されます。

HTTPレスポンスヘッダは以下。

HTTP/1.x 503 Service Unavailable
Date: Sat, 16 Jan 2010 06:21:24 GMT
Content-Type: text/html
Server: Google Frontend
Content-Length: 999
X-XSS-Protection: 0

Task Queue

ちょうどTask Queueにキューが入っていたのですが、CPU Timeを使い切ったあとは、タスクが実行されなくなりました。

45個のタスクが残っているのに実行されていません。

解放待ち

今回は24hに使えるCPU Timeをオーバーしたので、時間が経過すれば利用できるようになるはずです。

実際のサイトではサイト監視で503が出たら、Quotaを広げる（課金額を増やす）といった運用になるのでしょうね。

解放まであと1時間。。。

追記：1時間後に解放されました。

Google App Engine（GAE）が盛り上がってきてますね。

今後増えて行くであろうGAEを使ったサイトを判別する方法です。

そうは言っても何も特殊なことをするのでは無く、単にHTTPレスポンスヘッダを見るだけです。

GAEを使ったサイトは「Server: Google Frontend」が返ってくる、というの話でした。