FreeComics

대용량 ZIP을 한 요청으로 받으면 네트워크 끊김·타임아웃 시 처음부터 다시 올려야 했습니다. FreeComics에서는 request_id를 먼저 발급(/translation-re/init)한 뒤, 클라이언트가 파일을 청크로 나눠 POST /translation-re/chunk로 보냅니다.

각 청크는 Busboy로 multipart 스트림을 받아 /mnt/nvme/uploads/{request_id}/{chunkIndex}.part에 쓰고, Redis 해시 upload_chunks:{request_id}에 인덱스를 pending → done으로 마킹합니다. 헤더 x-request-id, x-chunk-index, x-chunk-total이 이 상태를 맞춥니다.

상세 조회 API는 Redis에서 첫 pending(없으면 다음 인덱스)을 chunk_start_idx로 돌려주어, 클라이언트는 그 지점부터만 재전송합니다. 전부 done이면 /merge가 worker_threads mergeWorker로 part를 합치고 번역 큐에 넣습니다.

여러 사용자가 동시에 대용량 ZIP을 올리거나 압축 해제하면 디스크·메모리 압박이 커집니다. 업로드 시작 전 /translation-re/preflight에서 file_size를 받아 ensureUploadCapacity로 허용량을 검사합니다.

상수 MAX_ING_FILE_SIZE = 300GB이며, Redis 키 uploading:active:*에 저장된 진행 중 용량을 합산합니다. 합산 + 요청 크기가 한도를 넘으면 remaining_bytes·lacking_gb와 함께 400을 돌려 새 업로드를 막습니다.

허용 시 uploading:active:{request_id}에 file_size를 TTL 600초로 기록하고, 청크 진행·병합 완료 시 키를 갱신·삭제합니다.

업로드·압축 해제·번역을 한 Node 프로세스에 두면 OOM·크래시가 전체 API를 멈출 수 있었습니다. 주간 스크럼에서 저는 worker_threads로 같은 프로세스 안 분리를, 동료는 nginx 로드밸런서 + PM2 fork 다중 프로세스를 제안했습니다.

프로토타이핑으로 스트림 I/O·ZIP·큐 소비 비중과 장애 격리·배포 단순성을 비교한 뒤 동료안을 채택했습니다. ecosystem.config.js는 API 서버 5개(포트 5101~)와 translation-worker 10개를 fork로 띄우고, 프로세스당 --max-old-space-size=8192를 줍니다.

API는 Redis 큐에 작업을 넣고 워커가 소비해, 업로드 경로와 번역 경로의 프로세스 경계를 나눕니다. nginx는 이 레포 밖 인프라에서 API 포트로 분산하는 형태로 전제합니다.