메시지 큐

사용자를 언제까지 기다리게 할 것인가

주문 버튼을 누르면 시스템은 여러 가지 일을 합니다. 주문을 저장하고, 결제를 승인받고, 확인 메일을 보내고, 창고에 출고를 지시하고, 통계를 갱신합니다.

이 일들을 전부 끝낸 다음에 사용자에게 "완료됐습니다"를 보여준다고 해봅시다. 메일 서버가 2초 걸리면 사용자는 2초를 더 기다립니다. 메일 서버가 죽어 있으면 주문 자체가 실패합니다. 메일이 안 갔다고 주문을 취소하는 게 맞는 일일까요?

아닙니다. 사용자에게 정말 필요한 것은 "주문이 접수됐다"는 확답뿐입니다. 나머지는 뒤에서 해도 됩니다.

접수대와 심사실

민원 창구를 떠올려 보세요. 창구 직원은 서류를 받고, 확인하고, 접수증을 끊어줍니다. 여기까지가 30초입니다. 실제 심사는 뒤쪽 사무실에서 사흘에 걸쳐 진행됩니다.

민원인은 사흘을 창구에 서 있지 않습니다. 접수증을 들고 집에 갑니다.

시스템에서 이 접수대에 해당하는 것이 메시지 큐입니다. 그리고 뒤쪽 심사실에서 일하는 사람이 워커(worker) 입니다.

큐는 무엇이 다른가

앞선 강의에서 서버는 처리 능력을 넘으면 요청을 버렸습니다. 대기열이 꽉 차면 새 손님을 돌려보냈습니다. 사용자에게는 오류 화면이었습니다.

큐는 그렇게 하지 않습니다. 큐는 쌓습니다. 그게 큐의 존재 이유입니다.

일반 서버:  감당 못 하면 → 버린다  → 사용자가 오류를 본다
큐:         감당 못 하면 → 쌓는다  → 사용자는 모른다, 대신 처리가 늦어진다

이 차이가 결정적입니다. 트래픽이 몰려도 사용자 화면은 멀쩡합니다. 주문은 전부 정상 접수됩니다. 다만 확인 메일이 30분 뒤에 도착합니다.

공짜가 아니다

여기서 많은 사람이 착각합니다. 큐를 붙였으니 문제가 해결됐다고요.

아닙니다. 일의 총량은 그대로입니다. 큐는 일을 없애주지 않습니다. 단지 사용자가 기다리는 자리에서 안 보이는 자리로 옮겼을 뿐입니다.

워커가 초당 30건을 처리하는데 초당 60건이 들어오면, 매초 30건씩 쌓입니다. 한 시간이면 10만 건이 밀립니다. 사용자 화면은 여전히 멀쩡합니다. 그런데 오늘 주문한 사람의 확인 메일이 내일 도착합니다.

큐가 바꾼 것은 실패의 모양입니다. 유실(오류 화면)이 지연(늦은 처리)으로 바뀐 것입니다. 대개는 이 교환이 남는 장사지만, 공짜는 아닙니다.

그리고 큐에도 한계는 있습니다. 쌓을 자리마저 다 차면 그때는 큐도 버립니다. 그때는 이미 훨씬 큰 문제입니다.

쌓인 것을 어떻게 빼는가

적체가 쌓이는 이유는 단순합니다. 들어오는 속도 > 처리하는 속도. 그러니 해법도 단순합니다. 처리하는 쪽을 빠르게 하거나, 처리하는 사람을 늘리는 것입니다.

심사관을 한 명에서 두 명으로 늘리면 심사 속도가 두 배가 됩니다. 들어오는 속도를 넘어서는 순간부터 쌓여 있던 서류가 줄어들기 시작합니다.

이것이 큐 구조의 진짜 장점입니다. 접수대는 그대로 두고 뒤쪽 인력만 늘리면 됩니다. 사용자는 아무것도 눈치채지 못합니다. 창구는 처음부터 30초였으니까요.

직접 해보세요

아래 과제에는 워커가 한 명뿐이라 큐에 일이 계속 쌓입니다. 먼저 실행해서 사용자는 멀쩡한데(오류 0건) 큐만 부풀어 오르는 것을 확인하세요. 이 조합이 큐 구조에서 가장 위험한 신호입니다. 그다음 워커를 늘려 적체를 빼보세요.