요청은 긴 일을 소유 안 해

"몇 시간짜리 일을 소유한 요청은 노트북 닫아서 죽일 수 있는 job 이야."

솔깃한 실수

'이 아카이브 전사해줘' 를 짓는 뻔한 방법은 그걸 하는 요청 핸들러야: 브라우저가 endpoint 를 부르고, 핸들러가 영상들을 돌며 각각 전사하고, 아카이브가 끝나면 return. 데모에선 돼. 프로덕션에선 재앙이야 — 요청은 상상 가능한 가장 부서지기 쉬운 소유자거든. 그 수명이 TCP 연결, 브라우저 탭, 호텔 Wi-Fi 신호, 노트북 뚜껑에 묶여 있어. 그 중 아무거나 끝나면 몇 시간짜리 job 이 중간에, 반만 된 채로, 깔끔하게 재개할 방법 없이 죽어.

더 깊은 문제는 timeout 이 아냐. 소유권이야. 요청이 일을 소유하면, 일은 요청이 사는 동안만 존재해 — 그리고 요청은 짧게 설계됐어. 버려지도록 만들어진 컨테이너 안에 몇 시간짜리 가치를 넣은 거야.

계획, enqueue, 관찰 — 절대 소유 안 함

Recall 은 그걸 뒤집어. 요청은 절대 전사를 돌리지 않아. 싸고 빠른 세 가지 중 하나를 하고 즉시 return 해:

계획(Plan) — run 이 뭘 할지(어떤 영상, 몇 개) 를 아무것도 안 쓰고 계산.
enqueue — durable batch 랑 그 queued job 을 DB 에 만들고, batch id 를 return. 밀리초.
관찰(Observe) — 이미 도는 batch 의 현재 상태, 진행, ETA 를 읽음.

실제 몇 시간짜리 전사는 persistent worker 가 소유해 — 운영체제의 서비스 매니저가 살려두는, 어떤 요청과도 독립인 프로세스. queued job 을 claim 하고 누가 보든 말든 갈아. 그래서 operator 노트북 연결을 끊거나 status 명령을 죽여도 batch 엔 아무 일 없어. 일은 애초에 요청에 없었어. 요청은 durable 의도를 쓰고 걸어 나갔을 뿐이야.

테스트: 노트북을 닫아

이걸 제대로 했는지 보는 한 줄 테스트: 일을 시작하고, 노트북을 닫아. 계속 도나? 그렇다면 일이 persistent worker 가 소유한 durable queue 에 살아. 아니라면 어떤 요청이 몰래 job 을 인질로 잡고 있고, 첫 불안정한 네트워크가 몇 시간을 날려. Recall 은 설계상 이 테스트를 통과해: 요청의 유일한 일은 뭐가 일어나야 하는지 durably 기록하는 거고, 모든 요청보다 오래 사는 worker 가 그걸 일어나게 해.

Code

요청은 enqueue 하고 return; worker 가 시간을 소유·python

# 틀림: 요청이 몇 시간짜리 일을 소유
@router.post('/archive/transcribe')
async def transcribe_archive(req):
    for video in select_videos(req):
        do_transcription(video)   # 몇 시간 block
    return {'status': 'done'}     # 탭 닫으면 전부 죽음

# 맞음: 요청은 의도를 쓰고 밀리초에 return
@router.post('/archive/start')
async def start_batch(req):
    batch = create_batch(req)             # durable 행
    enqueue_jobs(batch)                    # queued, DB 가 소유
    return {'batch_id': batch.id}          # 즉시 return

# 요청이 아니라, OS 서비스 매니저가 살려두는 persistent worker 가
# 그 job 들을 claim 하고 몇 시간을 돌린다.

Exercise

네 일에서 느린 걸 inline 으로 하는 endpoint 를 찾아(아니면 상상해) — 리포트 생성, 업로드 처리, 긴 export. 노트북 닫기 테스트를 적용해: 호출자가 중간에 끊기면 일이 유실돼? endpoint 는 durable 의도 record 만 만들고 핸들을 return 하게, 별도 persistent worker 가 느린 부분을 하게 다시 설계해. 핸들이 뭔지랑 호출자가 진행을 어떻게 확인하는지 적어봐.

Hint

패턴엔 움직이는 부분이 셋: (1) durable job/batch 행을 쓰고 id 를 빠르게 return 하는 endpoint, (2) 어떤 요청 밖에 살며 그 행을 claim 하는 worker, (3) 호출자가 id 로 poll 하는 status endpoint. 셋을 다 못 대면, 느린 일이 아직 요청 안에 갇혀 있을 거야.