Pub-Sub & Fan-out Mechanics

1. Overview

발행-구독 및 팬아웃 역학(Pub-Sub & Fan-out Mechanics, PFM)은 송신자가 특정 수신자를 지목하지 않고 '채널'에 데이터를 던지면, 그 채널을 지켜보던 수만 명의 구독자가 동시에 정보를 낚아채게 만드는 방송형 소통 공학입니다.

학습자는 정보 생산자와 소비자의 물리적 결합을 극한으로 낮추는 발행/구독(Pub/Sub) 모델의 수리적 수순과, 단일 메시지를 기하급수적으로 복제하여 뿌리는 **팬아웃(Fan-out)**의 하드웨어 부하 분산 원리를 배웁니다. 특히, 주제(Topic) 기반 필터링의 수리 모델과, 수신측 가용성에 따라 메시지가 휘발되거나 보관되는 물리적 특징을 익힙니다. 이를 통해 실시간 뉴스 피드, 라이브 알림, 시스템 이벤트 버스 등 대규모 전파가 필요한 하이엔드 분산 소통 인프라 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Pub/Sub Patterns: 발행자, 브로커(Bus), 구독자의 물리적 삼각 관계 설계
• Fan-out Physics: 단일 입력을 N개의 큐 혹은 소켓으로 복제하는 하드웨어 가중치
• Filtering Mechanisms: Content-based vs Topic-based 수리적 선별 수순
• Message Volatility: Redis Pub/Sub 등 인메모리 방식의 전송 보장 한계와 속도
• Push vs Pull Dynamics: 브로커가 밀어주는 방식과 구독자가 당겨가는 방식의 하드웨어 처리 비교

Out-of-Scope

• 단일 객체 지향 언어 내에서의 옵저버(Observer) 패턴 코드 상세 (04-02-XX 영역으로 위임)
• 웹소켓(WebSocket) 프로토콜 자체의 핸드셰이크 물리 (08-03-03 영역에서 분담)

Boundaries

• PFM vs. Message Queues: MQB(08-04-01)가 '한 메시지를 한 명만' 처리하는 경쟁 소비에 집중한다면, PFM은 '한 메시지를 모두가' 받는 공유 소비에 집중하여 전송 모델을 구분합니다.

3. Counterexample

• 단순히 "알람 보내기"라 설명하는 것은 PFM 학습이 아닙니다. 왜 구독자(Subscriber) 숫자가 10배 늘어났을 때 브로커의 네트워크 카드(NIC) 대역폭이 수리적으로 포화(Saturation)되는지 '팬아웃 계수'로 증명할 수 있어야 하며, Redis Pub/Sub 사용 시 수신 측 지연이 발생할 때 왜 메시지가 물리적으로 '드랍(Drop)'되는지 버퍼 관리 물리학으로 논증하지 못한다면 PFM의 본질을 이해하지 못한 것입니다.

4. Prerequisites

• Network Foundations & OSI Stack (Basic): 브로드캐스트 및 멀티캐스트 물리 기초 이해가 필수입니다. (08-01-01 PDP)
• Data Structures & Algorithms (Recommended): 트리 및 라우팅 테이블 검색 알고리즘 이해가 권장됩니다. (04-03-XX)

5. Learning Map

1. Broadcasting Vision: 1<1> 통신을 넘어 '관심사가 같은 모든 이'에게 외치는 물리적 소통을 이해합니다.
2. Channel Strategy: 데이터의 성격에 따라 채널(Topic)을 쪼개고 구독자 그룹을 수리적으로 배치합니다.
3. Replication Storm: 기하급수적으로 복제되는 데이터가 인프라 물리 한계를 넘지 않게 조절합니다.
4. Instant Reach: 수 밀리초 만에 수만 곳으로 정보가 뻗어 나가는 하이엔드 전파망을 완성합니다.

6. Learning Topics

Basic

Core: 발행/구독 모델의 기본 구조 (Pub/Sub Foundations)

• Why to Learn: 송신자가 수신자가 누구인지 알 필요가 없는 유연한 시스템을 구축하기 위해서입니다.
• What to Learn:
  • Publisher Duties: 채널에 메시지를 태워 보내는 물리 행동
  • Subscriber Interests: 원하는 주제에 귀를 기울이는 수리적 등록
  • Decoupling Benefits: 시스템 모듈을 마음대로 넣고 뺄 수 있는 물리적 자율성
• How to Learn:
  • Redis의 PUBLISH와 SUBSCRIBE 명령어를 터미널 두 개에서 돌려보며, 즉각적인 전파 과정 확인 실습
  • 구독자가 0명일 때 메시지가 물리적으로 증발하는 현상 관찰
• Implement: 주제별로 구독자 리스트를 관리하고 배포하는 가상 PubSubHub

