Message Queue

요청이 몰릴 때 생산자와 소비자가 같은 속도로 움직여야 한다고 가정하면 시스템이 쉽게 무너집니다. 느린 하위 작업이 사용자 요청 경로를 직접 막아 버리기도 합니다. 실패한 작업을 바로 버리면 데이터 손실이 되고, 즉시 무한 재시도하면 더 큰 혼잡을 부릅니다. Message Queue는 이 속도 차이와 실패 처리를 다루기 위해 들어오는 일을 잠시 붙잡아 두는 버퍼입니다.

웹 시스템이 실시간 상호작용과 백그라운드 작업을 함께 떠안기 시작하면서, 모든 처리를 사용자 요청 경로에서 바로 끝내는 방식이 버티기 어려워졌습니다. 이메일 발송, 이미지 변환, 정산, 색인 갱신 같은 작업은 약간 늦어져도 되지만 안정적으로 처리되어야 했습니다. 그래서 생산과 소비를 느슨하게 연결하는 작업 버퍼가 중요한 기본기처럼 자리 잡았습니다.

생산자는 메시지를 큐에 넣고 빠져나오며, 소비자는 큐에서 메시지를 꺼내 처리합니다. 이 구조 덕분에 생산 속도와 소비 속도가 같을 필요가 없어지고, 소비자 수를 늘려 병렬 처리할 수도 있습니다. 실패한 메시지는 재시도하거나 별도 격리 경로로 보내며, 운영자는 작업 흐름을 더 안정적으로 통제할 수 있습니다.

Message Queue와 Publish/Subscribe는 둘 다 메시징 구조이지만 Queue는 보통 하나의 작업을 누군가가 가져가 처리하는 버퍼 모델이고, Publish/Subscribe는 하나의 사건을 여러 구독자에게 퍼뜨리는 fan-out 모델입니다. 즉 Queue는 작업 전달과 처리율 제어에 가깝고, Pub/Sub는 반응의 확장에 가깝습니다.

대기 시간이 긴 작업을 요청 경로에서 분리하거나, 순간적인 트래픽을 흡수하거나, 여러 워커가 병렬로 작업을 처리해야 할 때 Message Queue는 매우 유용합니다. 다만 큐를 넣는다고 흐름이 단순해지는 것은 아니므로, 재시도 전략과 중복 처리 안전성까지 함께 설계해야 합니다. 특히 적어도 한 번 전달되는 환경에서는 같은 메시지가 다시 올 수 있다는 전제를 놓치면 안 됩니다.

다음에 볼 개념

함께 보면 좋은 개념