큐를 공유하는 컨슈머

미디어 처리 시스템을 자원이 더 적은 다른 환경으로 옮기고 있었다. 큐 하나에 컨슈머 여럿이 붙어 작업을 나눠 가는 구조였다.

Open Table of contents

한 큐를 공유한 세 작업

짧은 미리보기 생성과 메타데이터 추출과 긴 인코딩이 같은 큐에 들어가고 있었다. 컨슈머는 큐에서 순서대로 가져갈 뿐 그것이 무거운 작업인지 아닌지를 모른다.

옮긴 뒤에 긴 작업 몇 개가 들어오면 다른 작업이 전부 멈추는 일이 반복됐다. 원래 환경에서는 컨슈머 수가 넉넉해서 겉으로 티가 안 났던 문제였다.

동시에 도는 것은 컨슈머 수만큼인데 긴 작업이 그것을 다 잡으면 뒤의 짧은 작업은 그냥 기다린다. 초 단위로 끝나는 작업이 실제로는 몇 분씩 대기하고 있었다.

같은 지연이라도 사용자 쪽 체감은 다르다. 긴 인코딩이 오래 걸리는 것은 예상된 일이지만 미리보기가 안 나오는 것은 고장으로 읽힌다.

작업 종류로 나누면 종류가 늘 때마다 큐가 늘고 요청자로 나누면 같은 요청자가 긴 작업과 짧은 작업을 다 낸다. 서로를 막는 축이 소요 시간이므로 그것으로 나눴다.

그래서 빠른 작업 큐와 느린 작업 큐로 갈라 컨슈머를 각각 나눠 붙였다. 이렇게 하면 느린 쪽이 아무리 밀려도 빠른 쪽은 막히지 않는다.

나누면 잃는 것도 있는데 빠른 큐가 비어 있는 동안 그쪽 컨슈머가 그냥 논다. 큐가 하나였으면 그것들이 느린 작업을 도왔을 것이다.

격리를 얻는 대신 자원 활용률을 내주는 교환이었다. 사용자가 기다리는 작업이 섞여 있으므로 격리를 골랐고 배치만 도는 시스템이면 반대가 맞다.

실패한 작업이 같은 큐로 재투입되고 있어서 계속 실패하는 것이 큐를 도는 동안 다른 작업이 밀렸다. 재시도 전용 큐를 따로 두어서 실패가 정상 흐름을 막지 않게 했다.

컨슈머 수는 도착률 대비 처리량으로 잡되 정확한 값보다 부족하지 않은지를 먼저 확인했다. 이 문제들이 옮기는 과정에서 드러난 것은 자원이 줄어 여유가 없어졌기 때문이고 이식은 원래 있던 구조 문제를 보이게 만든다.