올리브영은 데이터를 주고 받을 때 어떤 기술을 사용할까요?

안녕하세요 올리브영 배송 및 물류 스쿼드에서 백엔드 개발을 담당하고 있는 맹곰이입니다.

올리브영에서는 여러분이 상품을 구경하고 주문 및 결제, 배송하는 과정에서 온라인몰, 오프라인 매장, 결제 시스템, 물류 시스템 등 여러 시스템들이 다양한 데이터를 주고 받고 있어요.

이 중 최근에 온라인몰과 물류센터와의 데이터를 주고 받는 시스템을 리뉴얼 했는데요. 이번 포스팅에서는 리뉴얼 전후로 사용한 데이터 전송방식에 대해 소개하고자 합니다. 먼저, 여러분이 온라인몰에서 상품을 주문하고 집 앞까지 배송이 되기까지의 과정을 한 번 살펴봅시다.

배송 프로세스는 구매한 상품 정보, 배송지 정보 등을 전송하여 출하를 지시하는 출하지시, 박스에 상품 포장이 완료되어 출하가 확정된 출하확정, 물류센터에서 상품이 출발한 출고완료, 상품이 집 앞에 도착하는 배송완료의 과정을 통해 여러분의 집 앞까지 도착을 하게 되는데요. 오늘은 이 중에서 온라인몰과 물류센터 사이에 데이터를 어떻게 주고 받는지 소개해보도록 할게요.

우선, 데이터 전송 방식을 먼저 살펴보겠습니다.

데이터 전송 방식

데이터 전송 방식은 EAI I/F, API, MQ(Message Queue) 등 다양한 방법이 존재합니다. 이 중 위 3개만 아래에서 간단히 살펴보겠습니다.

EAI I/F

EAI는 Enterprise Application Integration의 약자로, 기업에서 여러 시스템을 하나의 EAI 어댑터를 사용하여 데이터를 주고 받도록 되어 있어, 개발 및 유지비용이 절감되는 장점이 있는 방식입니다. 다만, 하나의 EAI를 사용하기때문에 EAI에 장애가 발생하면 모든 시스템에 장애가 전파되는 단점도 있습니다. 여러 EAI I/F 중, DB와 배치를 사용하는 방식을 살펴보면 아래와 같습니다.

1. 전송하는 시스템은 송신테이블에 데이터를 추가한다.
2. EAI 어댑터가 수신테이블에 데이터를 복사하여 송신테이블로 전송한다.
3. 전송 받는 시스템 배치에서 주기적으로 DB 수신테이블을 조회하여 데이터를 가져온다.

API

API는 Application Programming Interface의 약자로, 정해진 규격을 바탕으로 클라이언트가 API 서버를 호출하여 데이터를 주고 받는 방식이며, 한 번 만들어놓은 API는 재사용이 가능하며, HTTP 표준을 사용하여 통신을 하기에 다양한 플랫폼, 언어간의 호환성이 제공되는 장점이 있습니다. 그러나 서버에 요청을 전송하고 응답을 받아야 하는 등의 이유로 비교적 느리다는 단점이 있습니다.

MQ

MQ는 Message Queue의 약자로, 데이터를 전송하는 시스템은 생산자로 메시지를 생산해서 큐에 전송하고, 전송 받는 시스템은 소비자로 MQ에 있는 메시지를 소비함으로서 데이터를 전송 받는 방식입니다. 데이터를 전송하는 시스템은 MQ에 메시지를 발행하고, 메시지를 전송받는 시스템의 응답은 기다리지 않기 때문에 데이터 전송이 빠른 장점이 있습니다. 하지만, 소비자의 응답을 기다리지 않으므로 양방향이 아닌 한방향 통신이며, 다양한 설정값을 이해하고 설정해야 해서 초기에 많은 시간이 필요하다는 단점이 있습니다.

이 중 기존에는 올리브영에서 물류센터와 통신 할 때는 EAI I/F를 사용하여 통신을 하고 있었는데요. 기존 시스템이 오래된 시스템이며, 배치를 사용하는 EAI I/F로 인한 지연 발생, 하나의 EAI 어댑터로 인하여 EAI에 장애가 발생 시 전체적인 통신이 멈추는 등의 이유로 시스템을 새로 구축 하기로 했습니다. 또한, 새로 만드는 시스템에서는 어떤 방식을 사용해서 통신할지를 결정해야 했는데요. 우선 요구사항은 아래와 같습니다.

1. 전송하는 즉시 받을 수 있는 실시간 전송이 가능한 시스템
2. 추후 주문량이 늘어나는 경우를 대비하여 현재의 최대치에 2~3배 더 많은 대용량 데이터 전송이 가능한 시스템
3. 다른 시스템에 장애가 발생해도 영향을 주지 않는 시스템

또한, 새로 만드는 시스템에는 실시간 전송이 가능하고, 추후 주문량이 늘어나는 경우를 대비해 더 많은 대용량 데이터 전송이 가능하고, 일방적으로 보내주는 데이터이기에 여기에 적합한 MQ를 사용하는 방식을 사용하기로 했습니다.

그럼 올리브영에서는 어떤 구조로 데이터를 주고 받는지 살펴볼까요? 배송 프로세스에는 많은 프로세스가 있지만 이 중 출하지시, 출하확정 프로세스를 기존 EAI I/F로 전송 했을 때랑, MQ로 전송할 때를 그림과 함께 살펴보겠습니다.

EAI I/F 구성도

