안녕하세요. 쿠폰 스쿼드 포덕입니다.
지난 시간엔 어푸님께서 Sync 쿠폰 발급에서 Async로 전환하며 Redis Worker에 대해 포스팅 해주셨습니다.
이번 시간엔 지난 Redis Worker에서 Rabbit MQ로 최종 도입하게 된 배경 및 사용 기술에 대해 작성하게 되겠습니다.
도입 배경
얼마 전 쿠폰 발급을 Redis Worker의 도입 에 대해 포스팅 하였었습니다.
도입 전 세일 대비 발급량에서 우월한 성능을 보여주었지만... Redis에겐 문제가 있었습니다.
1️⃣ 저희의 Redis의 Worker는 list를 MQ의 형태로 활용하였는데,(이전 포스팅 참고)
해당 방법은 단순 처리하기엔 충분하였으나, 추후 기능의 확장을 위한 부분이 미비할 수 있었습니다.
2️⃣ Redis Worker의 세일 발급 당시 과도한 요청 처리에 대해 불편한 사항이 있었습니다.
일반적인 쿠폰발급에는 이상이 없었으나, 네고왕/세일과 같은 행사기간에 간혹 문제가 발생하였습니다.
보다 안정적인 발급 처리와 기능적인 확장을 위해 MQ를 도입하게 되었습니다.
왜 RabbitMQ를 사용했나요?
개인적으로 MQ 하면 대표적으로 RabbitMQ 와 Kafka가 있다고 생각합니다.
AWS sandbox를 제공해주시어, 적극적인 PoC를 통해 선정하였습니다.
1️⃣ MSK
Aws가 제공하는 Kafka서비스입니다.
스토리지 size지정부터 AZ영역,네트워크설정 등
어지간한건 Aws가 다 관리해줍니다. 모니터링 LOG의 제공 및 지표 확인은 유료입니다.
특징으로는
- 파티션 정책을 통해 분산처리가 가능합니다. 대용량 데이터 처리 지표가 우수합니다.
- 메시지 영속성을 가집니다.
- 수신을 보장하는 경우 사용합니다.
2️⃣ RabbitMQ
마찬가지로 Aws Managed RabbitMQ를 사용하였습니다.
관리는 위 MSK와 유사합니다.
- 가장 큰 장점은 사용이 간편합니다.
- 다양한 메시지 교환방식으로 유연한 구조설계가 가능합니다.
- 수신을 보장하는 경우 사용합니다.
둘 다 유사하지만, 내부적인 동작이 다릅니다. 메시지 영속성이라던가..분산처리방식이라던가..
대용량 데이터 처리 지표는 kafka가 높은 것으로 알려져 있습니다.
하지만, 저희 스쿼드는 세일기간 혹은 특정 이벤트마다 scalability한 유연한 구조로 운영이 이루어지기 때문에
확장 이후 축소가 불가한 Kafka의 파티션 정책은 저희와 맞지 않았습니다.
그리고 RabbitMQ는 활용도에 따라서 Kafka보다 오히려 더 다양한 처리에 유용하다고 생각하여 도입하게 되었습니다.
사용 후기
- 전
- 후
이전 일련번호를 통해 list의 데이터를 읽어오고, 처리를 위한 비동기 구성을 한 것과 달리,
RabbitMQ는 내부적으로 concurrency를 이용하기 때문에 처리가 간소화되었습니다.
그리고 기존 배치로 처리하던 고객 쿠폰 대량 발급처리와
세일행사 및 기타 쿠폰 발급처리에 도입하였습니다.
1️⃣ 세일행사 및 기타 쿠폰 발급
메시지 처리(실 발급) Process는 달라지지 않았기에, 메시지 Consume을 하고 RabbitMQ Config를 코드기반으로 구성하였습니다.
prefetch와 concurrency 설정 및 direct exchange 방식을 채택하였습니다. (사진은 간단한 예시입니다.)
발급량은 이전 5월 네고왕이나 6월 세일만큼 총 발급량이 많지 않지만, 성능은 안정적으로 나왔습니다. 기존 과도한 요청 처리시 불편하던 사항도 해결되어, 보다 안정적인 발급이 가능하게 되었습니다.😆
2️⃣ 고객 쿠폰 대량 발급처리
기존에 굉장히 오래 걸리던 작업이었습니다. 엑셀로 한땀한땀 작업해주시던 내역을
멤버 등급별로 자동 발급처리되도록 개선되었습니다.
이건 추후에 좀 더 자세히 다루도록 하겠습니다.
마치며
글 재간이 없어서, 이리저리 작성된 느낌입니다.
앞으로 개인적으로라도, 글로 남기는 습관을 들여야 겠네요. 😄
백엔드는 우아한 백조의 숨겨진 발길질입니다. 🦢
다음엔 또 다른 주제로 찾아뵙겠습니다~
