결론부터 말씀드리면: 압축 작업 비동기화의 표준방안은 Celery + Redis 작업 큐이며, 핵심 아키텍처는 Producer(FastAPI 작업등록) → Broker(Redis 임시 저장) → Worker(Celery 소비 및 Rust 압축 엔진 호출) → Backend(Redis 결과 저장)입니다. 10000개 파일 대량 압축에 대응하여, 100개 파일 단위로 분할하고 12개의 Worker가 동시 처리하면 약 40분 만에 전체를 완료할 수 있습니다. 핵심 설계 포인트는 작업 분할, 우선순위 큐, 지수 백오프 재시도, 데드 레터 큐 안전망입니다. 아래에서는 큐 아키텍처부터 시작하여 Celery 구성 파라미터 표와 완전한 실전 방안 제시합니다.
압축 서비스의 전체 배포에 익숙하지 않으시다면, 먼저 Docker로 압축 서비스 배포하는 완전한 가이드를 읽어보시기를 권장합니다.
1. 압축 작업이 비동기 큐를 필요로 하는 이유
파일 압축은 전형적인 CPU 집약적 + IO 집약적 작업입니다. 100MB PDF 압축은 5–15초가 소요될 수 있으며, 동기 인터페이스로 처리하면 HTTP 연결이장시간 대기 상태로 묶여 단일 머신의 동시 처리 능력이 매우 떨어집니다. 비동기 큐는 "제출"과 "실행"을 분리합니다. 클라이언트가 작업을 제출한 후 즉시 task_id를 받고, Worker가 백그라운드에서 천천히 압축하며, 완료 후 콜백 또는 폴링으로 결과를 반환합니다.
| 처리 방식 | 동시 처리 능력 | 응답 지연 | 실패 처리 | 적용 규모 |
|---|---|---|---|---|
| 동기 처리 | 낮음(HTTP 연결 차단) | 5–60초 | 재시도 없음, 직접 오류 보고 | 10개 미만 파일 |
| 스레드 풀 | 중간(스레드 수 제한) | 1–5초 | 수동 구현 필요 | 10–100개 파일 |
| Celery 비동기 큐 | 높음(Worker 수평 확장) | 200ms 미만 | 자동 재시도 + 데드 레터 큐 | 100–100000개 파일 |
| Kubernetes + 큐 | 매우 높음(HPA 탄력 확장) | 100ms 미만 | 완전한 내결함성 체계 | 100000개 초과 파일 |
SmartSlim 네트워크 버전은 FastAPI + Celery + Redis + MinIO 아키텍처를 채택하여, 단일 머신에서 12개의 동시 작업을 안정적으로 실행하며, Kubernetes 배포 시 HPA가 3–10 복제본 사이에서 자동 확장/축소됩니다. 이 아키텍처는 이미 여러 기업 고객의 일 평균 만 단위 파일 압축 요구를 지원하고 있습니다.
2. Celery 작업 큐 아키텍처 상세
Celery 작업 큐는 네 가지 핵심 역할로 구성됩니다: Producer(생산자), Broker(메시지 브로커), Worker(작업 프로세스), Backend(결과 저장소). 이 네 계층의 책임을 이해해야만 압축 작업 큐를 올바르게 구성할 수 있습니다.
| 구성 요소 | 기술 선택 | 책임 | 핵심 구성 |
|---|---|---|---|
| Producer | FastAPI | HTTP 요청 수신, 작업 구성, Broker에등록 | task.apply_async(queue=...) |
| Broker | Redis 7.x | 처리 대기 작업 메시지 임시 저장, 우선순위 큐 지원 | broker_url, visibility_timeout |
| Worker | Celery 5.x | 작업 소비, Rust 압축 엔진 호출하여 압축 실행 | concurrency, prefork pool |
| Backend | Redis | 작업 상태 및 반환 결과 저장 | result_backend, result_expires |
| 저장 계층 | MinIO | 원본 파일 및 압축 후 파일 저장 | S3 호환 프로토콜, 분할 업로드 |
2.1 Celery 핵심 구성 파라미터 표
Celery 구성은 큐의 처리량과 안정성을 직접 결정합니다. 아래 표는 압축 시나리오의 권장 구성으로, SmartSlim 운영 환경에서 이미 검증되었습니다.
| 파라미터 | 권장값 | 설명 |
|---|---|---|
| broker_url | redis://:password@redis:6379/0 | 메시지 브로커로 Redis 사용, 충돌 방지를 위해 독립 DB |
| result_backend | redis://:password@redis:6379/1 | 결과 저장용 독립 DB, Broker와 격리 |
| task_serializer | json | JSON 직렬화, 다국어 호환 |
| result_serializer | json | 결과도 JSON 사용 |
| accept_content | ['json'] | JSON만 수락, 보안 강화 |
| timezone | Asia/Shanghai | 시간대 통일 |
| task_acks_late | True | 작업 완료 후에만 ACK, 크래시 시 작업 손실 방지 |
| worker_prefetch_multiplier | 1 | 각 Worker가 1개 작업만 사전 페치, 장시간 작업 기아 방지 |
| task_time_limit | 600 | 단일 작업 하드 타임아웃 600초 |
| task_soft_time_limit | 540 | 소프트 타임아웃 540초, SoftTimeLimitExceeded 트리거 |
| task_reject_on_worker_lost | True | Worker 비정상 종료 시 작업 거부, 재재입력 |
| result_expires | 86400 | 결과 24시간 보존 후 자동 정리 |
2.2 우선순위 큐 설계
압축 작업에는 우선순위의 구분이 있습니다. 사용자가 실시간으로 제출한 압축 요청은 빠른 응답이 필요하며, 정기 아카이빙 작업은 천천히 실행해도 됩니다. Redis 우선순위 큐로 차별화된 스케줄링을 구현하며, 높은 우선순위 작업이 Worker에 의해 먼저 소비됩니다.
| 큐 이름 | 우선순위 | 라우팅 규칙 | 대표 작업 |
|---|---|---|---|
| compression_high | 9(최고) | 사용자 실시간 요청 | 단일 파일 즉시 압축 |
| compression_normal | 5(기본) | 대량 작업 | 대량 압축 100–500 파일 |
| compression_low | 1(최저) | 정기 아카이빙 | 야간 전체 아카이빙 압축 |
| dlq_queue | —(데드 레터) | 재시도 실패 작업 | 수동 조사 또는 보상 처리 |
3. 실전 사례: 10000개 파일 비동기 압축
다음은한 기업의 데이터 아카이빙 시나리오입니다. 10000개의 과거 문서(PDF/Word/이미지 혼합, 평균 단일 파일 8MB, 총합 약 80GB)를 통합 압축 아카이빙해야 합니다. 1시간 내 완료, 압축률 60% 이상 요구.
방안 설계: 100개 파일 단위로 분할하여 100개의 하위 작업으로 나누고, Celery group으로일괄 등록, 12개의 Worker가 동시 소비. 각 하위 작업 내에서 Rust 압축 엔진을 호출하여 100개 파일을 순차적으로 압축합니다.
실행 파라미터 및 처리량 성능:
| 지표 | 파라미터 | 실측값 | 설명 |
|---|---|---|---|
| 총 파일 수 | 10000개 | — | 혼합 포맷, 평균 8MB/개 |
| 분할 입도 | 100 파일/조각 | 100개 하위 작업 | 스케줄링 오버헤드와 재시도 비용의 균형 |
| Worker 동시성 | 12개 | prefork 모드 | 단일 머신 12 코어 CPU |
| 단일 파일 압축 소요 | — | 평균 3.2초 | Rust 엔진 medium 등급 |
| 단일 조각 소요 | — | 약 5.3분 | 100 파일 순차 |
| 전체 소요 | — | 약 44분 | 100 조각/12 동시 |
| 압축률 | — | 67.3% | 80GB → 26.2GB |
| 실패 수 | — | 17개 | 파일 손상, 재시도 후 데드 레터로 |
결과: 44분 만에 10000개 파일 압축 완료, 압축률 67.3%, 17개의 손상된 파일이 자동으로 데드 레터 큐로 이동하여 수동 처리. 전체 아키텍처는 안정적이었으며, CPU 사용률 피크 89%, 메모리 사용량 피크 4.2GB, OOM 또는 작업 손실 없음.
3.3 재시도 및 데드 레터 큐 전략
압축 작업 실패의 원인은 두 가지로 나뉩니다. 일시적 오류(IO 타임아웃, 메모리 부족, 동시성 과다)와 확정적 오류(파일 손상, 포맷 미지원). 일시적 오류는 재시도 시 높은 확률로 성공하며, 확정적 오류는 재시도가 무의미합니다. 아래 표는 재시도와 데드 레터의 의사 결정 전략을 제시합니다.
| 오류 유형 | 대표 예외 | 처리 전략 | 재시도 횟수 | 최종 귀결 |
|---|---|---|---|---|
| 일시적 - IO | ConnectionError, TimeoutError | 지수 백오프 재시도 | 3회 | 성공 또는 데드 레터로 |
| 일시적 - 리소스 | MemoryError, OOMKilled | 백오프 연장 + 성능 저하 | 2회 | 성공 또는 데드 레터로 |
| 확정적 - 파일 | FileCorrupted, ParseError | 재시도 안 함, 즉시 데드 레터 | 0회 | dlq_queue |
| 확정적 - 포맷 | UnsupportedFormat | 재시도 안 함, 즉시 데드 레터 | 0회 | dlq_queue |
| 확정적 - 권한 | PermissionDenied | 재시도 안 함, 알림 | 0회 | dlq_queue + 알림 |
재시도 구성은 Celery의 autoretry_for 및 retry_backoff를 사용하며, 초기 백오프 60초, 최대 600초, 랜덤 지터를 추가하여 눈사태 효과를 방지합니다. 데드 레터 큐의 작업은 독립적인 모니터링 작업이 정기적으로 스캔하여, Enterprise WeChat/DingTalk 알림을 트리거하여 운영팀에 통지합니다.
| 모니터링 지표 | 수집 방식 | 알림 임계값 | 처리 동작 |
|---|---|---|---|
| 큐 적체량 | Redis LLEN | 500 초과 | Worker 확장 트리거 |
| 작업 실패율 | Celery events | 5% 초과 | 로그 조사 +등록 일시 중지 |
| 데드 레터 큐 길이 | Redis LLEN dlq | 10 초과 | Enterprise WeChat 알림 |
| Worker 생존 수 | Celery inspect | 10 미만 | Worker 자동 재시작 |
| 평균 작업 소요 | Flower 모니터링 | 30초 초과 | 대용량 파일 확인 + 저하 |
| CPU 사용률 | node_exporter | 95% 초과 | 요청 제한 + 확장 |
압축 API의 완전한 호출 방식은 압축 API 호출 가이드: REST 인터페이스 설계를 참조하시기 바랍니다.
4. 시나리오별 큐 구성 권장
다양한 업무 시나리오의 처리량, 지연, 안정성 요구가 다르므로, 큐 구성은 차별화되어야 합니다. 아래 표는 흔한 시나리오의 권장 구성을 제시합니다.
| 시나리오 | Worker 수 | 분할 입도 | 우선순위 큐 | 재시도 전략 |
|---|---|---|---|---|
| 개인 즉시 압축 | 2 | 분할 없음 | high | 빠른 재시도 3회 |
| 기업 대량 아카이빙 | 12 | 100 파일/조각 | normal/low | 지수 백오프 3회 |
| 정부 기밀 처리 | 4 | 50 파일/조각 | high | 엄격한 재시도 + 감사 |
| 이커머스 플랫폼 이미지 | 16 | 200 파일/조각 | normal | 빠른 재시도 2회 |
| 야간 정기 아카이빙 | 8 | 500 파일/조각 | low | 느린 백오프 5회 |
| 실시간 비디오 트랜스코딩 | 24 | 단일 파일 | high | 재시도 안 함, 실패 시 알림 |
일반적인 원칙: 실시간 시나리오는 높은 우선순위 큐 + 소분할 + 빠른 재시도, 대량 시나리오는 보통 큐 + 대분할 + 지수 백오프, 기밀 시나리오는 엄격한 감사 + 소분할 + 다단계 재시도. 엔터프라이즈급 대량 압축의 완전한 방안은 엔터프라이즈 대량 압축방안: 만 단위 파일 처리 실전을 참조하시기 바랍니다.
5. 자주 묻는 질문(FAQ)
Q1: Celery 압축 작업은 어떻게 비동기 처리를 구현하나요?
Celery + Redis로 비동기 작업 큐를 구성합니다. FastAPI가 요청을 받은 후 작업을 Redis Broker에등록하고, Celery Worker가 Broker에서 작업을 소비하여 Rust 압축 엔진을 호출하여 압축을 실행하며, 결과를 Backend와 MinIO 저장소에 기록합니다. 하나의 task.apply_async로 비동기 실행이 가능하며, task.id로 상태를 폴링합니다. 단일 머신 12개의 Worker 동시성으로, 10000개 파일을 100개 배치로 분할하여 40분 내에 완료할 수 있습니다.
Q2: 압축 작업 실패 시 어떻게 자동 재시도하나요?
Celery의 autoretry_for 파라미터로 자동 재시도를 구성하며, max_retries=3, retry_backoff=True(지수 백오프, 초기 60초), retry_backoff_max=600초, retry_jitter=True(눈사태 효과 방지를 위한 랜덤 지터)를 설정합니다. 3회 재시도 후에도 실패한 작업은 자동으로 데드 레터 큐 dlq_queue로 라우팅되어 수동 또는 보상 작업으로 처리됩니다. 일시적 오류(IO 타임아웃/메모리 부족)에는 재시도를, 확정적 오류(파일 손상/포맷 미지원)에는 즉시 데드 레터로 보내는 것을 권장합니다.
Q3: 10000개 파일의 대량 압축은 어떻게 분할하나요?
100개 파일 단위로 분할하여 총 100개의 하위 작업으로 나눕니다. Celery group 또는 chord로일괄 등록, 12개의 Worker가 병렬 소비하며, 각 하위 작업 내에서 100개 파일을 순차적으로 압축합니다. 단일 파일 평균 압축 소요 3초, 단일 조각 약 5분, 100개 조각이 병렬 처리되어 전체 약 40분 만에 완료. 분할 입도가 너무 작으면(예: 조각당 1개) 스케줄링 오버헤드가 크고, 너무 크면(예: 조각당 1000개) 실패 시 재시도 비용이 높아지며, 100이 경험적으로 최적인 값입니다.
Q4: Celery와 RQ 중 어느 것이 압축 작업 큐에 더 적합한가요?
압축 작업에는 Celery를 권장합니다. Celery는 작업 분할(group/chord), 우선순위 큐, 정기 작업, 작업 체인, 데드 레터 큐를 지원하여 기능이 완비되어 있습니다. RQ는 더 가볍지만 분할과 우선순위가 부족합니다. 압축 시나리오의 흔한 요구인 대량 분할, 우선순위 스케줄링, 실패 재시도 등을 Celery가 네이티브로 지원합니다. 성능면에서는 둘 다 Redis 기반이며 처리량이 비슷합니다. SmartSlim 네트워크 버전은 FastAPI + Celery + Redis + MinIO 아키텍처를 채택하여, 단일 머신 12 동시성으로 안정적으로 운영됩니다.
결론
압축 작업 비동기화의 표준방안은 Celery + Redis 작업 큐이며, 핵심은 Producer/Broker/Worker/Backend 네 계층의 분리입니다. 만 단위 파일 대량 압축에 대응하여, 100 파일 단위 분할, 12 Worker 동시성, 약 40분 내 완료, 압축률 60%–70%. 재시도 전략은 일시적 오류(지수 백오프 재시도)와 확정적 오류(즉시 데드 레터로)를 구분해야 하며, 6가지 모니터링 지표로 큐 안정성을 확보합니다.
세 가지를 기억하시기 바랍니다. 첫째, task_acks_late=True로 크래시 시 작업 손실 방지. 둘째, worker_prefetch_multiplier=1로 장시간 작업 기아 방지. 셋째, 데드 레터 큐는 반드시 모니터링 알림과 함께 구성. 적합한 큐 아키텍처와 분할 전략을 선택하면, 압축 서비스의 처리량과 안정성이 한 단계 올라갈 수 있습니다.