Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則

p2: https://speakerdeck.com/morihirok/ruby-on-rails-nole-simifang
p4: https://speakerdeck.com/moro/dynamic?slide=41
p44: https://github.com/sidekiq/sidekiq/wiki/Best-Practices
p62: https://github.com/Shopify/job-iteration
p62: https://github.com/sidekiq/sidekiq/wiki/Iteration
p63: https://rubyonrails.org/2025/9/4/rails-8-1-beta-1
p64: https://github.com/sidekiq/sidekiq/wiki/Batches
p65: https://github.com/riseshia/sfn_job

Transcript

1. STORES 株式会社 Sidekiq その前に： Webアプリケーションにおける 非同期ジョブ設計原則 morihirok Kaigi on Rails 2025
2. 自己紹介 森弘 一茂 X: @_morihirok GitHub: morihirok STORES 株式会社 東京Ruby会議12 https://speakerdeck.com/morihirok/ruby-on-rails-nole-simifang
3. 非同期ジョブ 使ってる人🙋
4. https://speakerdeck.com/moro/dynamic?slide=41
5. https://speakerdeck.com/moro/dynamic?slide=41
6. 今ここ
7. 非同期 ジョブ！ 非同期 ジョブ！ 今ここ
8. 非同期ジョブあるある • 本番環境で何かおきたとき、非同期ジョブによって原因や 影響範囲の特定に時間がかかる • 非同期ジョブが途中で失敗し、総合的に何がどうなったの かわからなくなる • 長時間に及ぶ非同期ジョブによって、デプロイやメンテナ ンスインに影響を与えてしまう
9. 今日のテーマ 非同期ジョブの 考え方について 整理し理解する
10. 目次 1. なぜWebアプリには非同期ジョブが必要なのか 2. 非同期ジョブを使う前に考えること 3. 非同期ジョブの設計原則・指針 4. どのように原則を破るか
11. なぜWebアプリには 非同期ジョブが必要なのか
12. Webサーバは 長時間リクエストを 許容しにくい
13. • Webサーバは基本的に1リクエストを1プロセス/スレッド で処理する Webサーバのしくみ Webサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド
14. • プロセス/スレッド数以上のリクエストが同時に来ると待 ち行列に入る Webサーバのしくみ Webサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド
15. • プロセス/スレッドが占有される • 後続のリクエストを残されたプロセスで処理しなければな らなくなる 長時間リクエストが発生すると、Webサーバは困る Webサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド
16. • サーバがいわゆる「詰まっている」状態に 長時間リクエストが頻発すると本当に困る Webサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド
17. 長時間リクエストは他にもこんな問題がある • クライアント側からタイムアウトで打ち切られる • リソースを占有するような処理だと他のプロセス/スレッ ドに影響を与える • 1リクエストで様々な処理を行っていると観測しづらい • 途中で失敗するとシステムの整合性を崩す危険がある
18. • とはいえ1サーバのリソース（CPU/メモリなど）は有限で あり、増やせる数に限界がある Q: プロセス/スレッド数を増やせばよいのでは？ Webサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド プロセス/スレッド
19. • とはいえサーバを増やすのはコストがかかる Webサーバ Webサーバ Q: サーバを増やせばよいのでは？ Webサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド
20. じゃあ長時間になる処理はやめよう！ • とはいえ実際のWebアプリケーションに求められることを 考えると、現実的ではない • 一括処理、メール送信、外部API実行など、どうしても長 時間になる処理を求められる
21. • 非同期ジョブのプロセス/スレッドに処理を委譲すること で、リクエストが長時間になるのを防ぐ そこで非同期ジョブの出番となる Webサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド 非同期ジョブ
22. つまり 非同期ジョブは Webアプリを速く＆安くする 強力な仕組み
23. 非同期ジョブを使う前に考えること
24. それ、本当に 非同期ジョブ 必要ですか？
25. 非同期ジョブはシステムに複雑性を持ち込む • 基本的には同期的に処理するより、非同期ジョブを導入し たほうが処理が複雑になる • 結果として機能追加や不具合対応の難易度が上がる
26. 例題：外部サービスのAPI実行結果をブラウザに表示 Webサーバ 外部サービス ブラウザ • 非同期ジョブを使わない場合
27. • 非同期ジョブを使う場合 例題：外部サービスのAPI実行結果をブラウザに表示 Webサーバ 外部サービス ブラウザ 非同期ジョブ APIの結果 リクエスト1
28. • 非同期ジョブを使う場合 例題：外部サービスのAPI実行結果をブラウザに表示 Webサーバ 外部サービス ブラウザ 非同期ジョブ APIの結果 リクエスト1 リクエスト2 ポーリング？ WebSocket？
29. • 非同期ジョブを使う場合 例題：外部サービスのAPI実行結果をブラウザに表示 Webサーバ 外部サービス ブラウザ 非同期ジョブ APIの結果 リクエスト1 リクエスト2 エラーハンドリン グどうする？
30. • 非同期ジョブを使う場合 例題：外部サービスのAPI実行結果をブラウザに表示 Webサーバ 外部サービス ブラウザ 非同期ジョブ APIの結果 リクエスト1 リクエスト2 アプリのDB使う？ 使わない？
31. • 非同期ジョブを使う場合 例題：外部サービスのAPI実行結果をブラウザに表示 Webサーバ 外部サービス ブラウザ 非同期ジョブ 外部APIの結果 リクエスト1 リクエスト2 明らかに意思決定が増え複雑に...
32. 非同期ジョブの導入はトレードオフがある • 外部APIや一括処理であれば非同期ジョブを導入する、と いう機械的な判断はできない • 複雑さの受け入れ、スループットの向上、ユーザー体験、 様々な事情を天秤にかけ、その都度判断していく必要があ る • 本当に有効な場面か考えることが重要
33. それ、バッチ処理でも 良くないですか？
34. 非同期ジョブじゃなくてバッチ処理でできないか考えてみる • バッチ処理で行ったほうがシステムがシンプルに設計でき ることがある ◦ ユーザーに即時で結果を返す必要がない処理 ◦ 大量のデータをまとめて扱う処理処理
35. 例題：売上分析機能 ※表示しているのはテストデータなのでご安心ください
36. 例題：売上分析機能 Webサーバ ブラウザ 非同期ジョブ 計算結果 リクエスト1 リクエスト2 • 非同期ジョブを使う場合
37. 例題：売上分析機能 Webサーバ ブラウザ 非同期ジョブ 計算結果 リクエスト1 リクエスト2 • 非同期ジョブを使う場合 ポーリング？ WebSocket？
38. 例題：売上分析機能 Webサーバ ブラウザ 非同期ジョブ 計算結果 リクエスト1 リクエスト2 • 非同期ジョブを使う場合 ジョブ失敗時 待たされる ジョブの終わりが 読めない
39. 例題：売上分析機能 Webサーバ ブラウザ • バッチ処理を使う場合 計算結果 バッチ処理 あらかじめ 計算しておく
40. 例題：売上分析機能 Webサーバ ブラウザ • バッチ処理を使う場合 計算結果 バッチ処理 シンプルに作れる！
41. アーキテクチャではすべてがトレードオフ だ。だからこそ、アーキテクチャのあらゆる 問いに共通する答えは、「場合による」なの だ。この答えにいら立つ人は多いだろう。し かし、残念ながらそれが真実だ。 Mark Richards, Neal Ford ソフトウェア アーキテクチャの基礎 p30
42. 場合によるからこそ逡巡が起きる
43. 非同期ジョブの設計原則・指針
44. Sidekiq の Best Practice より • Make your job parameters small and simple ◦ ジョブのパラメータは小さくシンプルにする • Make your job idempotent and transactional ◦ ジョブは冪等でトランザクショナルにする https://github.com/sidekiq/sidekiq/wiki/Best-Practices Sidekiq に限らない ベストプラクティス
45. 非同期ジョブは 短時間で終わる シンプルな処理にする
46. => 長時間ジョブを避ける
47. 例題：注文情報一括処理機能 ※表示しているのはテストデータなのでご安心ください
48. 例題：注文情報一括処理機能 ※表示しているのはテストデータなのでご安心ください UIから一括選択でき 一括操作ができる
49. 例題：注文情報一括処理機能 ※表示しているのはテストデータなのでご安心ください 選択対象は 10,000件程度になりうる
50. 非同期ジョブ 処理 非同期ジョブ 処理 非同期ジョブ 処理 考えうる設計 まとめて処理する設計 分けて処理する設計 非同期ジョブ 処理 処理 処理 処理 非同期ジョブ 処理
51. 非同期ジョブ 処理 非同期ジョブ 処理 非同期ジョブ 処理 考えうる設計 まとめて処理する設計 分けて処理する設計 非同期ジョブ 処理 処理 処理 処理 非同期ジョブ 処理 こっちのほうが 短時間でシンプル
52. なぜ？の前に非同期ジョブのしくみについて • 非同期ジョブも基本的にジョブキューに積まれたジョブを 1つずつ1プロセス/スレッドで処理する 非同期ジョブサーバ プロセス/スレッド プロセス/スレッド プロセス/スレッド ジョブキュー 行列
53. つまり Webサーバと 同じように考えられる！
54. 短時間でシンプルなほうが全体のスループットが上がる • Webサーバと同様に1つのジョブが短時間で終わるほうが 全体のスループットが上がる • 他ジョブがリソースを占有して処理の遅延が起こるという ケースも減らせる
55. 失敗時の再試行において考えることが少なくなる • 長時間ジョブの途中で失敗した場合にどのように復旧させ るかは悩ましい問題になる ◦ 復旧するための設計を別途考えたり... • 小さくシンプルな処理であれば何も考えずリトライすれば すむケースが多い
56. 可観測性も良くなる • 長時間ジョブは実行状況が見えづらく、観測するためには 別途ログを書き込んだりAPMにツールを送ったりと観測す るための実装を行う必要がある • 短時間で終わるシンプルなジョブであれば、開始と終了が 観測できれば十分なケースが多い
57. デプロイ時の影響もなくなる • 非同期ジョブワーカーは多くの場合Webサーバと同様にデ プロイ時にプロセスを停止させる必要がある • 長時間ジョブがシステムに存在する場合、デプロイ時にま だジョブが動いていたときの考慮が必要になる
58. 非同期ジョブ設計原則 非同期ジョブは 短時間で終わる シンプルな処理にする
59. どのように原則を破るか
60. 現実的には長時間ジョブは存在しうる • 実現したいユーザー体験を考えると長時間ジョブでやるし かないというケース ◦ なるべくリアルタイム性はほしい ◦ 1件ごとの順序性が求めれる ◦ 全件成功したら最後に行いたい処理がある • 長時間ジョブである必要性はないが、すでに目の前に長時 間ジョブが存在しているケース
61. 長時間ジョブの運用で考えるべきポイント • デプロイ・メンテナンスインなどなんらかの理由で途中終 了しうるので、中断・再開ができるように作る • 長時間ジョブの中で例外が発生したときのハンドリング
62. 現代では便利なライブラリがあるのでそれを使うのを推奨 • https://github.com/Shopify/job-iteration ◦ ActiveJobで中断・再開を記述できる • https://github.com/sidekiq/sidekiq/wiki/Iteration ◦ Sidekiqで中断・再開を記述できる
63. Rails 8.1 からActive Job Continuationが導入 https://rubyonrails.org/2025/9/4/rails-8-1-beta-1
64. Sidekiq Pro であれば Batches が使える • https://github.com/sidekiq/sidekiq/wiki/Batches • ジョブ自体を小さい粒度に抑えつつ、全体の途中経過を見 れたり完了時のコールバックを差し込むことができたりす る • 長時間ジョブを避ける設計ができる • Sidekiq Proを使っていて順序保証が不要な処理であれば 候補になる
65. ちなみにSTORESだとこんな機構があります • https://github.com/riseshia/sfn_job • ActiveJob からAWS Step Functions経由でECS Taskを 実行し、ジョブの処理を行う • 分離されたプロセスで長時間ジョブを実行させることで 諸々の制約から逃れる riseshia a.k.a シムさん
66. まとめ
67. まとめ：非同期ジョブ設計の考え方 本当に非同期ジョブで 作るべきか？
68. まとめ：非同期ジョブ設計の考え方 本当に非同期ジョブで 作るべきか？ バッチ処理で作れないか？
69. まとめ：非同期ジョブ設計の考え方 本当に非同期ジョブで 作るべきか？ バッチ処理で作れないか？ 長時間ジョブを避ける 設計ができないか？
70. まとめ：非同期ジョブ設計の考え方 本当に非同期ジョブで 作るべきか？ バッチ処理で作れないか？ 長時間ジョブを避ける 設計ができないか？ Active Job Continuation などの導入
71. 非同期ジョブ設計原則 非同期ジョブは 短時間で終わる シンプルな処理にする
72. 72 04 STORES でのカンファレンス活用事例