안녕하세요. 쿠폰 스쿼드 포덕입니다.
이전 게시글에서는 고객분들의 많은 불편사항이었던 선착순 쿠폰의 개선에 대한 내용이었습니다.
그리고, 이전 작성글 말미에, 대량쿠폰도 같이 개선했다는 작은 문장이 있었습니다.
올리브영 쿠폰은 RabbitMq를 이용한 발급 시스템 구성을 하였고, Rabbit의 유연한 동작의 핵심인 Exchange 가운데에서도, Direct Exchange를 사용했습니다.
여기서 Exchange란?
RabbitMq는 Publish, Exchange, Route, Queue, Consume 에 의해 동작합니다.
Publish 는 메시지를 전송하고
Exchange 는 메시지를 수신하고
Route 는 특정 Routing Key를 가지고, binding된 Queue 를 찾아가서 메시지를 적재합니다.
그리고 적재된 메시지를 Consume을 통해, 처리할 수 있습니다.
여기서 RabbitMq는 Exchange라는 특징을 통해 다양한 처리방식을 지원합니다.
- Direct Exchange
특정 Exchange 키 값으로 메시지를 전송합니다. Exchange는 작성된 Routing Key에 binding된 Queue로 메시지를 적재합니다.
이 값은 Default Exchange 값에 해당합니다.
- Topic Exchange
특정 Exchange 키 값으로 메시지를 전송합니다. Exchange는 작성된 Routing Key에 binding된 Queue로 메시지를 적재합니다.
여기서 Direct방식과 다른 점은 Exchange의 키 값을 Pattern으로 작성 가능합니다.
해당 Pattern에 정확히 일치하거나, 포함되는 모든 곳에 메시지를 적재합니다.
- Fanout Exchange
특정 Exchange 키 값으로 메시지를 전송합니다. Routing Key에 상관없이 binding된 모든 Queue로 메시지를 적재합니다.
- Header Exchange
특정 Header 값과 함께 메시지를 전송합니다.
Routing Key에 상관없이, 전달받은 Header값이 binding시 지정된 값과 일치한다면, 메시지를 적재합니다.
- 이 가운데, 대량발급에서도 Direct Exchange가 사용되었으며, 이로 인해 발생했던 문제와 개선에 대해 다뤄보려 합니다.
도입 배경
올리브영에는 선착순 쿠폰만큼 중요한 쿠폰이 있습니다.
바로 멤버십 승급 쿠폰🫡 입니다.
올리브영은 굉장히 많은 고객님들께서 사용하고 계십니다.
예시로 가장 많은 BABY 등급만 해도 1천 만명 이상이 있으며,
해당 멤버십 등급의 고객님들에게 쿠폰을 발급하는 과정에서만, 12~15시간이 소요되고 있었습니다. (다른 등급까지 생각한다면..😱)
그리고 이러한 문제로 인해 다음과 같은 애로 사항이 발생했습니다.
-
백오피스는 대량 발급뿐만 아니라 다양한 기능을 수행하고 있습니다.
쿠폰 발급 외에도 다른 도메인과 관련된 내부 작업들이 진행되고 있습니다.
다만, 대량 발급 작업이 이루어지게 되면, 많은 리소스를 소모하여, 다른 업무에 영향을 줄 수 있습니다. -
백오피스에서 발급 과정이 장기화될 경우, 시스템 변경(예: 긴급 배포)이나 다른 작업의 영향을 받아 안정적인 사용에 불편이 발생할 수 있었습니다.
-
작업 시간이 과도하게 길어지면, 해당 업무의 진행을 기다리는 내부 인력의 리소스가 불필요하게 소모됩니다.
-
지나치게 긴 작업 시간으로 인해 승급과 쿠폰 발급 사이의 간격이 생길 수 있으며, 이는 쿠폰의 지연은 고객 경험에 부정적일 수 있습니다.
개선 필요사항
쿠폰 대량 발급 시스템은 구성원이 개별적으로 발급하기 어려운 상황을 해결하기 위해 만들어진 만큼, 발급 시작부터 종료까지 외부 요인의 영향을 받지 않고 안정적으로 운영되어야 합니다.
또한, 멤버십 승급과 연계된 작업이기 때문에, 고객이 쿠폰 발급과 승급 간의 시간 차이를 느끼지 않도록 신속한 처리가 중요합니다.
- 처리 방식의 변경
대량 발급은 올영세일의 선착순 발급에서도 사용하던 Direct exchange로 구성되어 있었습니다.
발급은 지정된 Queue에 적재되며, 발급도 concurrency를 통해 처리되고 있습니다.
물론 기다리면, 언젠가 처리는 되겠지만, 너무 장기간입니다.
작업량이 가령 1억 건이라면? (언젠가 되지 않을까요? 😎 )
낼 수 있는 최대의 성능을 내더라도, 병목이 발생할 수 밖에 없습니다.
가능한, 발급 대상 조회에서 pending되는 시간을 줄이고, 빠르게 발급하여,
작업시간을 단축할 필요가 있었습니다.
- 작업 주체의 변경
기존에 발급 대상을 조회하고 전송하던 역할을
백오피스에서 독립된 환경을 구성하고, 전송할 수 있어야 했습니다.
백오피스는 운영 상황에 따라, 긴급한 변경이나, 다른 작업에서 영향이 있을 수 있습니다.
그리고 이러한 변경은 대량 발급의 안정적 동작에 변수로 작용할 수 있습니다.
개선 진행
- 해당 프로세스를 정리해보겠습니다.
ASIS
- 먼저 백오피스에서 대량발급을 실행합니다.
- 내부적으로 대상을 조회하여, LOOP문을 통해 메시지를 전송합니다.
- 메시지가 적재된 Queue를 Consume하여, 발급합니다.
TOBE
- 이전과 동일하게, 실행은 백오피스에서 발생합니다.
- 백오피스는 Fanout Exchange를 호출합니다.
- 호출시, 전달한 메시지에 대량발급 ID값을 이용하여, Consume 할 때, 분기처리됩니다.
- Consume에서 대상을 조회하여, LOOP하여, 메시지를 전송합니다.
- 메시지가 적재된 Queue를 Consume하여, 발급합니다.
변경은 크게 2가지 정도입니다.
- Exchange 변경
먼저 Exchange를 Fanout으로 변경하였습니다.
기존의 지정된 Queue로의 적재가 아닌, Multi Queue로 적재됩니다.
그리고 Exchange에 바인딩되는 Multi Queue Name은 Task를 활용하여 생성되도록 하였습니다.
메시지에 대한 Consume 작업시, 동일 메시지에 대한 중복처리를 방지하기 위해,
대량 발급 ID값에 따라 별도로 분기되어 처리하도록 구성하였습니다.
- 작업 주체의 변경
기존에 발급 대상을 조회하고 전송하던 역할을 백오피스에서
Fanout Exchange를 받는 Trigger Worker구성을 별도로 하였습니다.
Trigger Worker는 전달받은 메시지에 따라, 대상을 조회하고 발급 Worker로 전달하여,
발급을 진행하게 됩니다.
이로써, 백오피스에서는 대량발급시 실행만 담당하게 되고,
실 대상 조회 및 발급은 별도의 시스템에서 진행하는 것으로, 동작의 안정성을 갖게 되었습니다.
결과
- 작업시간 단축
- 기존에 12~15시간 소요되던 작업 시간이 5~6시간으로 대폭 감소했습니다.
- 이를 통해 승급과 쿠폰 발급 간의 간격이 줄어들어, 고객 경험이 더욱 향상되었습니다.
- 안정적인 운영 환경 구축
- 기존 백오피스 시스템에서 독립적인 구조로 변경되어 작업을 수행할 수 있게 되었습니다.
- 대량 쿠폰 발급 작업의 안정성을 확보함과 동시에, 자원 사용량 및 운영 상황을 모니터링할 수 있는 환경을 보다 원활하게 구성되었습니다. 이 개선을 통해 시스템 효율성과 안정성을 모두 강화할 수 있었습니다.
이 개선을 통해 시스템 효율성과 안정성을 모두 강화할 수 있었습니다.
마치며
이번 글은 어쩌다보니 시리즈로 이어지게 된, 쿠폰 발급 개선 과정을 다룬 이야기였습니다.
개선 이후에도 지속적인 모니터링과 올리브영 고객들의 VoC(Voice of Customer)에 대한 빠른 대응을 통해 시스템의 안정성을 유지하기 위해 노력해왔습니다.
앞으로도 더욱 안정적이고 신뢰할 수 있는 올리브영 쿠폰을 제공하기 위해 최선을 다하겠습니다. 🫡🫡
