Cloudflare WorkersでCronのN+1が顕在化した。全件処理をQueueへ分ける

DRANK

Cron Triggerで全ユーザーの状態を更新する処理を、Cloudflare Workersへ移しました。DBから対象IDを1回取得し、N件の対象それぞれで外部APIを1回呼ぶ。「一覧取得の1回 + 対象ごとのN回」という、N+1の形です。EC2のcronでは、長い全件処理として動いていたため、この構造を強く意識していませんでした。ここでいうN+1は、ORMで関連recordを1件ずつ読む典型的なDBのN+1 queryそのものではありません。しかし、対象件数Nに比例して外部I/Oが増える点は同じです。Cloudflare Workersへ移すと、1 invocationあたりのsubrequest上限があるため、このN+1が実行失敗として顕在化しました。その後CloudflareはPaidプランの既定上限を1,000から10,000へ引き上げ、最大1,000万まで設定できるようにしています。それなら設計変更は不要だったのでしょうか。私は、上限が緩和された現在でも、Cron 1回の中でN件すべてを実行しない方がよいと考えています。CronにN+1が生まれていた元の処理は、対象を探す1回のDB queryと、対象ごとのN回の外部API呼び出しで構成されていました。1: 対象ユーザーを一覧取得 N: ユーザーごとに外部APIを呼ぶ Cron 1回で全対象を処理すると、Nの増加と一…