문서 처리가 밀리면 Worker를 늘리고 싶어진다. 하지만 프로세스 수를 두 배로 만든다고 처리 시간이 절반이 된다는 보장은 없다. 가상 변환이 CPU를 쓰는지, 외부 저장 응답을 기다리는지, 허용량 API가 처리량을 제한하는지에 따라 결과가 달라진다. 이번 초안은 숫자 추천 대신 같은 부하에서 Worker 확장의 효과를 읽는 실험을 설계한다.
예제는 허용량 예약, 가상 문서 변환, 결과 저장, 예약 확정이다. 실제 파일이나 외부 유료 API 대신 생성한 입력과 지연을 조절할 수 있는 시험 구현을 사용한다. 아래 내용은 수행 전 예상과 판정 기준이며 벤치마크 결과가 아니다.
replica, slot, poller를 구분한다
replica는 실행 중인 Worker 프로세스 또는 컨테이너의 수다. slot은 Worker가 동시에 처리할 수 있는 Task의 자리다. poller는 Service에서 작업을 받아오는 요청을 수행한다. 이 세 수를 모두 올리면 어느 변화가 결과에 영향을 줬는지 구분하기 어렵다.
작업을 충분히 받아도 실행 slot이 다 차 있다면 poller만 늘려도 처리량은 개선되지 않을 수 있다. 반대로 실행 여유는 있는데 작업을 충분히 받아오지 못한다면 다른 조건을 확인해야 한다. Workflow Task와 Activity Task도 역할과 자원 특성이 다르므로 같은 한도로 생각하지 않는다.
SDK의 Worker tuner는 slot 공급 방식을 정하는 기능이다. 고정 개수로 둘 수도 있고 자원 사용을 참고하는 공급 방식을 사용할 수도 있다. resource-based 방식이라고 메모리 초과를 절대로 막아 주는 것은 아니다. 시작한 작업이 이후 얼마나 큰 메모리를 쓸지 완벽히 알 수 없기 때문이다. 지원되는 API와 기존 동시성 옵션의 혼용 제한은 선택한 SDK 문서를 확인한다.
먼저 무엇이 느린지 정한다
“문서 하나가 끝나는 시간”은 여러 시간을 포함한다. 시작 요청이 기록되는 시간, Task가 Worker를 기다리는 시간, 예약 API 응답, 가상 변환 실행, 결과 저장, 재시도 대기가 모두 섞일 수 있다. 전체 시간 하나만 보면 Worker를 늘려야 할 이유가 불분명하다.
이번 실험에서는 대기 시간과 실행 시간을 나눈다. Worker가 작업을 받기 전 기다림이 늘어났다면 처리 용량이 부족할 가능성이 있다. 하지만 외부 저장소가 느려져 slot을 오래 점유한 결과일 수도 있다. Worker CPU와 메모리, 외부 API 지연, 오류율을 함께 봐야 한다.
입력 크기도 고정한다. 작은 문서와 큰 문서를 섞어 놓고 두 실험의 평균을 비교하면 구성 차이를 Worker 효과로 오해할 수 있다. 생성 규칙과 문서 수, 제출 간격, 가상 변환의 CPU 작업 또는 대기 시간을 기록한다. 실험용 지연은 실제 문서 변환 성능을 대표하지 않는다는 한계도 적는다.
하나만 바꾸는 비교
처음에는 Worker 프로세스 수만 바꾸는 실험이 이해하기 쉽다. 각 Worker의 자원과 slot 설정, 입력 묶음은 고정한다. 정상 부하가 안정된 구간과 밀린 작업을 처리하는 구간을 구분하고, 동일 조건을 여러 번 반복해 흔들림을 확인한다.
| 비교 항목 | 그대로 둘 것 | 바꿀 것 |
|---|---|---|
| replica 실험 | 입력, slot, 외부 지연, 컨테이너 자원 | Worker 수 |
| slot 실험 | 입력, Worker 수, 외부 지연, 자원 | slot 공급 설정 |
| 외부 지연 실험 | Worker 수와 설정, 입력 | 저장 API 지연 |
예상 결과는 병목이 Worker의 가상 변환 실행에 있을 때 Worker 증가가 대기 시간을 줄일 수 있다는 것이다. 실제 개선 폭은 측정해야 한다. CPU가 이미 호스트 전체를 채웠다면 같은 머신에 Worker를 추가해도 자원 경쟁이 늘 수 있다.
완료 건수만 보지 말고 실패한 시도와 재시도 수도 본다. 더 많은 작업을 시작했지만 외부 API 제한에 걸려 재시도가 늘었다면 유효한 처리량은 기대만큼 늘지 않을 수 있다. 평균과 함께 느린 실행 구간을 나타내는 분위수도 기록하되 표본 수와 측정 구간을 함께 적는다.
확장이 오히려 저장 실패를 늘리는 경우
대표 실패는 결과 저장소의 수용량을 넘기는 것이다. Worker를 늘리면 동시에 저장하려는 요청도 늘 수 있다. 저장소가 제한 응답을 보내거나 연결 대기가 길어지면 Activity가 더 오래 slot을 사용하고, 재시도까지 겹쳐 대기가 악화될 수 있다.
이때 “Worker가 부족하다”는 진단을 반복하면 문제를 키울 수 있다. 저장 API 지연과 제한 응답, Activity 실행 시간, Task 대기량을 시간순으로 대조한다. 가상 저장소의 허용 동시성을 의도적으로 낮춘 시험을 별도로 수행하면 이런 관계를 이해하기 쉽다. 단 정상 부하 실험과 같은 표에 섞지 않고 조건을 구분한다.
해결 후보는 Worker를 무작정 줄이거나 늘리는 한 가지가 아니다. Activity 동시성 조절, Queue 분리, 외부 API 제한을 고려한 요청 제어가 후보가 된다. 어떤 제어가 실제 지원되고 어느 범위에 적용되는지 SDK와 Service 설정에서 확인해야 한다. 글로벌 제한을 각 Worker의 로컬 제한으로 착각하지 않는 것도 중요하다.
종료와 확장 축소도 실험의 일부다
Worker를 늘리는 실험만 하고 줄이는 과정은 생략하기 쉽다. 하지만 운영에서는 배포나 비용 조절 때문에 실행 중 Worker가 줄어든다. 처리 중인 Activity가 있는 상태에서 정상 종료와 강제 종료를 구분하고, 남은 작업이 어떻게 재시도되는지 확인해야 한다.
같은 업무 키를 사용한 예약과 저장이 중복 반영되지 않는지 다시 대조한다. 처리량 시험이 멱등성 검증을 대신하지는 않지만, 확장 과정에서 중복 시도가 생겨도 업무 상태를 유지하는지 확인할 기회를 준다. 성공 건수는 최종 결과 기준으로 세고 시도 횟수와 구분한다.
이 글의 산출물은 추천 replica 숫자가 아니라 실험 조건과 결과를 연결한 표다. “이 입력과 이 자원에서 Worker 증가가 대기를 줄였지만 저장소 제한 이후에는 실패가 늘었다”처럼 적용 범위가 드러나는 결론이어야 한다.
검증 질문은 “slot을 늘린 뒤 CPU는 그대로인데 저장 지연만 늘었다면 무엇이 제한일까?”다. 또 “처리 시도 수가 증가했다는 사실을 성공 처리량 증가로 볼 수 있을까?”를 생각해 보자. 확장 효과를 평가하려면 시작한 양보다 올바르게 끝낸 양을 봐야 한다.