발행과 구독

주문 하나에 관심 있는 사람들

주문이 하나 들어왔습니다. 이 사실에 관심 있는 곳이 몇 군데나 될까요?

• 메일 담당: 주문 확인 메일을 보내야 합니다.
• 창고 담당: 물건을 꺼내 포장해야 합니다.
• 통계 담당: 오늘 매출에 더해야 합니다.

주문 서버는 이 세 곳을 어떻게 움직여야 할까요?

방법 1 — 일일이 전화를 돌린다

주문 서버가 메일 서비스를 호출하고, 창고 서비스를 호출하고, 통계 서비스를 호출합니다. 단순하고 명확합니다. 그런데 여기에 두 가지 병이 숨어 있습니다.

첫째, 새 관심사가 생길 때마다 주문 서버를 고쳐야 합니다. 내일 마케팅팀이 "주문할 때마다 쿠폰을 주고 싶다"고 하면 주문 서버 코드를 열어 호출을 하나 더 넣습니다. 모레 고객센터가 또 요청합니다. 주문과 아무 상관없는 이유로 주문 서버가 계속 바뀝니다. 가장 중요한 코드가 가장 자주 흔들립니다.

둘째, 남의 사정이 내 사정이 됩니다. 통계 서버가 죽어 있으면 호출이 실패합니다. 그러면 주문도 실패시켜야 할까요? 통계가 안 밀렸다고 주문을 취소하는 건 말이 안 됩니다. 하지만 직접 호출 구조에서는 그 실패가 자연스럽게 위로 번집니다.

방법 2 — 관보에 싣는다

주문 서버는 딱 한 가지만 합니다. "주문이 발생했다"고 알립니다. 끝입니다. 누가 그 소식을 듣는지, 몇 곳이나 듣는지, 듣고 뭘 하는지 주문 서버는 모릅니다. 알 필요도 없습니다.

관심 있는 쪽이 각자 구독합니다. 메일 담당이 읽고, 창고 담당이 읽고, 통계 담당이 읽습니다.

방법 1:  주문 서버 ──호출──> 메일
                 ──호출──> 창고      (주문 서버가 셋을 다 안다)
                 ──호출──> 통계

방법 2:  주문 서버 ──발행──> [주문 발생]
                               ├── 메일이 구독
                               ├── 창고가 구독   (주문 서버는 아무도 모른다)
                               └── 통계가 구독

말투가 바뀐다

이 구조에서 가장 중요한 변화는 그림이 아니라 말투입니다.

발행-구독은 명령이 아니라 사실을 흘려보냅니다. 사실은 누가 듣든 변하지 않으므로, 듣는 쪽이 늘어나도 말하는 쪽은 그대로입니다.

그래서 무엇이 좋아지나

새 구독자를 공짜로 붙일 수 있습니다. 마케팅팀이 쿠폰을 주고 싶다면 자기 구독을 하나 만들면 됩니다. 주문 서버는 한 글자도 바뀌지 않습니다. 담당 조직이 서로 다를 때 이건 코드 문제가 아니라 일정 문제입니다. 남의 팀 배포를 기다리지 않아도 됩니다.

한 곳의 고장이 갇힙니다. 통계 담당이 죽으면 통계 큐에만 일이 쌓입니다. 메일은 정상 발송되고, 창고는 정상 출고되고, 주문은 정상 접수됩니다. 통계 담당이 살아나면 쌓인 것을 읽어 따라잡습니다. 고장이 번지지 않고 한 칸에 머무는 것, 이게 이 구조의 진짜 값어치입니다.

대가도 분명하다

공짜는 아닙니다. 주문 서버 로그만 봐서는 메일이 실제로 갔는지 알 수 없습니다. "발행했다"까지만 압니다. 문제가 생기면 여러 구독자의 상태를 각각 따라가야 합니다. 전체를 한눈에 보기 어려워지는 것, 이것이 느슨하게 묶은 대가입니다.

이 강의에서는 토픽 하나에 구독자마다 큐를 하나씩 매달아 발행-구독을 표현합니다. 토픽이 사본을 만들어 모두에게 보내고, 큐가 구독자별로 나뉘어 있어야 한 구독자가 밀려도 다른 구독자가 멀쩡합니다.