웹 서버의 장시간 요청 처리 한계
대부분의 웹 서버는 요청당 프로세스나 스레드를 할당하여 처리합니다. 동시 처리 가능한 프레임워크 수를 초과하는 요청이 발생하면 대기열에 쌓이게 됩니다. 이때 하나의 요청이 장시간 리소스를 점유하면 전체 서버의 처리 능력이 저하되어 응답 시간이 길어지고, 결국 사용자에게 타임아웃 오류를 발생시키거나 서비스 전체의 장애로 이어질 수 있습니다. 또한, 장시간 요청은 CPU 및 메모리 같은 서버 리소스를 과도하게 사용하거나, 데이터베이스와 같은 미들웨어에 부하를 주어 다른 처리에도 악영향을 미칩니다. HTTP 타임아웃, 처리 중단으로 인한 데이터 불일치, 문제 발생 시 원인 파악의 어려움 등 다양한 운영상의 문제를 야기합니다.
비동기 작업의 필요성 및 도입 고려사항
이러한 장시간 요청 문제를 해결하기 위해 비동기 작업이 도입됩니다. 웹 서버는 처리 시간이 긴 작업을 비동기 시스템에 위임하고 즉시 응답함으로써, 제한된 리소스로 더 많은 요청을 효율적으로 처리할 수 있게 됩니다. 그러나 비동기 작업은 동기 처리보다 시스템을 복잡하게 만들고, 기능 추가, 모니터링, 장애 대응 난이도를 높입니다. 따라서 비동기 작업 도입 전, 해당 기능이 정말 비동기 처리가 필요한지, 혹은 배치(Batch) 처리로 대체할 수 없는지 신중하게 검토해야 합니다. 예를 들어, 실시간성이 중요하지 않은 대량 데이터 분석 기능은 비동기 작업보다 배치 처리로 설계하는 것이 더 단순하고 효율적일 수 있습니다.
비동기 작업 설계 원칙: 짧고 단순하게
Sidekiq의 베스트 프랙티스에서도 강조하듯이, 비동기 작업은 짧고 단순하며 멱등성(Idempotent)과 트랜잭션(Transactional)을 갖추도록 설계해야 합니다. 여기서 ‘짧다’는 수 초 이내에 완료되는 것을 의미합니다. 이 원칙을 따르는 것이 중요한 이유는 다음과 같습니다:
-
성능 향상: 짧은 작업은 리소스를 빠르게 해제하여 전체 처리량을 높입니다.
-
재시도 용이성: 단순하고 멱등적인 작업은 실패 시 재시도를 통해 쉽게 복구할 수 있습니다.
-
모니터링 단순화: 시작 및 종료 이벤트만으로도 처리 시간, 실패율 등을 쉽게 측정할 수 있어 모니터링 시스템을 간소화할 수 있습니다.
-
배포 및 유지보수 용이성: 짧은 작업은 배포 시 강제 종료될 위험이 적어 안정적인 시스템 운영을 가능하게 합니다.
장시간 비동기 작업 처리 전략
그럼에도 불구하고, 대량 데이터 일괄 처리나 외부 서비스 연동 등 장시간 작업이 불가피한 경우가 있습니다. 이러한 경우, 다음과 같은 전략을 고려할 수 있습니다:
-
작업 분할 및 재개: Shopify의 Job Iteration, Sidekiq Iteration, Rails 8.1에 도입될 Active Job Continuations과 같은 라이브러리를 활용하여 작업을 작은 단위로 분할하고, 중단 시 이전 상태에서 재개할 수 있도록 합니다.
-
배치 처리: Sidekiq Pro의 Batches와 같이 여러 작업을 하나의 그룹으로 묶어 관리하며, 각 작업은 짧게 유지하되 전체 진행 상황을 모니터링하고 완료 시 후속 처리를 수행합니다.
-
외부 서비스 활용: AWS Step Functions와 같은 외부 서비스를 통해 복잡하고 장시간이 소요되는 작업을 비동기 시스템과 분리하여 처리하고, 워크플로우를 관리합니다. 이는 메인 비동기 시스템의 부하를 줄이고 배포 시 안정성을 확보하는 데 도움이 됩니다.