Fanout Service
Fanout Service는 하나의 데이터를 다수의 수신자에게 빠르고 효율적으로 전달하는 시스템 아키텍처.
소프트웨어 아키텍처에서도 Fanout은 메시징 패턴의 하나로 자주 활용되며, 특히 이벤트를 다수의 구독자에게 병렬로 전달해야 할 때 효과적이다.
일반적으로 대규모 시스템에서 하나의 이벤트 또는 데이터가 수많은 구독자에게 동시에 전달되어야 하는 상황이 자주 발생하는데, 이때 Fanout 구조가 사용된다.
즉, 발행자(Publisher)가 특정 주제(Topic)에 메시지를 발행하면, 그 주제에 관심이 있는 구독자(Subscriber)가 메시지를 수신하는 구조이다.
이처럼 Fanout은 "하나의 이벤트 → 다수의 소비자에게 확산"이라는 패턴을 구현하며, 확장 가능하고 느슨하게 결합된 구조를 만드는 핵심 컴포넌트로 활용됩니다.
왜 쓸까?
성능 분산
하나의 이벤트(ex 게시글 업로드, 댓글 작성)를 여러 사용자에게 동시에 알림을 보내야 할 때, 모든 수신자를 단일 서비스가 직접 처리하면 과부하가 걸릴 수 있다.
: Fanout 구조로 분산시켜 각 수신자나 그룹에게 병렬로 빠르게 전파 가능하다.
아키텍처의 분리와 유연성
발행자(Producer)와 수신자(Consumer)를 완전히 분리시킬 수 있다.
Ex_ 알림, 푸시, 이메일, 피드 반영 등 다양한 수신자 로직을 개별 서비스로 독립시킬 수 있다.
비동기 처리
Fanout은 보통 비동기 메시징 시스템(Kafka, RabbitMq, Redis Pub/Sub 등)을 통해 구성된다.
: 발행자가 느려지지 않도록, 메시지만 날리고 처리는 나중에 하도록 만들 수 있다.
사용자 개인화 처리 가능
A라는 사용자는 "친구 게시물만", B라는 사용자는 "모든 게시물" 등 조건이 다를 경우
: Fanout 단계에서 각 사용자 조건에 맞는 데이터 선별이 가능하다.
동작 방식
- 이벤트 발생
- 이벤트를 Fanout Service가 수신
- Fanout Service는 수신한 이벤트를 구독자(Subscribers) 리스트 기반으로 분산
- 각 구독자에게 이벤트를 전송
주요 구성 요소
이벤트 수신부
이벤트 수신부
: 메시지 큐 또는 HTTP 기반의 웹훅(Webhook) 형태로 이벤트를 수신
구독자 관리 시스템
: 구독자 목록을 유지하며 각 이벤트가 어디로 전송될지 결정
분산 처리 엔진
: 대량의 메시지를 빠르게 처리하고, 다수의 엔드포인트에 전송하는 분산 작업 처리 시스템 (Ex_ Kafka, RabbitMQ, AWS SNS)
오류 처리 및 재시도 메커니즘
: 메시지 전송 실패 시 재시도하거나 실패한 작업을 로깅하는 시스템
예시(1)
A. SNS 피드 생성
유저 A가 게시글을 업로드 -> 팔로우 1,000명에게 피드 전파 필요
: Fanout을 통해 게시글 ID를 큐에 넣고, 각각의 팔로워에게 피드 반영 작업 수행
B. 푸시 알림 발송
한 이벤트(Ex_ 친구 요청)를 모든 관련 유저에게 동시에 전송
: Fanout -> 푸시 발송 서비스들로 병렬로 메시지 분배
C. AWS SNS + SQS
AWS SNS와 SQS를 활용한 구조로, Pub/Sub 및 Fan-out 아키텍처
하나의 SNS 주제(Topic)에 메시지를 발행하면,
이를 구독 중인 여러 SQS 큐로 동시에 전송하고,
각 큐는 독립적으로 메시지를 비동기적으로 수신한 후 Lambda 함수가 이를 처리하며,
그 결과는 DynamoDB, S3 등 외부 저장소에 저장하는 방식이다.
장점
높은 확장성
: 수백만 사용자에게 동시 알림 가능
빠른 응답 속도
: 실시간 처리를 통해 지연 최소화
효율적 리소스 사용
: 서버 부하를 최소화하고 병렬 처리를 활용
고려 사항
메시지 전달 보장
: 메시지가 유실되지 않고 정확히 전달되도록 보장
메시지 순서
순서 보장이 중요한 서비스에서는 SQS FIFO Queue 등을 통해 순서를 제어하는 전략이 필요하다.
장애 처리
: Fanout Service가 중단되었을 때, 메시지 처리를 어떻게 할지
참고 벨로그 - taekwonV.log
