큐 구성이 바뀌자 소비가 멈췄다

미디어 처리 시스템을 인수받았다. ActiveMQ 큐 하나에 ffmpeg 워커 넷이 전부 붙어 있었다.

Open Table of contents

목표와 범위

Queue를 넷이 나눠 가져가니 같은 사용자의 파일 순서가 섞였다. 같은 사용자의 작업은 순서대로 처리돼야 했다.

큐를 용도별로 나누면서도 같은 사용자의 순서 보장은 유지하는 것이 이 작업의 목표였다. 처리량을 늘리는 것은 이번 범위가 아니었다.

media.encode·media.thumb·media.probe 셋으로 나누고 워커를 각각 붙였다. 그중 media.thumb만 처리가 안 됐다.

새로 붙인 전용 워커에는 메시지가 한 건도 안 왔는데, 관리 콘솔에서 보면 그 큐의 Consumers는 1이 아니라 4였다.

ActiveMQ를 다뤄 본 적이 없어서 Queue와 Topic의 차이부터 문서로 확인해야 했다. 큐 이름을 바꾼 것 말고는 달라진 게 없어 보였다.

ActiveMQ 문서의 Wildcards 항목을 보니 >는 그 아래 계층 전체를, *는 한 단계를 받는다고 돼 있었다.

기존 워커 설정을 열어 보니 구독 대상이 media.>로 잡혀 있었고, 새로 만든 큐 이름이 media.thumb이었다.

기존 워커 셋이 새 큐까지 함께 받고 있었다. Queue는 컨슈머끼리 나눠 가지므로 전용 워커에게는 4분의 1만 갔다. 가로채는 것이 아니라 경쟁이었다 — 큐에서는 컨슈머가 여럿이면 라운드로빈으로 갈린다.

기존 워커의 구독을 media.>에서 media.encode로 좁혀 새 큐 셋을 그 범위 밖으로 뺐다.

설정을 반영하자 전용 워커로 메시지가 오기 시작했고 큐별 Consumers도 1로 잡혔다.

ActiveMQ 문서에는 policyEntry로 큐별 정책을 나누는 방법도 있는데 그쪽은 아직 안 써 봤다.

순서가 어긋나는 사례가 한 건이라도 나오면 되돌리기로 했다. 순서 보장이 처리량보다 앞이었다.

한 주 동안 순서 오류 건수를 세게 했다. 0이면 유지하고 나오면 원래 구성으로 돌린다.

ActiveMQ.Advisory.Consumer.>를 구독하는 모니터링 쪽은 그대로 두었는데, 그건 컨슈머 접속을 감시하는 용도라 범위가 넓어야 한다.