⏳
Background Jobs
Active Job + Sidekiq — 重い処理を非同期で実行
Background JobはHTTPリクエストサイクルから時間のかかる処理を分離し、別プロセスで処理するパターンです。
# app/jobs/send_welcome_email_job.rb
class SendWelcomeEmailJob < ApplicationJob
queue_as :default
def perform(user)
UserMailer.welcome(user).deliver_now
end
end
# 使用
SendWelcomeEmailJob.perform_later(user) # キューに登録（非同期）
SendWelcomeEmailJob.perform_now(user) # 即時実行（同期）
Active Job: RailsのJob抽象化レイヤー。バックエンド交換時もコード変更不要。
Sidekiq: 最も人気のJobアダプター。Redisベース、マルチスレッドで高スループット。
Solid Queue: Rails 8の新デフォルトアダプター。DBベースでRedis不要。ただしプロセスベースでワーカーがデフォルト3つ起動し約534MB（178MB×3）のメモリを占有 — Sidekiq（スレッドベース、1プロセス）よりメモリ消費が大幅に多い。Redis不要の代わりにメモリコストが大きいトレードオフ。
リトライ:
retry_on StandardError, wait: :exponentially_back_off, attempts: 5
discard_on ActiveRecord::RecordNotFound
キーポイント
1
rails generate job SendEmail → app/jobs/にJobクラス生成
2
performメソッドに実行ロジックを記述
3
MyJob.perform_later(args) — キューに登録（非同期実行）
4
queue_as :high_priority — キュー優先度指定
5
retry_on / discard_on — リトライ/破棄ポリシー設定
6
config.active_job.queue_adapter = :sidekiq — アダプター設定
メリット
- ✓ HTTPレスポンス時間短縮（ユーザー体験向上）
- ✓ 失敗時の自動リトライ
- ✓ アダプター交換容易（Sidekiq → Solid Queue）
- ✓ キュー別優先度管理
デメリット
- ✗ 別プロセス管理が必要（Sidekiqワーカー）
- ✗ デバッグが複雑（非同期環境）
- ✗ Redis依存（Sidekiq）またはDB負荷（Solid Queue）
- ✗ 順序保証が困難
- ✗ Solid Queue + SQLiteはマシン分離不可 — SQLiteはファイルベースでネットワーク共有不可のため、RailsとSolid Queueが同じディスク（同じマシン）で実行される必要あり。Fly.io等ではボリュームは1つのマシンにのみマウント可能で別マシンへの分離は不可。PostgreSQL/Redisならネットワーク接続可能でマシン分離が可能
ユースケース
メール送信
ファイル処理（画像リサイズ、PDF生成）
外部API呼出
データ集計/レポート生成
CSVインポート/エクスポート