SolidQueue を Puma プラグインで動かして本番運用する

本記事は READYFOR 株式会社の READYFOR Advent Calendar 2025 の 6 日目の記事です。

はじめに

READYFOR 株式会社でバックエンド領域のテックリードをしている @yuji_developer です。

SolidQueue を Puma プラグインとして利用することで、「非同期処理をしたいけど専用のプロセスを起動したりサーバーを建てたくない（コストが……）」というときに便利ですというご紹介です。

SolidQueue の Puma プラグイン

SolidQueue は通常は専用のプロセスを起動して利用しますが、 Puma のプラグインとしても利用できます。
これを利用すると SolidQueue の起動や停止を Puma が代行してくれます。

最初にお断りしておくと、社内ユーザーの極少人数で利用するかつ利用頻度も少ないアプリケーションだったので採用した方法であり、通常は別のサーバーなりで専用のプロセスを起動して利用するほうが良いと思います。

https://github.com/rails/solid_queue
https://github.com/puma/puma

SolidQueue 導入の経緯

Web アプリケーションを作っていると非同期処理をしたいことがよくあると思います。

今回はデータ修正などをコンソールで行わないよう MaintenanceTasks を導入したくなりました。
https://github.com/Shopify/maintenance_tasks

MaintenanceTasks は非同期処理用のジョブキューが必要ですが、当時の対象アプリケーションでは非同期処理を必要としていなかったため、まだジョブキューがありませんでした。

できるだけコスト（お金と時間）を掛けずに導入できるものを選定したところ SolidQueue を選択することにしました。

主に以下の理由です。

1. Redis などを新たに導入しなくて良い
2. Puma プラグインを使えば別途 ECS などを用意する必要がない
3. Rails 8.0 からデフォルトになっている

導入方法

基本的に SolidQueue の README の Puma Plugin セクションにある通りです。

プラグインモードとして起動するための設定は config/puma.rb などの puma の設定ファイルに plugin :solid_queue を追加するだけです。

config/puma.rb

plugin :solid_queue

SolidQueue 自体は README の Configuration セクションに従って通常通り設定します。

Puma プラグインとして起動する時はデータベースのコネクションプール数の設定に注意が必要です。
アプリケーションと SolidQueue で同じ config/database.yml を参照することになるので、「Puma のワーカースレッド数」と「 SolidQueue のスレッド数 + 2 」のうち、大きい方をプール数に設定しておく必要があります。
SolidQueue のスレッド数に +2 するのは SolidQueue がワーカースレッドとは別に polling と heartbeat に利用するためです。
SolidQueue の README には以下に記載があります。

It is recommended to set this value less than or equal to the queue database's connection pool size minus 2, as each worker thread uses one connection, and two additional connections are reserved for polling and heartbeat.

例えば、以下の場合は pool は 5 以上に設定します。

• Puma のスレッド数: 3
• SolidQueue のスレッド数: 3

おわりに

このように特段難しい設定もなく、 README 通りに設定することで Puma プラグインとして利用できるのは便利ですね。
現在のところリソースの逼迫や謎のエラーなどもなく問題なく利用できています。
社内向けの小規模なアプリケーションなど、ちょっとした用途には便利なので検討してみてはいかがでしょうか。

明日の READYFOR Advent Calendar 2025 は kecy さんによる記事です。お楽しみに。