「受け付けました」と「完了しました」は違う。バックグラウンド処理の基本

キューは、あとで処理する仕事を渡す場所

バックグラウンド処理は、画面からの一回の応答を待たせ続けず、別の処理として仕事を進める方法です。依頼を渡すために使われる仕組みの一つがキューです。

キューへ仕事の情報を送り、それを受け取る処理が変換や集計などを実行します。ただし、「列に並べる」というイメージだけで、必ず一件ずつ順番どおりに終わると考えることはできません。実行数や順序の保証は、使うサービスと設定で違います。

Cloudflare Queuesの仕組みの説明でも、メッセージの順序は保証されないと説明されています。順番に依存する仕事なら、同じ対象への処理をどう整理するかが別の設計課題になります。

受付番号があれば、進み具合をたどれる

たとえば、架空の名簿取り込みを考えてみましょう。ファイルを受け取って受付番号を返した段階では、全行の検査や登録が終わっていないかもしれません。

その時点で「登録が完了しました」と表示すると、利用者は新しいデータが使えると考えてしまいます。「受け付けました。処理結果は一覧から確認できます」のように、今の状態と戻る場所を伝えるほうが実態に合います。

次は、利用者向けに状態を分けるための記事独自の例です。

画面を閉じても依頼の記録へ戻れると、同じファイルをもう一度送るべきか迷いにくくなります。進捗を示せない処理で、根拠のない完了率を表示する必要はありません。

同じ仕事が二度届くことを考える

信頼性のために、キューがメッセージを再配信する場合があります。Cloudflare Queuesの配信保証は、少なくとも一度届ける方式を基本とし、まれに複数回届くことがあると説明しています。

したがって、メッセージを受け取るたびに新しい登録をすると、同じ仕事が重複する可能性があります。依頼の識別子と処理済みの状態を使い、再配信でも意図した結果になるようにする考え方が役立ちます。

これは「キューを使えば二重処理が自動でなくなる」という話ではありません。届ける側の保証と、受け取った仕事を安全に実行する仕組みを組み合わせる必要があります。

失敗した仕事の行き先を決めておく

一時的な障害なら再試行で成功するかもしれませんが、壊れたファイルや不正な入力は、繰り返しても直らない場合があります。再試行の上限と、上限に達したあとの扱いが必要です。

Cloudflare QueuesのDead Letter Queueの説明では、再試行上限に達したメッセージを別のキューへ送る構成を紹介しています。保管期間や処理の設定があるため、そこへ送れば無期限に保全されるとは考えられません。

運用では、誰が失敗を確認し、原因を直したあとにどの依頼を再開するかまで決めると、取り残された仕事を見つけやすくなります。利用者には、受付番号と対応状況を結び付けて示す方法が考えられます。

まとめ

バックグラウンド処理は、依頼の受付と実行を分ける仕組みです。状態をたどれること、再配信で重複しないこと、失敗した仕事を回収できることまで含めて考えると、待つ側にも運営側にも分かりやすくなります。

関連する仕組みは冪等性の基本と、変更を知らせるWebhookで説明しています。