요즘 주목받는 아키텍처인 MSA가 적용된 시스템을 EDA가 보완할 수 있다. 이때 MSA를 이용하여 서비스를 개발하다 보면, 한 API에서 다른 API로 정보를 전달하고 싶을 때가 있다. 이러한 상황에서 쓸 수 있는 것이 Pub/Sub 모델이다.
- 예를 들어,
User 서비스: 회원가입 발생 →
Coupon 서비스: 회원가입 기념 쿠폰 발행 / Point 서비스: 회원가입 기념 포인트를 유저에 제공
Message Queue 방식
Kafka: 소셜 네트워크 서비스, 링크드인에서 개발함.
개발 배경(기존 데이터 시스템의 문제점)
- App <-> DB (End-to-End)
- 요구사항이 늘어나면서 복잡도 ↑
- Complexity: Data Flow 파악 어렵 - 관리 어렵 - 장애 조치 시간 증가
- Data Pipeline 관리의 어려움
→ 모든 시스템으로 데이터를 전송할 수 있고, 실시간 처리도 가능하고, 급속도로 성장하는 서비스를 위해 확장이 용이한 시스템을 만들자
특징
- 모든 이벤트/데이터의 흐름을 "중앙"에서 관리
- 확장성 용이 → 신뢰성 증가
- 서비스 간 (x), 각 서비스의 비즈니스 로직에 집중하면 됨
동작 방식: Message Queue
-
Message Queue(MQ)-
MOM(Message Oriented Middleware)를 구현한 시스템
- 프로그램(프로세스) 간 데이터를 교환할 때 사용하는 기술
-
메시지는 Endpoint 간 직접 통신하지 않고, Queue을 통해 중개됨
-
Producer: 정보 제공 하는 자 -
Consumer: 정보 제공 받는 자 -
MQ:Producer의 데이터를 임시 저장하고Consumer에게 제공하는 곳
- 장점
- 비동기: Queue라는 임시 저장소로 인해 나중에 처리 가능
- 낮은 결합도
- 확장성: 각 Endpoint를 원하는대로 확장 가능
- 탄력성: 한 Endpoint가 다운되더라도 Queue에 남아있음
- 보장성: MQ에만 들어가면 모든 메시지가 Consumer에 전달됨
-
-
Message Broker(Redis)
- Pub/Sub 구조:
Publisher가 생산한 메시지를 MQ에 저장 + 저장한 메시지를Subscriber에 전달 - 비동기 전송:
publisher는 수신자가 없어도publish가능,Subscriber는Subscribe한 메시지만 수신 가능, 발신자 정보가 없어도 수신할 수 있음. Subscriber가 메시지를 가져가면, 짧은 시간 안에 큐 내 데이터가 삭제됨.
- Pub/Sub 구조:
-
Event Broker(Kafka)
- Message Broker 역할인 것은 동일하나 차이점이 있음
- 이벤트 처리 후 바로 삭제하지 않고, 시점을 저장함
- 따라서
Subscriber가 특정 시점부터 이벤트를 다시Subscribe할 수 있음- e.g. 장애가 일어난 시점부터 이벤트를 다시 처리 가능
- 더불어서 MB보다 더 많은 양의 데이터 처리 가능
- Message Broker 역할인 것은 동일하나 차이점이 있음
Pub/Sub 모델: Redis, Kafka
Redis(Message Broker)
-
Publisher - Channel - Subscriber -
특징
channel- 이벤트가 도착했을 때 해당 채널의 Subscriber가 없다면 이벤트는 사라진다(= 이벤트를 저장하지 않는다.).
subscriber- 여러
channel동시 구독 가능 - 특정
channel을 지정하지 않아도, 패턴을 설정할 수 있어 이에 맞는 채널 구독 가능
- 여러
-
장단점
- 빠른 처리 속도, 명시적 데이터 삭제
- 메모리 기반으로 서버 다운 시 Redis 내 모든 데이터 사라짐, 이벤트 도착 보장이 불가능함
Kafka(Event Broker)
-
Producer - Topic - Consumer(Publisher - Channel - Subscriber와 동일 개념)Topic은 여러Broker에 분산 저장되며, 분산된Topic을partition이라 함- Partition Topic 관리:
ZooKeeper
-
동작 방식
-
Producer: 전달하려는 메시지를 Topic에 전달 -
Topic: Topic의 각 Partition에 이벤트가 분산되어 저장(카테고리화) -
Consumer: 구독하고 있는 Topic의 1개 이상의 partition으로부터 이벤트를 가져옴(=메세지를 읽음)+
Broker들이 하나의Cluster로 구성되어 동작하도록 설계되어 있음
+Cluster내Broker분산 처리 담당은ZooKeeper
-
-
장점
- 대규모 트래픽 처리 및 분산 처리에 효과적
- 메세지를 저장하여 장애 시 재처리 가능
주된 차이점
-
1. 이벤트의 저장 여부
- Kafka: 발행된 이벤트가 각 Partition에 저장됨
- Redis: 발행된 이벤트를 저장하지 않아서 Subscriber가 없을 시 사라짐
- 고려 조건: 이벤트의 발행 및 구독이 실시간으로 이루어져야 하는 상황인가? || 발행된 이벤트를 언제든 읽으면 되는 상황인가?
-
2. 한 이벤트를 받을 수 있는 Subscriber(Consumer) 개수
한 이벤트에 대해 1번의 기능만 작동되어야 한다면 Kafka를 사용하는 것이 유리하다.
만약 AWS를 통해 서버를 배포하는 중이라면 Scale-out 등의 이유로 서버 인스턴스가 여러 개 작동하고 있을 수 있다. 이때, 앞선 예시에서 Coupon 서비스는 유저 회원 가입에 대한 Topic을 구독하고 있으며, 회원가입을 했다는 이벤트를 받으면 기념 쿠폰을 발행한다고 가정하자. 이때 Coupon 서비스는 2개의 서버를 사용한다고 하자.
-
Kafka: Consumer의 수와 관계없이, 유저 회원가입당 하나의 쿠폰이 발행
- Partition으로부터 이벤트를 가져올 때, 2개의 서버가 있다한들, Group 내에서 구독하는 Topic의 이벤트를 1개의 서버만이 받아올 수 있음. 따라서 매번 1개의 쿠폰만이 발행됨.
- Partition으로부터 이벤트를 가져올 때, 2개의 서버가 있다한들, Group 내에서 구독하는 Topic의 이벤트를 1개의 서버만이 받아올 수 있음. 따라서 매번 1개의 쿠폰만이 발행됨.
-
Redis: User는 1번의 회원가입으로 2개의 쿠폰을 얻게 됨
-
Redis는 Group 구분이 없기 때문
발행된 이벤트가 모든 Subscriber에서 발생되어야 하는 경우, Redis가 유리하다.
내가 개발한 Gateway의 권한 플러그인에서, 존재하는 모든 권한 목록을 서버가 ‘시작될 때’ 가져온다. 이때 새로운 권한 추가 / 삭제 시 서버 재시작 전까지는 권한 목록을 갱신할 수가 없다는 문제가 발생한다.
-
Kafka: gateway 서버가 두 개 이상 뜨더라도, 각각의 서버는 같은 Consumer Group에 속하기 때문에, Permission Service에서 보낸 이벤트를 단 한 서버만 받을 수 있다. 결국 권한 목록의 갱신은 하나의 서버 인스턴스에만 이루어지게 되고, 이는 synchronization 문제를 낳는다.
-
Redis: Redis는 Group이라는 개념이 없기 때문에, Gateway Server가 여러 개 뜬다고 하더라도 각각이 이벤트를 받을 수 있다
-
언제 사용하는 것이 좋을까
Kafka: 대용량 데이터 처리, 실시간, 고성능, 고가용성이 필요한 경우- 한 이벤트에 대해 1번의 기능만 작동되어야 하는 경우
- 추가로 저장된 이벤트를 기반으로 로그를 추적하거나 재처리가 필요한 경우
Redis: 메시지를 DB에 저장하기 때문에 이벤트를 미들웨어에 저장할 필요가 없는 경우, 꼭 알람이 도착한다는 보장 없이 Push 보내는 것만 중요한 경우, 발행된 이벤트가 모든 Subscriber에서 발생되어야 하는 경우
ref) 카프카란 무엇인가
