큐를 공유하는 컨슈머

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

Open Table of contents

배경 — 한 큐를 공유한 세 작업

가을에 용도별로 media.thumb 과 media.probe 와 media.encode 로 나눴지만 새 환경에서는 워커가 둘뿐이라 셋을 다시 한 큐로 받고 있었다. 컨슈머는 큐에서 순서대로 가져갈 뿐 그것이 무거운 작업인지 아닌지를 모른다.

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

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

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

작업 종류로 나누면 종류가 늘 때마다 큐가 늘고 요청자로 나누면 같은 요청자가 긴 작업과 짧은 작업을 다 낸다. 서로를 막는 축이 소요 시간이므로 그것으로 나누는 쪽을 골랐다. 이유는 막는 축과 나누는 축이 같아야 분리가 효과를 내서다.

그래서 media.fast 와 media.slow 로 갈라 워커를 각각 하나씩 붙였다. 이렇게 하면 느린 쪽이 아무리 밀려도 빠른 쪽은 막히지 않는다.

나누면 잃는 것도 있는데 media.fast 가 비어 있는 동안 그쪽 워커가 그냥 논다. ConsumerCount 는 1인데 처리량은 0이다. 큐가 하나였으면 그것이 느린 작업을 도왔을 것이다.

격리를 얻는 대신 자원 활용률을 내주는 교환이었다. 사용자가 기다리는 작업이 섞여 있으므로 격리를 골랐고 놀고 있는 워커 하나만큼의 처리량을 감수했다. 배치만 도는 시스템이면 반대가 맞다.

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

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