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

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

Offline Processing on App Engine: a Look Aheadを見たメモ

メモ GAE

Offline Processing on App Engine: a Look Ahead

  • 背景
    • バックグラウンド処理やバッチ処理の要求がとても多い
      • cronはあるが、たくさんの処理や高頻度の処理には向かない
  • 概要
    • 現状はApp Engine Labsの扱い：APIが未確定。課金方法も未定
    • Python版が6/18にリリース済み（追ってJava版）
  • TQとは？
    • ベストエフォートFIFOに処理要求を登録しておくと、バックグラウンドで実行。
    • 実行に失敗した場合は、成功するまでリトライする
taskqueue.add(description_of_work )
  • TQのメリット
    • 非同期
    • 軽量で遅延が少ない。Datastoreの最大3倍
    • 信頼性が高い：成功するまでリトライ
    • スケーラブル：新しいタスクをいくらでも追加できる。それぞれ並列処理される。
  • 他のTQシステム
    • 各種MQ、Amazon SQS、Azure queuesなど
    • pub-subメッセージングと統合されていることが多い
  • Queueingとpub-subの違い
    • Queueing：非同期処理によりネットワークやCPU、ディスクのキャパシティを効率よく引き出し、スループットを最大化する
    • pub-sub：非同期処理により多数の小さなtxを効率よく扱う。fan-outや優先処理、フィルタリング、分散txなどを提供
    • app engineのTQは前者のみを対象とする
  • GAE TQの特徴
    • Web Hookベース
      • RESTfulなpushベースのインタフェースでタスクを起動。今後登場する各種APIもWeb Hookを活用する予定
      • コールバックしてほしいURLをTQに登録する。TQのワーカーがバックグラウンドでURLをコールバックする
taskqueue.add(url='/work/mail', params=dict(
    to='foo@example.com',
    subject='Hello',
    body='this is a message!'))
      • 非同期なので登録は一瞬で終わる（数10msくらい）。メール送信処理を待つ必要がない
      • ステータス200を返せばタスク終了
      • ワーカーの数は負荷に応じて自動調節されるので、開発者がワーカーのプールを管理する必要はない
      • （従来のリクエスト処理と同様に）ダッシュボード上にURLごとのCPU消費状況が表示される
  • タスクはIdempotenceにする
    • タスクは繰り替えし（二重に）実行されても問題のないように書くこと
    • さまざまな理由（タスク自身の問題、コンテナの問題、またはそのほかの理由）でタスクは2回以上実行されることがある
    • memcacheなどを使って排他する方法が考えられる
  • Queueの使い方
    • queue.yamlで定義
    • 優先度や処理頻度の違いに応じて異なるQueueを定義。さまざまなタスクが混在できる
queue:
- name: mail_queue
  rate: 2000/d
- name: speedy_queue
  rate: 5/s

応用例

  • Write behind cache
    • ユーザーリクエスト処理時はキャッシュに書き込んでおき、TQのタスクでDatastoreに一括書き込み
    • カウンターでの利用：memcacheのカウンター値を加算し、タスクでDatastoreに書き込み

Future

  • JMS統合
  • MapReduceサポート: しかし他にももっとツール（シャッフル用の中間ストレージなど）が必要
  • Queue用AdminConsole

Questions

  • タスクにも30秒制限は適用される？
    • される。
  • TQはapp engine外部のタスクも呼べる？
    • 使える。Web Hookはapp engine以外のアプリも呼べる。