대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략 엿보기 - 1. About Core Serving Layer

쿠팡의 대규모 트래픽을 다루는 백엔드 전략 정리 첫 번째 챕터, 쿠팡의 현재 상황 및 대용량 트래픽을 처리하는 최전선인 Core Serving Platform의 역할에 대해 다룬다.

 

먼저 쿠팡이 직면한 트래픽이 어느 정도인지, 어떤 것들을 특히 신경써야 하는지 알아보자.

 

 

쿠팡의 상황

---

쿠팡의 백엔드 시스템이 다뤄야하는 상황은 크게 두 가지: 높은 성장세와 확장세, 다양하고 복잡한 E-commerce 데이터로 나눌 수 있다. 이 요인들은 쿠팡이 다른 플랫폼들과 다르게 특화되어 발달한 특징들이 존재하게 됐기 때문에, 각각이 무엇을 의미하는지 이해하는 것은 앞으로의 대처를 이해하는데 큰 도움이 된다.

 

---

 

1. 높은 성장세 및 확장세

쿠팡은 2020년 당시 2018년도와 비교했을 때 4배 이상 성장했다.

쿠팡의 성장세. Reveal2021 참조

 

매 분기 꾸준하게 성장세가 증가하고 있으며, 이에 따라 유입되는 트래픽또한 당연하게 증가하고 있다. 뿐만 아니라, 로켓 배송이나 로켓 프레시, 쿠팡 이츠 등 다양한 비즈니스와 서비스가 계속해서 확장되고 있다.

 

즉, 쿠팡의 경우 꾸준히 성장하고, 해당 서비스와 연관지어 새로운 서비스를 계속해서 만들 것이 확정된 상황이다.

 

 

2. 다양하고 복잡한 E-commerce 데이터

다른 도메인과 비교해도, E-commerce 데이터 및 비즈니스 로직은 다양하고 복잡하다. 특히 쿠팡은 상품의 구입, 집배송 등 온라인 상거래 전반에 걸친 서비스에 관여한다. 또한, 이를 로켓 배송, 로켓 프레시와 같은 빠른 배송 서비스를 제공한다. 마지막으로 쿠팡은 이런 상품과 관련된 다양한 데이터들을 MSA 형태로 관리한다.

 

각 데이터를 다루는 Micro Service들 예시

 

다시 말하자면, 각 Micro Service 별로 취급하는 데이터의 성격이 달라진다. 또한, 이런 데이터들이 실시간으로 변하기도 하는데, 예를 들어 판매자 측에서 코로나 확진자가 발생하는 경우 해당 판매자가 다루는 모든 상품의 재고 정보와 도착 보장 정보를 실시간으로 (정말 초단위로) 변경해줘야 한다.

 

---

 

고객페이지에서 각각의 데이터를 각각의 도메인에 요청해서 호출하고자 한다면, 각각의 백엔드 시스템은 굉장한 높은 수준의 고가용성 및 성능을 보장해야 할 것이며, 공통적으로 적용되어야하는 비즈니스 로직들은 중복코드로 여기저기에 남게될 것이다.

 

이를 효율적으로 처리하고, 중복 코드를 방지하기 위해서는 모든 페이지에서 공통으로 사용되는 데이터와 비즈니스 로직을 처리하는 Micro Service가 필요한 것이다.

 

쿠팡에서는 이 Micro Service를 Core Serving Layer라고 부른다.

 

 

쿠팡의 Core Serving Layer

---

Core Serving Layer는 Coupang의 모든 페이지에 데이터를 Serving하는 역할을 담당한다. 또한, 쿠팡에서 의도적으로 Single-point failure를 만든 micro service이다.

 

 

Core Serving Layer의 목표

고객으로부터 발생하는 대부분의 이벤트는 Read이기 때문에, Core Serving Layer는 모든 페이지에서 사용되어야 하는 공통의 Busniess Logic과 요청된 Read 데이터를 제공한다. 이를 고성능으로 제공하기 위해서 신경 쓴 3가지 요인들이 있는데, High Availability, High Thoughput, Low latency이다.

 

1. High availability
장애 없이 99.99%의 높은 가용성을 제공하는 것을 말한다. 장애 발생시 최소한의 시간 내에 복구되어야 함을 의미한다.