Recommended

Core: 팬아웃 하드웨어 부하와 복제 (Fan-out Dynamics)

• Why to Learn: 인기가 많은 게시물이 전송될 때 왜 서버 대역폭이 비명을 지르는지 알기 위함입니다.
• What to Learn:
  • Fan-out Ratio: 입력 대비 출력 패킷 수의 수리적 배수
  • Backbone Saturation: 메시지 복제가 네트워크 백본 하드웨어에 미치는 영향
  • Message Cloning: 브로커 내부에서 데이터 메모리를 복사하는 물리 수순
• How to Learn:
  • 메시지 하나를 100명의 구독자에게 쏠 때 발생하는 네트워크 인터페이스의 초당 전송량($BPS$) 측정 실습
  • 브로커 성능 한계 도달 시 신규 구독자의 물리적 거부 시나리오 분석
• Implement: 입력 메시지를 지정된 N개의 타겟으로 복제 전송하는 FanOutBridge

Practical

Core: 주제 기반 필터링과 와일드카드 (Filtering Mechanics)

• Why to Learn: 수만 개의 주제 중에서 사용자가 원하는 정확한 데이터만 수리적으로 골라내기 위해서입니다.
• What to Learn:
  • Topic Tree Structure: 계층적 주제(예: log/error/db)의 물리적 배치
  • Wildcard Matching: *나 # 기호를 사용한 수리적 패턴 매칭 수순
  • Trie-based Routing: 고속 필터링을 위한 전용 트리 자료구조 활용 물리학
• How to Learn:
  • MQTT 프로토콜 설정에서 복잡한 토픽 필터를 걸어보고, 의도한 메시지만 물리적으로 도달하는지 검증 실습
  • 필터 패턴이 복잡해질 때 브로커의 CPU 연산량 변화 수치 측정
• Implement: 와일드카드가 포함된 채널 주소와 메시지 주소를 대조하는 TopicMatcher

Advanced

Core: 고가용성 전파 시스템 거버넌스 (Reliable Broadcast)

• Why to Learn: 메시지가 휘발되면 안 되는 중요 알림(푸시 결제 등) 환경을 설계하기 위함입니다.
• What to Learn:
  • Durable Subscriptions: 구독자가 오프라인일 때도 메시지를 가두는 물리적 큐 결합
  • Message Ordering in Broadcast: 여러 구독자가 보는 순서가 동일해야 하는 수리적 정합성
  • Backpressure in Pub/Sub: 너무 많은 구독자가 느릴 때 전체 전파 속도를 조절하는 법
• How to Learn:
  • AWS SNS와 SQS를 결합하여 전파된 메시지를 물리적으로 보존하는 아키텍처 구현 실습
  • 클러스터된 브로커들 사이에서 구독자 정보($State$)가 동기화되는 물리 지연 수치 분석
• Implement: 구독자의 수신 확인($ACK$)이 늦어질 때 전송량을 제한하는 CongestionBroadcast

7. Terminology

8. References

Primary

• [P1] CS2023 - NC/Networking and Communication (Network applications / Information models) — Information flow.
• [P2] SWEBOK v4.0 - Software Design / Software Structure and Architecture (Event-driven systems) — Structural context.

Secondary

• [Enterprise Integration Patterns] Gregor Hohpe — Pub-Sub and Fan-out chapters.
• [Building Microservices] Sam Newman — Event-driven communication parts.

Industry

• [Redis: Pub/Sub Documentation] — In-memory messaging physics.
• [AWS: SNS (Simple Notification Service) Features] — Managed fan-out logic.

9. Final Checklist

Primary

• '발행-구독 모델'이 '요청-응답 모델'보다 분산 시스템 확장성($Scalability$)에서 물리적으로 왜 유리한지 설명 가능한가? (P1)
• '토픽 기반 라우팅'이 왜 브로커의 하드웨어 리소스를 소모하는 수리적 원인이 되는지 기술할 수 있는 가? (P1)

Secondary

• '팬아웃 계수'가 100을 넘을 때, 단일 브로커 하드웨어가 겪는 물리적 병목($Bottleneck$) 시나리오를 소통 가능한가?
• Redis Pub/Sub의 'Fire-and-forget' 성질이 하이브리드 장애 상황에서 데이터 유실에 미치는 수리적 영향을 논증할 수 있는 가?

Industry

• 대규모 이벤트 뉴스 피드 설계 시, 실시간성과 하드웨어 가용성 사이의 수리적 균형을 맞추는 채널 분할 전략을 제안할 수 있는 가? (SFIA)
• '와일드카드 구독'이 수천만 개의 메시지 흐름 속에서 유발하는 수리적 계산 비용과 그 최적화 방안을 분석할 수 있는 가?