강의 대본
Queue group with Nats Fanout
description
하나의 subject(starfruit.internal.event)를 여러 개의 queue group이 구독하는 모델입니다.
3가지의 서비스가 있으며 각 서비스 별로 3개의 인스턴스가 있는 분산 환경 구성입니다.
각 서비스는 모두 공통의 nats Subejct를 구독하고 있어서 이벤트를 모든 서비스가 동시에 수신할 수 있지만,
nats queue group(QueueSubscribe)을 이루고 있기 때문에
이벤트 수신 시, 서비스 내에서 단 하나의 인스턴스만이 이벤트를 처리합니다.
적용 사례
- 특정 이벤트 발생 -> 이벤트에 대해서 여러 서비스에서 작업을 처리해주어야 하는 경우 해당 구조를 활용할 수 있습니다.
- 여러 서비스에서 동시에 병렬적으로 작업을 처리를 할 수 있으며, 서비스 간의 비즈니스 로직 결합도를 낮출 수 있다는 장점이 있습니다.
- 예: 회원 가입 이벤트 발생하였을 때 해당 회원의 이메일로 가입 관련 내용을 전송해야 하고,
회원 가입 내역을 로그로 남겨야 하는 경우, user.Signup subject를 여러 서비스에서 구독합니다.
이메일 처리 서비스는 user.Signup subject로 된 메세지를 수신하여 이메일을 전송하면 되고
로그 서비스는 user.Signup subject로 된 메세지를 수신하여 DB에 해당 로그를 동시에 남기면 됩니다.
- 단 분산환경을 고려했을 때, 이벤트를 수신한 각 서비스 인스턴스들 중 단 하나의 인스턴스만이 해당 이벤트를 수신하여 처리를 하도록 하려면, 각 서비스 인스턴스들은 subject에 대해 QueueSubscription을 해야합니다.
-
- 따라서 이벤트 subject를 설계를 할때는, "특정 서비스에서 어떤 역할을 하세요" 라는 의미를 담은 명령형 이벤트가 아닌, "사실 그 자체"를 담도록 subject 네이밍을 해주세요.
올바르지 못한 subject 예: user.requestSendEmail, user.recordLog (서비스간 비즈니스 로직 결합도 증가, 비즈니스 시나리오 변경 대비에 불리함)
올바른 subject 예: user.Signup
관련 문서
실행방법
# nats 서버 실행
docker-compose up -d
# poc 코드 실행
go run main.go
- [처리 완료] 로그에서 이벤트가 어떤 서비스의 어떤 인스턴스에 의해 처리가 되었는지 확인해 보세요