Q&A
> ユーザーのステータス更新に遅延処理を使いたく
どうしてそのような実装にしているのでしょうか（ステータス更新がそれだけ煩雑で時間のかかる処理なのでしょうか）？
前提・実現したいこと
タイトルの通りです。
現在delayed_jobを使っており、sidekiqへ移行しているところです。
ユーザーのステータス更新に遅延処理を使いたく、
多重実行を防ぐため、JOBは処理状況を取得してviewにステータスを表示しておきたいです。
delayed_jobの場合は /delayed_jobs にブラウザからアクセスすると実行中のJOBの状態が分かるので
jsで値を取ってきて処理状況をviewに表示できていたのですが
sidekiqの場合そのような機能がないため、どう実装するべきか迷っています。
試したこと
jsを使わず、modelに定義したメソッドでsidekiq内にJOBがあるかを見て判定させようとしています。
rb
1def async_job_enqueued?(user_id) 2 3 # 実行中JOBを取得して配列にする 4 job = Sidekiq::Workers.new.to_a 5 6 # ごにょごにょ でJOBに渡った user_id を取りにいく 7 return true if job.[ごにょごにょ].include?(user_id) 8 false 9 10end
これをviewでは if async_job_enqueued?(user.id) として、
ユーザーのステータスを表示したい場所に入れると、
JOBがあれば 処理中... 、なければステータスを表示とできるのですが
[ごにょごにょ]の部分にSidekiqが持っている多次元配列・多次元Hashが大量に存在するため、
flatten一回で平坦化できなかったり、digで取りにいくのも難しく複雑化してしまう状況です。
難しく考えすぎている気がするのですが、いまいち似たような情報がなく、
・そもそももっといいアプローチがないか？
・ブラウザからsidekiqの進行状況をJSONで取得する方法がないか？
上記2点が知りたいです。
よろしくお願いいたします。
補足情報（FW/ツールのバージョンなど）
rails (6.0.3.2)
sidekiq (6.1.1)
情報不足しており失礼しました。
1件ではなく複数のユーザーのステータスを一括変更したく、
それぞれのデータでupdateが走る際のafter_save等もあり時間のかかる処理になっています。
> 1件ではなく複数のユーザーのステータスを一括変更したく、
> それぞれのデータでupdateが走る際のafter_save等もあり
> 時間のかかる処理になっています。
ということですが、この処理を見直す方向で検討するというアプローチも良さそうですね。
この処理以外にも遅延したい処理が複数件存在しています。
例えば大量のユーザーへのメール配信など、時間がかかる部分はどうしようもなく数も多いため、
大元の実装をいじるという方向性は現実的ではないという状態です・
シンプルにsidekiqのキューの情報を取得しておいて、viewで進行状況によって表示を変える方法はないのでしょうか？
sidekiqを利用しているサービスは多いと思うのですが、この辺りは運用でカバーされているんですかね。。
> sidekiqを利用しているサービスは多いと思うのですが、この辺りは運用でカバーされているんですかね。。
Sidekiqに流すものは「そのうちに実行されればそれでいい」ので、進行状況を取得することがあまりないです。
https://github.com/Kondzolko/sk_progress_bar
その他にも「sidekiq progress bar」で検索してみてください。
プログレスバーが出せるんですね。何か使えそうな感じがしますのでこちらも調べてみます。
ありがとうございます！
回答1件
0
ベストアンサー
例えば大量のユーザーへのメール配信など、時間がかかる部分はどうしようもなく数も多いため、
大元の実装をいじるという方向性は現実的ではないという状態です
それこそ、データはすぐに確定させて、メール送信などの「時間のかかる処理」だけ遅延させればそれで済む話なのではないでしょうか。
投稿2020/10/23 02:11
総合スコア146018
メールの大量送信について知見がない中で、こんなところで聞いてよいのかわかりませんが・・・
「メール送信は時間のかかる処理」という言葉をたまに見かけます。
これは一般的にSMTPで送信しているという認識になるのでしょうか？
それともWeb APIで送信してもやはり時間のかかる処理になるのでしょうか？
https://sendgrid.kke.co.jp/blog/?p=5009
JOB側のロジックに問題があってメールが送信されないようなケースを考えると、
データを確定させると二重送信などは防げますが、JOBがリトライor失敗した場合に画面表示上は送信できているという状況が発生しそうな不安がありました。
sidekiqは「そのうちに実行されればそれでいい」というものであることを理解しましたので、
Rails側はsidekiqがとりあえず実行される前提で動かして、
もし遅延処理に失敗したら何らかのJOB監視によってJOBの実行状況を把握して、
動かなかったJOBはそこで把握・デバッグして再度手動で実行するような方向で行こうと思います。
大変助かりました。
@no1knows 今回はSMTPのため時間のかかる処理になってしまっています。。
WebAPIを使うと早く処理できるので、メールを遅延させているところに関しては
メールの一斉送信サービスを使ってスケジュールで動かすアプローチはありかも知れないです。
qazuさん、詳しい説明をありがとうございます。
いつも不思議に思っていたのでスッキリしました！
あなたの回答
tips
プレビュー
