越智 翔一

## 課題を解決した方法 メモリ使用量が多いSidekiqのジョブを別の非同期処理実行基盤に移行しました。 ざっくり言うと、Google Cloud WorkflowsからCloud Run Jobsを起動してバックグラウンド処理するようなアーキテクチャにしました。 ## 課題 1. メモリ使用量の問題 - `ある日付の特定の時間に対する空き枠`などの数十億を超えるレコード数のテーブルを更新処理するジョブの増加により、Sidekiqを実行するRailsアプリケーションのメモリ使用量が増大していた。 - 一部のジョブは Sidekiqのメモリ制限を超え、OOM Killerによってプロセスが強制終了されることがあった。 - 無料版のSidekiqをマルチスレッド環境下で動かしていたので、プロセスがクラッシュした場合には同一プロセス内の処理中のメッセージはすべて失われてしまっていた。 - 上記で述べたメモリ使用量が大きいジョブの実行が失敗することによって、その結果を待つユーザーをかなり待たせることになってしまっていた。 2. Sidekiq-Pro のコストの高さ - OOM Killerによって強制終了されたRedisのキューがジョブが完了するまで保持されるように、**Sidekiq-Pro（$99/月 ≒ 約15,000円）** の導入を検討したが、組織にとってはコストが高く、尚且つジョブの成功結果を待つユーザーの待ち時間は解消できなさそうだった。