2. High Thoughput
높은 Read Traffic을 감당할 수 있어야한다. 또한, 실시간 변경에 따라 데이터의 일관성 및 최신성을 보장해주어야 한다.

3. Low latency
여러 도메인 데이터를 모아서 제공하며, 실시간 변경에 따른 데이터 일관성 및 최신성을 보장해야 한다.

 

위 3가지 요인들은 대용량 트래픽을 처리하기 위한 3가지 필수 조건으로써 많이 언급되기 때문에 기억해두는 것이 좋다. 어쨌든, 쿠팡에서 User 페이지에 데이터를 서빙하는 Core Serving Layer가 목표로 하고 있는 성능 지표들은 위와 같았다. 그렇다면 이를 달성하기 위해서 Core Serving Layer가 어떤 모습을 하고 있는지 알아보자.

 

Core Serving Layer의 구조

Core Serving Layer 및 데이터를 보관하는 Unified NoSQL Data Storage, 각 도메인들의 Event Queue 등 다양한 컴포넌트를 확인할 수 있다.

 

앞서 언급했듯, Core Serving Layer는 모든 페이지에서 호출하는 하나의 Micro Service로써 떠있다. 이 Micro Service는 모든 페이지에 필요한 데이터와 비즈니스 로직을 Serving한다.

 

쿠팡의 Core Serving Layer를 이루는 기본 컴포넌트는 Queue, Common Storage, Common Serving Layer로 이루어진다. 각각에 대해서 살펴보자.

 

Queue, Common Storage

그렇다고 해서 Core Serving Layer가 사용자가 요청한 데이터를 분석해서 이를 각 도메인에 요청한다면, 앞서 언급했던 것과 같이 엄청난 고성능으로 구축해야 할 것이다. (다를 게 없다.) 때문에 쿠팡에서는 Core Serving Layer가 각각의 도메인을 인지하기보다는, 각각의 도메인이 데이터가 변경될 때마다 Queue에 보내고, 해당 데이터를 NoSQL Storage에 저장한다.

 

하나의 상품 정보가 있다면, 해당 정보를 이루는 각각의 field는 서로 다른 도메인들에서 채우게 되는 것이다. 아래의 예시처럼 하나의 비정규화된 거대 테이블에 저장하는 것이다. 

 

하나의 비정규화된 거대 테이블의 예시. 각 도메인은 자신이 담당하는 Field의 데이터만을 채운다.

 

결국 RDBMS를 사용하게 되면 Transaction이라는 무거운 작업을 통해 데이터의 CRUD가 이루어져야 하는데, 이런 제한점을 극복하고자 NoSQL DB를 사용한다. 이렇게 NoSQL 데이터베이스를 사용함으로서 Transaction 없이 언젠가는 반영되는 Eventual Consistency 모델을 사용하고, 한 번의 Read로 모든 도메인의 데이터를 가져갈 수 있도록 구조화한 것이다.

 

이때 Eventual Consistency란 언젠가는 동기화가 되어 수정이 반영된 데이터를 언젠간 볼 수 있음을 보장해주는 모델이다. 모든 읽기 작업은 결국엔 마지막으로 업데이트된 값(가장 최신의 값)을 반환하는 것을 보장한다. 고성능, 고가용성이 필요한 시스템에서는 좋은 선택지가 될 수 있다.

 

이렇게 Unified 된 Data Storage를 통해 여러 도메인으로의 I/O 작업을 줄일 수 있고, Common Storage를 사용함으로써 높은 Throughput을 달성할 수 있게 되는 것이다.

 

Common Serving Layer

Common Serving Layer는 이렇게 저장된 데이터를 읽어온다. 다만, 해당 과정에서 더 많은 Read Traffic을 처리하기 위해 Cache Layer가 추가로 적용된다. Cache Layer에 대해서는 다음 포스팅에서 다룬다.

 

 

Reference

---

영상:

https://www.youtube.com/watch?v=qzHjK1-07fI 

칼럼:

https://medium.com/coupang-engineering/대용량-트래픽-처리를-위한-쿠팡의-백엔드-전략

대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략