Solid Queueのパフォーマンス特性に関する検証と考察
DeNA Engineeringは、Ruby on RailsプロダクトのジョブキューシステムをSolid Queueに移行する過程で実施した負荷試験の結果、Solid Queueがシングルスレッド設定で約1000 job/s、マルチスレッドモードでは約2000 job/sのスループットを実現可能なパフォーマンス特性を確認したと報告した。
キーポイント
Solid Queueの実用パフォーマンス実証
負荷試験により、Solid Queueはシングルスレッド設定で約1000 job/s（1日約8640万ジョブ）、マルチスレッドモードでは約2000 job/sのスループットを安定または不安定ながら処理可能であることが確認された。
高負荷環境での運用知見
高負荷環境では、Solid Queueのワーカープロセス数の調整が必要であり、extra claimパッチの利用によりパフォーマンス向上が可能であることが示された。
実プロダクトへの適用背景
移行対象は全世界配信の複数モバイルゲームで利用される基盤サーバーシステムであり、高品質かつ高いパフォーマンスが求められる環境での実証事例となっている。
業界実績との比較検証
37signalsのDHH氏が報告した「1日数千万ジョブ」処理実績を超える負荷（約8000万ジョブ/日）でも処理可能であることが試験で示された。
影響分析・編集コメントを表示
影響分析
この記事は、Ruby on Railsエコシステムにおけるジョブキューシステムの実用的なパフォーマンスデータを提供し、大規模プロダクトでのSolid Queue採用判断に役立つ実証情報となる。特に、既存の業界実績を上回る数値検証は、技術選定の信頼性を高める重要な知見を提供している。
編集コメント
実プロダクトでの負荷試験結果に基づく具体的な数値データが掲載されており、技術選定の参考になる実用的な記事。ただし、AI/機械学習分野との直接的な関連性は限定的。
はじめに
ゲームサービス事業本部の三軒家です。
社内のとある Ruby on Rails プロダクトにおいて、ジョブキューシステムのバックエンドを Solid Queue に移行するプロジェクトを推進しています。
本記事では、Solid Queue への移行に際して実施した負荷試験の内容と、その結果得られた Solid Queue のパフォーマンス特性に関する知見についてご紹介します。
TL; DR
- Solid Queue は、シングルスレッド設定において、約 1000 job/s のスループットを安定して処理できる。
- 1000 job/s は 86,400,000 job/day（約 8000万 job/日）に相当する。
- 37signals の DHH 氏は「Tens of millions of daily HEY jobs now run off SQ exclusively!（数千万件/日）」と発言しているが、我々の検証ではそれを上回る負荷も処理可能であることが示された。
- 参考: https://x.com/dhh/status/1816913608024232032?s=20
- マルチスレッドモードを利用するか、後述の extra claim パッチを適用すれば、不安定さはあるものの、約 2000 job/s 程度の負荷であれば処理できる。
- 高負荷環境では、Solid Queue のワーカープロセス数の調整が必要となる。
Solid Queue 移行の背景
今回 Solid Queue への移行を行ったプロダクトは、全世界に配信されている複数のモバイルゲームタイトルで利用されている基盤サーバーシステムです。このプロダクトは Ruby on Rails で長年開発されており、AWS および Google Cloud の両方で運用されています。全世界展開を行うという性質上、高品質でありながら高いパフォーマンスを発揮することが求められています。
原文を表示
はじめに ゲームサービス事業本部の三軒家です。
社内のとある Ruby on Rails プロダクトにて、ジョブキューシステムのバックエンドを Solid Queue に移行するプロジェクトを推進しています。
この記事では、Solid Queue への移行に際して実施した負荷試験の様子と、その結果として得られた Solid Queue のパフォーマンス特性に関する知見についてご紹介しようと思います。
TL; DR Solid Queue は、シングルスレッドな設定において、 1000 job/s 程度のスループットを安定して処理することができる 1000 job/s = 86400000 job/day なので、8000万 job/day ということになる 37signals1 の DHH氏は Tens of millions of daily HEY jobs now run off SQ exclusively! (数千万/day) と発言しているが、それを超える負荷でもさばき切れるということが示せた https://x.com/dhh/status/1816913608024232032?s=20 さらに、マルチスレッドモードを利用したり、後述の extra claim パッチを利用すれば、不安定ながらも 2000 job/s 程度の負荷であれば捌き切ることができる 高負荷環境においては、Solid Queue のワーカープロセス数の調整が必要となる Solid Queue 移行の背景 今回 Solid Queue への移行を行ったプロダクトは、全世界へ配信を行う複数のモバイルゲームタイトルで利用されている、基盤サーバーシステムです。このプロダクトは Ruby on Rails で長年開発されており、AWS / Google Cloud の両方で運用されています。全世界展開を行うという背景から、高品質でありながらも高いパフォーマンスを発揮しなければならないというミッションが課されています。
関連記事
年間600時間を節約したKubernetesの一行修正
チームがTerraform変更を計画・適用するツールAtlantisを再起動する際、Kubernetesの安全なデフォルト設定が原因で30分間のダウンタイムが発生していた。月100回の再起動で50時間以上のエンジニア時間がブロックされていたが、一行の修正で問題を解決した。
データサイエンティストが知るべき Python の必須概念 5 つ
この記事は、データサイエンティストがスパゲッティコードから高速で生産レベルのデータパイプラインへ移行するために必要な Python の 5 つの必須概念を詳しく解説しています。
ミリ秒コンバーター
Simon Willison氏は、LLMの応答時間をミリ秒で表示する仕様を確認し、手動計算の手間を省くため「Millisecond Converter」ツールを作成した。