巷で議論を呼んでいるGoogle App Engine（GAE）の料金改定ですが、拙作ウェブサービスtwistoireも当然対象となります。どのくらい課金されるようになるかというと、こんな感じ。 だいたい5$/day、つまり150$/month……高い！高いよ！ で、なぜこんなに課金されるかというと非常に簡単な話で、インスタンスを使い過ぎなんですね。課金単位がCPU時間からインスタンス時間に変わったのが大きいわけです。twistoireはcronでTaskQueueにtaskを積んでバッチ処理を回し続けるというつくりになっているので、5〜6インスタンス起動するということも珍しくありません。ということで、この利用インスタンス数を削れないか試すことになりました。 threadsafeをONにする 最初に行ったのは、1インスタンスで複数リクエストをさばくためにappengine-web.xmlに

App Engine は、大規模なウェブ アプリケーションを開発およびホスティングするための、フルマネージド型のサーバーレス プラットフォームです。アプリの開発では複数の一般的な言語、ライブラリ、フレームワークからの選択が可能で、開発したアプリのインスタンスのサーバー プロビジョニングとスケーリングは App Engine によってオンデマンドで行われます。詳細については、こちらをご覧ください。

元旦はSlim3の練習もかねてLogCounterを実装してみました。このカウンターは、 ユニークな連番を生成して返す（sharding counterのように集計専用ではありません） 追記ログで値を保持するのでスケールアウトする（はず） といった特徴があります。以前のロジックをもっと簡素化してタイムスタンプなしで実装してみました： MemcacheService#incrementでカウントアップし、値を返す CountLogエンティティを新規追加する（以下プロパティを備える） countValue: カウント値 memcache上に値がない場合（初期化時またはmemcache上の値の破棄時） CountLogのcountValueの降順で最初のエンティティを取得し、そのvalue値をmemcacheに入れる CountLogがない場合は、1をmemcacheに入れる これをSlim3で

昨日一昨日、Google App Engine (GAE)に関する日本最大の勉強会（だと思う）appengine ja night #7 (ajn7)が行われました。 その中で『ランキング問題』が話題に上がりました。『ランキング問題』とは、何十万件もの点数のデータがあるときに、App Engine上で、「◯点は何位です」と高速に求めることは難しい、という問題です。（◯ページ目を表示、というページングもこれと同じ種類の問題になります。） ajn7では「上位でない限り正確な順位は必要ないのではないか」という話になりましたが、Skiplistを用いた検索アルゴリズムを使えば正確かつ高速に順位を求めることができるのではないかと思い、実装＆検証してみました。 ランキング（順位取得）のデモ 下記ページで順位取得のデモを動かしています。スコア（点数）を入力すると順位と取得にかかった時間が表示されます（時

先日のSlim3 Source Code Reading #2 で話題になった件について。 Slim3 Source Code Reading #2 に参加してきた！ - SinDiary 丁度、twitter#slim3 でひが殿に質問してくださってる方がいらっしゃった。 タイミング的にここか、横山殿のblogを見てくださったのかな？ T.Yokoyamaのブログ: Slim3 Source Code Reading #2 更にその件について、@bluerabbit777jp殿が詳しく教えてくださった。 有識者の方とこんなに簡単にコンタクトが取れる・・・！ いい時代になったものだと、勝手に感動した！ ということで、言いだしっぺの私の役割は、学習した内容をblogにまとめることである！ 結論 DatastoreTimeoutExceptionはGAE/JのSDKより先のRPCの向こう側でリ

去る11月18日に行われた、 appengine ja night #18。「app engine ja nightって？」というのはこちらあたりでも見てもらうこととして、ぼく個人、これに参加したことはありませんでした（主に地理的要因による）し、今回も参加できたというわけでは無いのですが、appengineのpreview版卒業以降、初のajnということで、「きっと、appengineのリソース節約術が聞けるハズ！」と、心から、その開催を待ち望んでいました。 上述のとおり、ぼくの参加の大きな障害である「地理的要因」は今回のajn #18でも変わらず、ただ一方で“リソース節約術”は何としても聞きたい！ということもあり、今回はTwitter + Ustreamを利用しての“初参加”と相成りました〜。 結果、もちろん直接参加とは勝手が違って色々ともどかしかった部分もあったものの、個人的には非常に

AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワークだと1000cpu_msくらい(アプリによる)かかりますが、許容範囲内。JavaだとSlim3で1300cpu_ms、Springだと早くて7000cpu_msという感じで、Slim3がギリギリ許容範囲内でしょうか。ほんとうは、1000

先日、Amazonの価格をチェックしてメールでお知らせするWebサービス「マケプレ・フラグ」を公開してみた。 このWebサービスは、sinatra on GAE/JRuby という構成で作ってあるのだけど、実は4、5日程度でひととおりの機能が動作するくらいになっていた。 別にGAEバンザイと言いたい訳ではなくて、本題はここから。 GAEって制限が多くあるので、これを回避するのが結構大変。さらに「マケプレ・フラグ」は価格情報を得るためにAmazonのProduct Advertising APIを使っていて、実はこちらにも制限がある。 GAEは30秒以内にレスポンスを返さなくてはいけない 利用者が商品検索して30秒も待ってくれる訳はないので、それは問題にならない(というより30秒も待たせるならGAEに関係なく設計を見直すでしょ)。 問題は、cronで実行するようなバッチ処理も同様の制限がある

（随時更新中です。間違いなどありましたらコメントをお願いします！） このページのtinyurl: http://tinyurl.com/gaetips Datastoreのtips Bigtableの内部構造 BigtableによるDatastoreの実装 Datastoreによるクエリの実装 トランザクションとエンティティグループ Datastoreのtips List Proprtyとmerge joinの使い方 GAE一般のtips GAEのサーバー構成とリクエストの流れ Task Queue APIの使い方 開発環境とプロダクション環境の違い Flex/AIR＋GAEのtips GAE/JにBlazeDSを組み込む BlazeDSの本番環境へのデプロイでハマる Datastore APIの取り扱いでハマる App Engine開発の便利な参考ページ TOPGATEさんのGoogle

※2010/4/23 sessionのクリアについてご指摘頂き、追記しました。Google App Engine for Java(GAE/J)にて、どんなアプリを使う場合でも （自分的に）ほぼ必須となる設定ファイルのまとめ。 ていうか、リファレンス読めばいーんだけどさ １．sessionを有効にする & クリアの設定をする Javaでsession使わないケースなんてあるのか？ appengine-web.xml　に　下記を追加 <sessions-enabled>true</sessions-enabled> GAE/Jでsessionを使う場合、このままだとDatastoreにsession情報が残ったままなので定期的にクリアするcronを設定する web.xml　に　下記を追加 <servlet> <servlet-name>_ah_sessioncleanup</servlet-