1. 온라인몰은 주문한 상품 데이터를 출하지시 송신을 위해 출하지시 송신 테이블에 데이터를 추가한다.
2. EAI 어댑터가 출하지시 송신테이블에 있는 데이터를 출하지시 수신테이블로 복사한다.
3. 물류센터 시스템 배치에서 출하지시 수신 테이블에 있는 신규 데이터를 조회하여 상품을 출하한다.
4. 상품 포장이 완료되면, 물류센터 시스템에서 출하확정 송신 테이블에 데이터를 추가한다.
5. EAI 어댑터가 출하확정 송신테이블에 있는 데이터를 출하확정 수신테이블로 복사한다.
6. 온라인몰 시스템 배치에서 출하확정 수신 테이블에 있는 신규 데이터를 조회 한 후, 온라인몰 주문 데이터의 현재 상태를 변경한다.

MQ 구성도

1. 온라인몰은 주문한 상품 데이터를 출하지시 토픽에 메시지를 생산한다.
2. 물류센터 시스템에서 출하지시 토픽에 있는 메시지를 소비하여 상품을 출하한다.
3. 상품 포장이 완료되면, 물류센터 시스템에서 출하확정 토픽에 메시지를 생산한다.
4. 온라인몰에서 출하확정 토픽에 있는 메시지를 소비하여 온라인몰 주문 데이터의 현재 상태를 변경한다.

개선점

온라인몰은 빠른 배송이 무엇보다 중요한데요. 이를 위해서는 첫번째 단계인 출하지시를 빨리 전송해야 합니다. 이번 개선을 통해, 배치를 제거하고 MQ를 도입함으로서 출하지시 속도가 크게 개선 되었습니다.

기존에 사용한 EAI는 배치를 이용하여 주기적으로 배치가 실행되며 데이터를 가져오는 방식을 사용했습니다. 이로 인하여 지연이 존재했었습니다. EAI 주기와 물류센터에서 데이터를 조회하는 배치의 주기를 각각 5분이라고 가정하고 온라인몰에서 주문하고부터 물류센터에 출하지시가 내려갈 때까지 시간을 계산해봅시다. 11시 01분에 주문을 하면 11시 05분에 EAI가 데이터를 전송해주고, 11시 10분이 되서야 물류센터에서 데이터를 받을 수 있습니다. 이에 반해 MQ방식은 주문 즉시 데이터를 받으니 총 9분의 시간차이가 발생합니다. 하지만 MQ를 사용하면 주기로 인한 지연이 발생하지 않습니다.

추가로 기존 DB를 사용하는 EAI I/F에서 DB에 데이터를 삽입, 조회하는 시간보다 MQ에 메시지를 발행, 소비하는 시간은 큐를 사용하기 때문에 데이터가 이동하는 속도가 훨씬 빨라졌습니다.

또한 기존에는 모든 서비스가 같은 EAI를 사용하다보니, 여러 이유로 EAI에 장애가 발생하면 온라인몰과 물류센터간의 데이터를 주고 받는데에도 문제가 발생하는 의존성이 있었는데요. 이제는 더이상 EAI를 사용하지 않음으로서 EAI의존성을 분리해냈습니다.

성능비교

올리브영에서는 3달에 한번씩 가장 큰 행사인 올영세일이 진행되고 있습니다. 트래픽 또한 이 기간에 가장 많은데요. 그 중 6월, 9월 세일 마지막날인 6월6일, 9월5일에 시간대별 주문량을 가져와보았습니다. 아래의 시간대별 주문량 그래프를 보면 밤 12시를 갈 수록 주문량이 점점 늘어나고 12시에 주문량이 가장 많은 것을 볼 수 있습니다. 주문량이 많다는거는 그만큼 출하지시를 전송해야 하는 데이터도 많다는 것을 의미하는데요. 6월 올영세일과 9월 올영세일 때 주문량, 출하지시 전송량을 비교해보겠습니다. 아래 그래프를 보면 몇가지 특징이 보이는데요.

1. 6월과 9월에 주문량 및 주문량 추이는 비슷하게 보입니다.
2. 6월 출하지시 데이터는 비교적 여러 시간에 분산되어 분포되어 있고 변화량도 완만합니다.
3. 9월 출하지시 데이터는 특정 시간 (밤 12시)에만 튀는 현상이 보입니다.

위 3가지 특징으로 결론을 내려보겠습니다. 주문량이 가장 많은 밤 12시에 데이터를 보면 6월과 9월의 주문량은 비슷합니다. 9월 출하지시는 이 때 발생한 주문을 즉시 다 처리한 것으로 볼 수 있습니다. 다만 6월 세일에는 밤 12시에 발생한 주문을 즉시 처리하지 못하고 새벽 시간까지 천천히 처리되는 것을 볼 수 있습니다. 이것으로 보아, 기존 6월 출하지시(EAI I/F)보다 9월 출하지시(MQ)에 성능이 훨씬 개선되었다는 것을 확인했습니다.

마무리

이번 개편 이후 처음으로 대량의 데이터가 왔다 갔다 한 이벤트는 9월 올영세일이였는데요. 6월세일에 비해 속도가 크게 개선된 것을 눈으로 확인해 볼 수 있어 개선을 체감할 수 있는 좋은 기회였습니다. 또한, 추후에는 MQ 사용이 적합한 시스템은 MQ로의 전환도 예정되어 있습니다. 다만, 아쉬운 점은 무슨 서비스든 운영을 하다보면 이슈가 발생 할 수 있고, 확인이 필요할 때가 있는데요. MQ의 특성상 데이터를 큐에 저장하기때문에 데이터 검색에는 적합한 구조가 아닙니다. 그러다보니 검색에 적합한 DB보다는 검색하는데 제약조건도 많고 검색 시간이 오래 걸리는 현상은 어쩔 수 없는거 같아요.😢

다음번에는 또다른 기술을 소개하며 다시 찾아뵙겠습니다!!

감사합니다.