COLUMNS

Redisの存在感が揺らいでいる中で学んだこと

ー商用ライセンス変更の波紋と、第二世代キュー管理への回帰

Redisはインメモリデータストアとして長く愛用されてきましたが、近年のライセンス変更や運用コストの問題から、多くのECプラットフォームが代替手段を模索しています。特にRailsコミュニティでは、「Redis一択」だった構成を再考する動きが加速しています。

まだ強力だが「Redis一強」ではなくなった理由

視点 Redis採用時のメリット 再考を促す要因
性能 単一ノードでもサブミリ秒応答。高スループット。 近年のPostgreSQLやMySQLのI/O改良で「十分速い」ケースが増加。
運用 シンプルな構成で始めやすい。 高可用構成を組むとクラスタ管理・監視が必須。メモリ増設＝コスト増。
ライセンス かつては完全OSS。 商用機能のライセンス変更で将来不安を指摘する声。

ポイント: Redisは今もキャッシュやPub/Subなどで輝くユースケースが多いです。一方、「永続層はDB、キューもDBで十分」と判断できるワークロードが増えているのが2025年の現実です。

インフラコストとメンテナンス負荷を見直す

物理コスト：
インメモリ型ゆえにデータ量＝メモリ量。アプリケーション数やトランザクションが増加するにつれてコストが上昇します。

運用コスト：
Redis Sentinel/Clusterの構築・障害対応・バージョンアップは、RDBの運用とは別に専門知識を要します。クラウドサービスでも一定の管理が必要です。

DB性能の向上：
10年前と比べ、PostgreSQL 15/16系はshared buffer管理やJIT最適化が進み、数万TPS規模でもボトルネックになりにくくなりました。

これらを踏まえ、「キューはデータベースで十分」と判断するプロジェクトが増えています。

PostgreSQL × FOR UPDATE SKIP LOCKEDが変えた常識

PostgreSQL 9.5以降で使用可能になったこの機能は、キュー管理の考え方を変えました。例えば、バックグラウンド処理の待ち行列（キュー）からタスクを取り出す際、次のようなSQL命令を実行します：

SELECT * FROM jobs
WHERE status = 'pending'
ORDER BY id
LIMIT 100
FOR UPDATE SKIP LOCKED;

キュー用テーブルからこのように取得することで下記が可能になります：

  • 複数ワーカーによる安全な並列処理：
    • 他のプロセスがロック中の行をスキップし、競合を回避
    • 異なるワーカーが同じジョブを二重処理するリスクを排除
  • トランザクション一貫性の確保：
    • データとキュー管理が同じデータベース内で完結するため、データの整合性を維持しやすい
  • シンプルなインフラ構成：
    • Redis不要でキュー管理が可能になり、システム構成がシンプルに

第二世代キュー管理gem ― Solid Queue

Flagshipでは2024年、RedisベースのSidekiqからSolid Queueへの移行を進めています。Solid QueueはRailsコアチーム製で、上記のFOR UPDATE SKIP LOCKEDを活用しながらジョブを安全に取り出す"第二世代"キューgemです。

実践事例：Shopify統合アプリケーションでの移行

具体的には、2つのShopify統合Railsアプリケーションを、Redis/SidekiqからSolid Queueに移行することで、インフラの簡素化と運用の信頼性に大きな恩恵を得ました。私たちのアプリケーションは主に、15分間隔で実行される定期的な注文エクスポートや出荷処理など、時間的制約のあるeコマース操作のためのバックグラウンド処理を扱っています。

PostgreSQLをバックエンドとするSolid Queueに切り替えることで、すべてのスケジュールされたジョブ機能を維持しながらRedisへの依存を排除しました。Solid QueueのRecurringTask機能により、CRON形式のスケジュールされたジョブを簡単なYAML設定で移植できたため、この移行は特に洗練されたものでした。既存のActiveJobクラスを最小限の変更で維持することができ、基盤となるキューインフラストラクチャのみを変更しながらビジネスロジックを保持しました。

この一元化により、単一のデータベース技術へのモニタリングが簡素化され、Heroku上のインフラコストが削減され、潜在的な障害ポイントのカテゴリー全体が排除されました。特に価値があったのは、2つ目のデータストアのための個別の接続プールやモニタリングシステムを管理する必要がなくなったことです。Webhook処理や注文履行が重要なパスとなるShopify統合アプリケーションにとって、これらのジョブがアプリケーションデータを格納するのと同じトランザクショナルデータベースによってバックアップされることで、データの一貫性が向上し、データベース間の同期に関する懸念が排除されました。

導入効果

項目 Before (Redis) After (Solid Queue)
インフラ構成 Rails + PostgreSQL + Redis Rails + PostgreSQL
月額コスト Redisクラスタ分が追加 0（既存DBに集約）
運用負荷 Sentinel監視・バージョン管理 DB運用に一本化
性能 より高い Redisほどではないが、処理規模・ユースケースによっては十分
障害耐性 Redis障害＝ジョブ停止 DBのフェイルオーバーに統一

歴史はめぐる─ delayed_jobの作者はShopify CEO

Redis以前、Rails界で定番だったデータベース型ジョブgemがdelayed_job。作者は現Shopify CEO、Tobias Lütke氏です。（CEOがRuby gemの作者級のエンジニアなの、かっこいいですね）

第一世代DB（delayed_job）→ Redis全盛（Sidekiq）→ 第二世代DB回帰（Solid Queue）の流れは、OSSとインフラコストのダイナミクスを物語る好例と言えるでしょう。

まとめ：選択肢が増えた今こそ「適材適所」

  • Redisは今も強力ですが、用途を再評価するフェーズに入りました。
  • PostgreSQLの進化とFOR UPDATE SKIP LOCKEDの登場で、ジョブキューをDBに戻す選択肢が現実的になりました。
  • 技術選定は性能 × コスト × 運用 × ライセンスリスクのバランス。特にOSSプロジェクトの商用化リスクは無視できません。
  • Redisか DBか──二者択一ではなく、「今の要件に一番フィットするか」を問い直すことが、2025年のベストプラクティスです。なおRedisには、まだたくさんのアプリケーションでお世話になっていますよ！

 

Store Assistant