FastAPI 문서 처리 시스템에서 BackgroundTasks와 Celery + Redis 중 선택 기준 정립: CPU 바운드 OCR 작업의 서버 블로킹 문제 해결

Context

FastAPI의 async/await는 I/O 바운드 작업에만 효과적이며, OCR 처리처럼 CPU 바운드인 2~30초 소요 작업은 서버 스레드를 점유하여 다른 요청을 처리할 수 없다. BackgroundTasks는 메모리 기반이므로 서버 재시작 시 진행 중인 작업이 손실되는 문제가 발생한다.

Technical Solution

• BackgroundTasks: FastAPI 내장 기능으로 UUID 기반 job_id 생성 및 메모리 딕셔너리에서 상태(pending → processing → completed/failed) 추적
• Celery + Redis 도입: Redis를 broker(큐 저장소, localhost:6379/0)와 backend(결과 저장소, localhost:6379/1)로 사용하여 작업 영속성 확보
• Celery 설정: task_serializer='json', accept_content=['json'], task_track_started=True, worker_prefetch_multiplier=1로 구성하여 한 번에 1개 작업 처리
• 작업 설정: @celery_app.task(bind=True, max_retries=3)으로 자동 재시도 3회 및 자체 참조를 통한 재시도 로직 구현
• 상태 추적: Redis hash(f"job:{job_id}")에 status, progress, result를 실시간 저장하여 API 엔드포인트 /status/{job_id}에서 조회

Key Takeaway

CPU 바운드 작업에서 async 동시성은 효과가 없으므로, 프로토타입 단계에서는 BackgroundTasks로 시작하되 신뢰성(재시작 중 작업 손실 방지)과 확장성(분산 워커)이 필요하면 Celery + Redis 조합으로 전환해야 한다.