브로커를 완충재로 쓸 때

처리량이 불규칙한 작업 앞에 메시지 브로커를 뒀다. 요청을 큐에 넣고 워커가 자기 속도로 처리하니 몰리는 시간에도 요청이 죽지 않고 쌓이기만 했다.

Open Table of contents

길이 절대값이 만든 오탐

처음에는 큐 길이가 일정 수를 넘으면 알리게 했다. 몰리는 시간마다 그 선을 넘으니 알림이 계속 왔다.

그런데 그렇게 쌓였다가 나중에 처리되는 것이 이 구조의 목적이다. 완충하려고 넣은 장치에 완충이 일어났다고 알리는 조건을 걸어 둔 셈이었다.

조건을 길이가 일정 시간 계속 증가하는 경우로 바꿨다. 쌓이는 것은 괜찮고 줄지 않는 것이 문제이기 때문이다.

더 정확하게는 초당 들어오는 수와 초당 나가는 수를 각각 지표로 남기고 비율을 봤다. 유입이 처리보다 큰 상태가 잠깐이면 완충이고 오래 지속되면 용량 부족이므로 절대값이 아니라 관계를 봐야 갈린다.

운영자에게 더 쓸모 있는 지표는 큐 길이를 처리 속도로 나눈 값이었다. 몇 개가 쌓였다는 말보다 몇 분을 기다린다는 말이 판단하기 쉽다.

사용자가 실제로 겪는 것도 개수가 아니라 시간이다. 그래서 화면에도 현재 처리 지연을 시간으로 보여 주게 했다.

몰릴 때 워커를 늘리면 될 것 같지만 병목이 워커가 아닐 수 있다. 워커가 데이터베이스를 쓰면 데이터베이스가 병목이고 워커를 늘리면 연결이 늘어 더 느려진다.

그래서 늘리기 전에 워커가 포화 상태인지 대기 상태인지를 봤다. 대기 중이면 뒤쪽이 병목이므로 늘리는 것이 도움이 아니라 해가 된다.

여러 워커가 나눠 처리하면 전체 순서가 지켜지지 않는데 대부분은 상관없었다. 다만 같은 대상에 대한 작업은 수정과 삭제가 뒤바뀌면 안 되므로 대상 식별자로 분배해 같은 대상이 같은 파티션으로 가게 했다.

전체 순서를 포기하고 대상별 순서만 지키면 병렬 처리가 성립한다. 처리에 실패한 메시지는 몇 번 재시도한 뒤 별도 큐로 보냈는데 이 큐는 비어 있는 것이 정상이므로 앞의 큐와 반대로 하나라도 있으면 알리게 했다.