발행-구독 모델
IT 위키
더 많은 작업
- Publish-Subscribe; Pub/Sub; 발행-구독; 게시-구독
- 메시지를 보내는 발행자가 받는 쪽을 지정하지 않고 토픽에 메시지를 보내면, 그 토픽을 구독한 모든 수신자에게 전달되는 비동기 메시징 모델
발행-구독 모델에서는 발행자와 구독자 사이에 메시지 브로커(또는 라우터)가 끼어 있다. 발행자는 "주문 생성" 같은 토픽에 메시지를 한 번 보내고, 브로커가 그 토픽을 구독한 수신자 목록을 보고 메시지를 복제해 각자에게 전달한다. 발행자는 누가 받는지, 구독자는 누가 보냈는지 몰라도 된다. 이렇게 보내는 쪽과 받는 쪽을 떼어 놓기 때문에 구독자를 늘리거나 바꿔도 발행자 코드는 그대로이다. 이벤트 기반 아키텍처를 구현하는 기본 통신 방식이다.
| 구성 요소 | 역할 |
|---|---|
| 메시지 | 전달하려는 데이터. 문자열, JSON, 센서 값, 바이너리 등 |
| 발행자(publisher) | 특정 토픽에 메시지를 보내는 쪽. 수신자를 알지 못함 |
| 토픽(topic) | 발행자와 구독자를 잇는 논리적 채널. 관심 있는 수신자 목록을 가짐 |
| 구독자(subscriber) | 토픽에 등록해 메시지를 받는 쪽. 서로 독립적으로 동작 |
| 브로커(broker) | 토픽과 구독을 관리하고 메시지를 라우팅·전달하는 중간 기반 시설 |
| 구분 | 발행-구독 | 점대점(메시지 대기열) |
|---|---|---|
| 전달 대상 | 일대다. 구독자 모두가 같은 메시지를 받음 | 일대일. 메시지 하나는 소비자 하나만 처리 |
| 여러 소비자의 의미 | 서로 다른 일을 하는 수신자들(결제, 배송, 분석) | 같은 일을 나눠 맡는 작업자들(부하 분산) |
| 전달 방식 | 주로 브로커가 밀어 줌(push) | 주로 소비자가 가져감(pull) |
| 메시지 보관 | 전달 후 보관하지 않는 경우가 많음 | 소비자가 처리하고 삭제할 때까지 보관 |
| 구독자 부재 시 | 구독자가 없거나 꺼져 있으면 메시지가 버려질 수 있음 | 대기열에 쌓였다가 나중에 처리 |
| AWS 예 | 아마존 SNS, 아마존 EventBridge | 아마존 SQS |
두 방식은 함께 쓰는 경우가 많다. 토픽에 대기열을 구독시키면, 발행-구독의 일대다 복제와 대기열의 보관·완충을 동시에 얻는다.
팬아웃(fan-out)은 토픽에 발행된 메시지 하나가 여러 엔드포인트로 복제되어 병렬 처리되는 것을 말한다. 예를 들어 온라인 쇼핑몰이 주문 메시지를 한 번 발행하면 결제, 재고, 배송, 데이터 분석 시스템이 각자 받아 동시에 처리한다. 새로운 처리 시스템이 필요해지면 구독만 추가한다. AWS에서는 SNS 토픽에 여러 SQS 대기열을 구독시키는 SNS → SQS 팬아웃이 대표 구현이다.
구독자는 토픽의 모든 메시지가 아니라 일부만 원할 수 있다.
- 토픽 기반: 토픽을 잘게 나누어 필요한 토픽만 구독한다. MQTT의 계층형 토픽 이름(예: factory/line1/temperature)과 와일드카드가 대표적이다.
- 내용 기반: 메시지 속성이나 본문 값으로 조건을 걸어 맞는 메시지만 받는다. SNS 구독 필터 정책, EventBridge 이벤트 패턴이 이 방식이다.
| 장점 | 단점 |
|---|---|
| 발행자와 구독자가 서로 몰라 결합도가 낮음 | 발행자는 구독자가 메시지를 실제로 받았는지 알기 어려움 |
| 구독자 추가만으로 기능 확장 | 구현에 따라 순서 보장이 없거나 중복 전달이 생겨 멱등 처리가 필요 |
| 메시지 하나로 여러 작업을 병렬 처리 | 구독자 데이터가 시차를 두고 맞춰지는 결과적 일관성 |
| 서로 다른 언어·플랫폼의 시스템을 쉽게 연결 | 단방향이라 응답이 필요하면 요청-응답 패턴을 별도로 설계 |
| 브로커에서 접근 제어·암호화를 일괄 적용 | 메시지 수명(TTL)이 지나거나 전달에 실패한 메시지 처리 설계 필요(DLQ 등) |
| 구현 | 특징 |
|---|---|
| 아마존 SNS | AWS의 완전 관리형 pub/sub. 구독 프로토콜로 SQS, Lambda, HTTP/S, 이메일, SMS, 모바일 푸시 지원. 구독 필터 정책, FIFO 토픽 제공 |
| 아마존 EventBridge | 이벤트 버스와 규칙으로 내용 기반 라우팅. AWS 서비스와 SaaS 이벤트를 받음 |
| 아파치 카프카 | 토픽을 로그로 저장해 여러 생산자가 쓰고 여러 소비자가 읽음. 메시지가 소비 후에도 지워지지 않고 토픽별 보존 기간 동안 남아 여러 번 다시 읽을 수 있음. AWS에서는 아마존 MSK로 관리형 제공 |
| MQTT | IoT용 경량 pub/sub 프로토콜. 계층형 토픽과 와일드카드(+는 한 단계, #는 여러 단계), QoS 0(최대 1회)·1(최소 1회)·2(정확히 1회), 보존(retained) 메시지 지원. AWS IoT Core가 MQTT 브로커 역할을 함 |
참고로 같은 프로세스 안에서 대상 객체가 관찰자 목록을 직접 들고 알림을 보내는 옵저버 패턴(소프트웨어 디자인 패턴 참고)과 달리, 발행-구독은 브로커가 사이에 있어 발행자와 구독자가 서로를 전혀 모른다는 점이 다르다.
- "한 이벤트를 여러 시스템에 동시에 전달", "새 소비자를 발행자 수정 없이 추가"는 발행-구독(SNS, EventBridge)이다.
- 메시지를 잃지 않고 각 소비자가 자기 속도로 처리해야 하면 토픽 뒤에 SQS 대기열을 붙인다(SNS → SQS 팬아웃).
- 작업 하나를 여러 작업자 중 한 명만 처리해야 하면 발행-구독이 아니라 대기열(SQS)이다.
- 구독자마다 필요한 메시지만 받게 하려면 SNS 필터 정책이나 EventBridge 이벤트 패턴을 쓴다.
- 순서와 중복 방지가 필요한 팬아웃은 SNS FIFO 토픽과 SQS FIFO 대기열 조합이다.
- What is Pub/Sub Messaging? – AWS
- 게시-구독 패턴 – AWS 권장 가이드
- Introduction – Apache Kafka
- MQTT Version 5.0 – OASIS