スティルハウスの書庫の書庫

はてなダイアリーで書いてた「スティルハウスの書庫」を移転してきました。

Task Queue戦記

とても遅かった以前の実装をTask Queueを使って書き換えることができました。感想をまとめると、

  • Task Queueはすばらしい。30分かかってた処理が3分で終わるようになった(前の実装がヘボいのではという疑惑はさておき)
  • 処理を複数のタスクに分割して並列処理する(map)は簡単だけど、memcacheを使ってその結果をまとめる(reduce)のは面倒
    • reduce不要な用途(一括削除とか)や、reduceが簡単な場合(数の集計とか)、あとmemcache使わずにDatastoreに集約する使い方なら、そんなに苦労しないだろう
  • memcacheを介してデータの配布や収集をするとき、とくに収集時の排他を書く必要あり(こういうバグりそうな/バグを再現できなさそうなコードは書きたくない)
  • MemcacheService#incrementを使ってスピンロックを実装した
  • memcacheはいつデータがなくなるか分からないので、その対処も必要
  • 同じタスクがエラーやその他の理由で何度も実行されうるので、idempotentに書く必要あり
  • すべての処理がきちんと終了しているか確認する手段も必要
  • 収集した大量のデータをクライアントに分割ダウンロードするのも大変だ(エラー時はその部分だけ再度ダウンロードとか)
  • やっぱりMapReduceの方が(並列プログラミング/デバッグの苦労やリスクがあまりなさげで)偉大だ
  • しかし1 task/s程度しか捌けないぞ(捌け方にムラがあるみたい)。アプリ全体で10 tasks/sという制限もスケーラビリティ低くね?
  • 100K tasks/dayという制限もやっぱり少ない。テストでも10kくらい使った。

という感じでした。以下はその過程でtwitterにつぶやいた内容のまとめです(新着順)。途中デバッグのつらさに一時戦意を喪失しているのが見て取れます。


9/10追記

今日は数tasks/s捌けてます。捌け方は変動するようです

9/11追記

100K tasks/day制限はGoogleさんに頼んでみたら1M tasks/dayに増やしてもらえた!rateは増やしてもらえなかった

9/14追記

上記つぶやきでは「TQはローカル環境でデバッグできない!」とかほざいてますが、ひがさんのブログでデバッグする方法がきちんと説明されてます。苦労損orz