読者です 読者をやめる 読者になる 読者になる

#ajn3に参加しました!

発表者・参加者の皆さん、おつかれさまでした。
個人的にメモった部分だけですが、まとめておこうと思います。

発言者が入り乱れているところがあれですが、セッションごとのまとめとしてみてもらえればと思います。


キムティ♪さんによるtwitterのまとめ
http://d.hatena.ne.jp/kazuki-aranami/20091204/1259938454



【あおうささん】資料はこちら:http://d.hatena.ne.jp/bluerabbit/20091204
テーマ:「実際に作ってわかったappengineの困ったところ」
・TaskQueueをチェインして実行することができるし、そうすれば30秒の境界を越えられる
・チェインする場合、チェイン先にどうやってデータを引き渡すかが課題。datastoreやmemcacheを使う場合、並列実行されることを考慮する必要がある
・Memcacheのインクリメントについては、Memcacheオブジェクトの/存在チェックを行わなくてよいようにするのがよいプラクティス
・Memcacheのputにはいくつかオプションがあるので、適切なものを選ぶこと!
・バッチ処理の設計では、各種サービスメンテナンス時にも正常動作することを考慮する必要があるし、不特定多数のデータが処理対象となるのであれば終了判定も考える必要がある
・Keyだけのputもできるし、KeyだけのEntity Group親も可能!?
※pb的にはEntityProtoにkeyのみsetしてputするケースがEntity Groupの親になれるということかな?
・kind less ancestor queryというのもある。
・AllocateIdsではサーバーとの通信が走るので、ちまちまとるより一括で取得した方がよい
※AllocateIdsについては、more low levelを見てもサービス呼び出しとして実装されていることがわかります。
・ちなみに、KeyFactory.createKeyはローカルの呼び出しなので、オーバーヘッドは少ない



【たけざきさん】資料はこちら:http://blog.virtual-tech.net/2009/12/google-app-engine-ajn3.html
テーマ:「ぶいてく流 スケーラブルアプリの作り方」
・Service Component Architecture的な設計をしている?
※SCAって初めて聞きました。SOA的なものの一部のようです。
・ローカル/リモート双方でデータを同期する必要がある場合(ローカルストレージを使用する場合)、ローカルの日付とmemcacheの大きい方を使用することによって同期をとらせやすくなる
・データ件数の取得は、フィルターが予測可能であればqueryではなくputのタイミングでエンティティを書き換えた方がよい
・appengineのqueryではnullが0と同値なので、最小をとるときは0以外で一番小さいものを取得する必要がある
・datastoreのputはgetの5倍くらいが一般的なパフォーマンス。ただ、エンティティの大きさにも依存する。



【わだうぃーばーさん】資料はこちら:http://twitter.com/WdWeaver/status/6341518073
テーマ:「スケールアウトの真実?」
・taskqueueのスケールアウトに関する検証
・リクエストの生存期間、10秒が存在することを理解すべき
・あっためるのが重要(spin upがされる、され続けるように工夫しないとtaskqueueを使っていても並列実行数はそれほど高くならない)
※細かいことは資料を見た方がいいと思います。数字も出てきて細かいので。



【まつおさん】資料を探したけどみつからなかったのでブログの方を:http://takashi-matsuo.blogspot.com/
テーマ:「Kay (Python 版の framework) について」
・appengineに最適化されたpythonフレームワーク
・ブログサービスなどに使われている
・お子さんが生まれたタイミングでリリースタグをうつ
・kayもお子さんの名前
・自分の子供の名前を付けることによって、悪口言われたくない→モチベーション向上、となる
※なんというか、名前のつけ方が大事だなと思いました。ぼくは響きがそれっぽいこと基準でつけているので、もう少し他人から見て白っぽいことをするようになったらそういうことをしたいと思いました。子供が生まれる予定は全くありませんけどね!



【まーぶるさん】 資料はこちら:http://balmysundaycandy.googlecode.com/files/%23ajn3.lt.marblejenka.pdf
テーマ:「makeSyncCallでいろいろ試してみた」
・実は僕が話してきたのさ!
・more low level apiについて
http://d.hatena.ne.jp/marblejenka/20091204/1259941582 の頭にサマリーしています
・黒いことは全くしていません
・アカウントも停止されていません!いまのところ。。


思うに、byte[]の中身を書き換えたらさすがにいい訳できないような気もしますが、僕は普通に触れるクラス(package privateをだますこともしていないです。昔、KeyFactoryがあることを知らなかったので自前KeyFactoryは作りましたけど。。)でやれる範囲のことをやっているので、多分、本当にネタじゃなく黒くないと思います。

判断基準は、syncの使えないapiを使う・asyncを使うことによって戦略の幅を広げることをとるか、非標準のapiを避けるか、ということだと思います。いずれにせよ、こういうものがあるということを知っておくことは大事だろうと。本当は、googleさんの実装を使うのが一番いいということはわかっているのですけれどもね。。

内部的には既にmakeAsyncCallが使われていて、戻りをlow level apinオブジェクトに変換するときに同期がとられているのか、とも思いましたが、ぱっと見てDatastoreServiceImplではmakeAsyncCallしていないし、そういう名前の別の非同期なやつもいなさそうです。

makeSyncCallが実はmakeAsyncCallを呼び出していてgetしている可能性もあります。Delegateがインターフェイスで、おそらくこの実装クラスは(自分で作らない限り)本番環境のみに存在するはずなので、真偽のほどは定かではありません。



【まーぶるさんの宿題】
・1.2.8でasyncCallできるようになったの?
 →できました。できましたよ!本番ですよ!

・datastoreのmore low levelにあるcountって何件とれるの?(会場ではmax1000件のはず、という意見が有識者から出たけど、僕の記憶ではmax5000件取れたはず。)
 →1000件でした、すいません。。

・more low levelのEXPLAINってなんなのさ?
 →情報は http://d.hatena.ne.jp/marblejenka/20091204/1259948078 に出しましたが、僕の知っている範囲ではピンとこないので、有識者の皆様からコメントをいただきたいところです。

これ以下は、本日デプロイができなくなってしまったようなので、近日中に検証しようかと思っていることです。

・asyncCallでdeadlineを超えるとどうなるの?
 →これから検証

・asyncCallで、datastoreのputとかをした後に同期せずにhttpレスポンスを返すとどうなるの?
 →これから検証


ということで、おつかれさまでした!