월말에 한 고객사가 보고서 생성 작업 1만 건을 한 번에 넣었습니다. 시스템 전체 CPU는 여유가 있는데 다른 고객사의 단일 보고서도 30분을 기다립니다. 작업이 단순히 하나의 공유 큐에 먼저 들어온 순서대로 처리된다면, 큰 고객의 긴 줄 뒤에 작은 고객의 급한 작업이 묻힐 수 있습니다. 이 현상은 API 응답 속도만 보는 대시보드에서는 잘 드러나지 않습니다.
멀티테넌트 SaaS에서 백그라운드 작업은 총 처리량만큼 고객 간 대기 시간의 공정성이 중요합니다. 테넌트별 작업 유입량·작업 비용·지연 허용치를 분리해서 봐야 합니다.
‘공유 큐 하나’가 왜 위험할까
보고서 생성, 대용량 업로드 처리, 문서 OCR, 이메일 발송처럼 작업 시간이 다른 기능을 같은 큐에 넣으면 긴 작업이 짧은 작업을 막는 head-of-line blocking이 생깁니다. 여기에 한 테넌트가 대량 작업을 제출하면 이른바 noisy neighbor 문제가 됩니다. 워커를 무작정 늘리면 DB·스토리지·외부 API에 부하가 옮겨갈 수 있어 근본 해결이 아닙니다.
먼저 작업마다 테넌트 ID, 작업 종류, 예상 비용, 제출 시각, 재시도 횟수, 업무상 우선순위를 기록합니다. 내부 운영 작업과 고객 요청 작업도 구분합니다. 작업이 얼마나 오래 실행됐는지뿐 아니라 실행 전 대기한 시간도 관측해야 합니다.
공정 스케줄링의 기본은 줄을 분리하는 것
테넌트별 논리 큐를 두고 스케줄러가 번갈아 워커에 공급하면, 대량 제출한 고객이 워커를 독점하는 일을 줄일 수 있습니다. 모든 고객에게 완전히 같은 양을 배정할 필요는 없습니다. 계약 등급이나 작업 비용에 따라 가중치를 줄 수 있지만 최소 서비스 몫은 보장하는 편이 안전합니다. Amazon SQS 공정 큐 문서는 테넌트 ID를 메시지 그룹으로 제공해 noisy neighbor 영향을 줄이는 방식을 설명합니다. 여기서 공정성은 고객 간 대기 시간 문제이고, FIFO의 엄격한 순서 보장과는 다른 요구사항입니다.
서로 다른 작업 종류도 나누는 것이 좋습니다. 30초짜리 PDF 생성과 2시간짜리 데이터 재처리를 동일한 슬롯에서 경쟁시키면 테넌트 공정성만으로는 충분하지 않습니다. 긴 작업은 별도 워커 풀이나 청크 단위로 분해하고, 짧고 대화형인 작업은 독립된 지연 목표를 갖게 합니다.
유입 제한과 실행 제한은 별개다
고객이 동시에 1만 건을 요청할 수 있게 하더라도 실제 실행은 테넌트당 제한된 개수로 묶을 수 있습니다. 신규 유입 제한은 큐 팽창을 막고, 실행 중 동시성 제한은 DB 연결·메모리·외부 서비스 사용량을 보호합니다. 둘의 숫자는 같은 값일 필요가 없습니다. 비싼 작업에는 비용 가중치를 적용하고, 재시도 작업이 신규 작업을 밀어내지 않도록 재시도 예산도 둡니다.
한도를 넘긴 작업을 무조건 버릴지, 대기시킬지, 예약 시간으로 이동시킬지는 업무 계약에 따라 다릅니다. 사용자 화면에는 현재 대기, 처리 중, 완료, 실패 상태를 보여주고 예상 완료 시각은 근거가 있을 때만 제시합니다. 무제한으로 ‘접수 완료’만 표시하면 신뢰를 잃기 쉽습니다.
성공 지표는 전체 평균이 아니다
평균 대기 시간이 1분이어도 일부 고객은 20분을 기다릴 수 있습니다. 테넌트별 대기 시간 p95, 최장 대기 작업의 나이, 처리량, 실패·재시도율, 워커 점유율을 함께 봅니다. 특정 고객의 폭주 시 다른 고객의 p95가 얼마나 변하는지 부하 테스트로 확인합니다. 작업 수가 적은 고객도 관측에서 빠지지 않게 해야 합니다.
도입 체크리스트
- 모든 작업 메시지에 테넌트·작업 유형·비용 등급을 붙인다.
- 작업별 대기 시간과 실행 시간을 별도 계측한다.
- 테넌트별 유입·동시 실행·재시도 예산을 정한다.
- 긴 작업과 짧은 작업의 워커 자원을 분리한다.
- 한 고객이 폭주하는 부하 테스트에서 다른 고객의 지연을 검증한다.
공정한 큐는 모든 작업을 똑같이 느리게 만드는 장치가 아닙니다. 큰 고객의 작업량은 받아들이면서도 다른 고객의 작은 업무가 끝날 기회를 보장하는 구조입니다.
#멀티테넌트 #작업큐 #백그라운드작업 #공정스케줄링 #NoisyNeighbor #SaaS아키텍처 #큐운영 #비용최적화 #관측성 #시스템설계
