Hatena::Groupdann

dann's blog このページをアンテナに追加 RSSフィード

Fork me on GitHub

2010-10-28

RE: 非同期ジョブキューのアーキテクチャ設計、どうしてますか?

RE: 非同期ジョブキューのアーキテクチャ設計、どうしてますか? - dann's blog を含むブックマーク はてなブックマーク - RE: 非同期ジョブキューのアーキテクチャ設計、どうしてますか? - dann's blog RE: 非同期ジョブキューのアーキテクチャ設計、どうしてますか? - dann's blog のブックマークコメント

http://d.hatena.ne.jp/a666666/20101027/1288117907

少しだけ言及されてたので、自分の回答を書いておきますね。

刺身さんのエントリは、

  • 非同期リクエストへの非同期の応答の仕方
  • 非同期処理のキャンセルの仕方

の二つの問題を話しているように思うので、問題を少し分けてみます。

非同期リクエストへの非同期の応答の仕方

1つ目の問題は、リサイズと顔認識が十分に早いという前提に立てば、1つのworkerで処理をするのがいいでしょうね。で、Web App側がブロックしないように、Web App側からは非同期でタスクを登録するのがいいんじゃないかなと。それで、処理結果を別のキュー(またはmemcached)にいれてから、クライアント側(jsなど)でポーリングして、キューから取り出して結果表示するのがいいんじゃないでしょうか。こうするとで、Web App側はブロックせずに次の処理をすることができます。

これは非同期のrequest-reply patternといわれるもので、Enterprise Integration Patternに書かれています。 http://www.eaipatterns.com/RequestReply.html

Enterprise Integration Patternsは、非同期処理の基本的なパターンをまとめている良書なので、興味があればぜひ。

ただ、1番目の問題も、これは要求される応答性能次第でいろいろな設計方法がありえて、リサイズと顔画像認識の処理が両方遅い場合には、workerを分けて処理する必要があると思うんですが、これはまた話が膨らみそうなので、また別の機会に。

非同期処理のキャンセルの仕方

続いて、2番目の問題の非同期処理のキャンセルです。これはgearmanの機能不足の問題なので、gearmanに手をいれるか、はたまた別のキュー実装を使うのがいいんじゃないでしょうか。

ただ、一般に非同期job ququeからキャンセルしようとすると、結構コードが複雑になります。 キャンセルしようと思ったら、既にキューにはなくて、クライアントにレスポンス返す寸前だったりなどの、入れ違いがおこりうるからです。この問題についても、Enterprise Integration Patternはいくつか設計のパターンを示してくれているので、参考にされるといいんじゃないかと思います。

# 僕の感想では、あまりSEDAの話とは関係がないかな?という気もするんですが、一応自分の回答を書いてみました