数分から数時間かかる処理を、どう動かしますか

キューで細かく分ける

キューは、仕事を順に並べておく待ち行列です。API は「この仕事をやって」と積むだけですぐ返し、裏の担当 (コンシューマー) が取り出して処理します。1 万人にメールを送るなら、1 人分ずつか数十人分ずつの小さな仕事に分けて積みます。

小さく分けると、1 つが失敗してもその分だけやり直せます。担当の数を増やせば並べて速く進められます。キューの例は、AWS の SQS、Google Cloud の Pub/Sub、Cloudflare の Queues などです。

何回やり直しても失敗する仕事は、別の置き場 (デッドレターキュー) に移して、人があとで見ます。いつまでも同じ仕事を回し続けないためです。

手順を記録して途中から再開する

「データを取る、変換する、保存する、通知する」のように手順が長い物は、各手順が終わったことを記録するワークフローの仕組みに乗せます。途中で落ちても、済んだ手順は飛ばして続きから動きます。AWS の Step Functions、Google Cloud の Cloud Workflows、Cloudflare の Workflows などがこの役です。

キューでもワークフローでも、同じ仕事が 2 回動くことがあります。だから「すでに送った人には送らない」「同じ番号の書き込みは上書きで済む」のように、2 回動いても結果が変わらない (冪等な) 作りにしておきます。

重い所だけ逃がす (トレードオフ)

1 つの単位がそれでも数十分かかる、たくさんのメモリが要る、といった処理は、軽い実行環境の時間の上限に当たります。その部分だけ、長く動けるバッチ用の実行環境に渡します。Google Cloud の Cloud Run Jobs、AWS の Batch や ECS のタスクなどです。上限の長さはサービスや設定で変わるので、選ぶ前に確かめます。

分けるほど、どこで何が詰まっているかが見えにくくなります。仕事ごとに番号を付けてログをつなぐ、進み具合を画面や表で見られるようにする、などの手当てが要ります。件数が少なく数分で終わる処理なら、毎晩動く定期の処理 1 本で十分なこともあります。

話すときは、自分が関わったサービスで、長い処理をどう分けたか、何件をどれくらいの時間で流したかの例を 1 つ用意します。