메시지 큐 & 발행–구독

보내는 쪽과 받는 쪽 사이에 "우체통"을 하나 두면, 두 서비스는 서로가 켜져 있는지 몰라도 되고 속도가 달라도 터지지 않는다

왜 중간에 큐를 둘까?

쇼핑몰에서 "주문하기"를 누르면 결제, 재고 차감, 영수증 메일, 배송사 연동, 추천 학습용 로그 적재까지 여러 일이 벌어진다. 이걸 전부 한 요청 안에서 순서대로 호출하면 — 메일 서버가 느리면 주문 버튼이 5초간 멈추고, 배송사 API가 죽으면 주문 자체가 실패한다. 대신 주문 서비스는 OrderPlaced 메시지 하나만 브로커에 던지고 즉시 응답한다. 나머지 서비스들은 그 메시지를 각자 속도로 처리한다.

• 결합도 감소(decoupling) — 생산자는 누가 소비하는지 모른다. 소비자를 나중에 추가해도 생산자 코드는 그대로.
• 버퍼링 / 부하 평탄화 — 순간 트래픽이 10배로 튀어도 큐에 쌓였다가 소비자가 꾸준한 속도로 빼 간다.
• 내결함성 — 소비자가 잠시 죽어도 메시지는 큐에 남는다. 다시 켜지면 밀린 것부터 처리.
• 재시도 / 순서 보장 — 처리 실패 시 되돌려 넣거나(ack 안 함) 데드레터 큐로 보낸다.

두 가지 전달 방식

직접 만져 보기 — 생산자·브로커·소비자 시뮬레이터

아주 작은 브로커 구현

핵심만 남기면 브로커는 "토픽별 리스트 + 구독자 목록"이다. 실무 브로커는 여기에 영속화, ack/재시도, 오프셋, 파티션이 붙는다.

class Broker:
    def __init__(self):
        self.topics = {}          # topic -> [메시지 대기열]
        self.subscribers = {}     # topic -> [소비자 큐]

    def subscribe(self, topic):
        q = Queue()
        self.subscribers.setdefault(topic, []).append(q)
        return q                 # 구독자는 자기 큐를 받는다

    def publish(self, topic, msg):
        for q in self.subscribers.get(topic, []):
            q.put(msg)          # fan-out: 모든 구독자에게 복사

# 생산자 — B가 켜져 있든 말든 신경 안 씀
broker.publish("order.placed", {"id": 42, "total": 19900})

# 소비자 — 자기 속도로 하나씩 꺼내 처리하고 ack
while True:
    msg = mailbox.get()          # 없으면 블로킹(대기)
    send_receipt_email(msg)
    mailbox.task_done()          # 처리 완료 통지(ack)

전달 보장 (delivery guarantee)

네트워크는 언제든 끊길 수 있으므로 "정확히 한 번"은 공짜가 아니다. 보통 이 셋 중 하나를 고른다.

어떤 브로커가 있나

정리

• 메시지 큐 = 생산자와 소비자 사이의 비동기 우체통. 서로의 존재·속도·가동 여부를 몰라도 된다.
• 작업 큐는 메시지를 소비자들에게 나눠 주고(처리량 확장), 발행–구독은 모두에게 복사한다(이벤트 알림).
• 생산 > 소비가 지속되면 큐가 쌓이고 결국 backpressure(지연·유실). 소비자 확장이나 흐름 제어가 필요.
• 현실에서는 at-least-once + 멱등 소비자 조합이 가장 흔하다.