自分の発表について以前予告した通り、ジョブキューの移行の話をした。ほうが見やすいかもしれません。併用するのが悪いわけではありません。適材適所というものがあり、それに応じて使い分けるのは重要です。やるのに適任でしょう(速度がある程度求められ、時間指定が必要なく、多少データロストがあっても許される)。使っていることが問題で、これは当時の技術選定のミスだと思います。行ったり来たりするのは意味がわからない。(とは言え、発表の時にも言ったけど、歴史的経緯で変なことになるのは仕方がない。的な「時間指定ができる、DBバックエンド」の普通のジョブキューがあればよかったのです。懇親会とかで話してみて思ったのけど、使っている人は当たり前にジョブキューを使っているけど、使ってない人はイマイチ、どう使うのかイメージできないみたいでした。言えば前職はジョブキュー入れてなかったもんなぁ。ジョブキューを無理に使う必要は全然なくて、小規模で負荷の小さいなシステムならジョブキュー使わないほうが幸せだと思います。(ワーカーの監視が必要になったりするので、シンプルで済むならそのほうが管理は楽だから)とは言え、どういう時に使うと嬉しいか、もう少しイメージできると良いかな、と思ったので、こんな例を考えてみましたがどうでしょう。ジョブキューを使う場合の例まず、話を単純にするために、1プロセスだけで動くアプリケーションがあるとします。クライアントからは10秒に1回程度の頻度でアクセスがあるとします。アプリケーションは1秒程度で処理ができるとします。この場合は、(とても運が悪いと詰まって1,2秒待つかもしれませんが)ジョブキューは一切必要ありません。ここにメールを1000通送るボタンをつけたとします。メール1000通なので、1分かかるとしましょうか。なると、メールを送ってる間は、他のアクセスは1分待たされることになります。普段1秒で終わるものが1分待たされる(しかも他人のせいで)というのは、許容できないでしょう。いう場合、メール送信処理をジョブキューに回します。ジョブキューのワーカーでメールを送るようにして、アプリケーションはジョブキューへの登録が済んだらすぐに処理を終わらせます。すると、他と同様、1分かかっていた処理は1秒程度で返せるようになるでしょう。(代わりにジョブキューのワーカーが1分間処理することになる)メールを10万通送りたい場合も、受付だけなので、すぐにレスポンスを返せます。なると今度はワーカーが大変です。(10万通はさすがにめっちゃ時間がかかる)。いう場合は、メールを送るサイズを1ワーカーあたり1000通とかに分割して並列で送ったりします。1サーバで処理しきれなければ、ワーカーが動くサーバを増やすことでスケールアップも可能になったりします。これがジョブキューを使うメリットです。以上、ジョブキューを使うと良いかもしれない例でした。感想だいたい書いてた。これにておしまいです。主催のmagnoliakさん、お疲れ様でした。