개발자가 바라본 중국 쇼핑 축제 쐉쓰이(광군제)

2017-11-14

2017년 1월부터 중국에서 일하기 시작했으니 알리바바가 운영하는 티몰(tmall.com)의 연중 최대 할인 행사인 광군제를 처음으로 중국에서 접했습니다. 단순 사용자가 아닌 tmall에서 어느 정도의 규모로 판매하고 있는 서비스의 운영 팀과 같이 일하는 입장에서 참여하였습니다. 멀리 한국에 있을 때 매체로만 접했던 세계적으로 유례없는 이 쇼핑 이벤트에 참여하면서, 이 행사를 준비하는 과정과 행사 당일 등을 지켜보면서 느낀 소감을 정리해 봤습니다.

alibaba_night

(필자의 베이징 숙소가 있는 왕징 지역에 있는 알리바바 건물, 11/11 되기 몇일전부터 조금을 등이 켜지더니 11/9일 밤부터는 완전체의 모습을 드러내고 있다.) ^[1]

쐉쓰이! 왜 열광하나?

중국의 개발팀에 처음 조인하는 순간부터 가장 많이 들은 말이 바로 쐉쓰이(双十一) 였습니다. 쐉(双)은 pair(쌍)을 의미하고, 쓰이(十一)는 11을 의미합니다. 즉 11/11일을 의미합니다. 이 행사가 처음 시작했을 때에는 솔로데이라고 해서 솔로들을 위한 쇼핑행사였는데 지금은 그냥 "쑤왕쓰이"가 더 많이 쓰이는 것 같습니다.

소비자 입장에서는 단순히 물건을 싸게 살 수 있으니 열광할 수 밖에 없습니다. 그러면 물건을 판매하는 유통업체나, 생산하는 제조 업체는 어떨까요? 딱 한마디로 하면 1년 매출의 50% 정도를 이날 하루에 판매가 일어납니다. 저도 처음에는 이게 정말이야! 라고 계속 의문을 가지고 있었는데 실제 눈앞에서 벌어 졌습니다.

1년 매출의 50%이 하루만에 일어나는데 어떻게 열광하지 않겠나!

소비자, 판매자(유통, 제조 업체), 플랫폼 제공자, 물류 등 이 행사에 참여하는 모든 참여자에게 혜택을 돌아가게 만든 것이 말그대로 대박을 만들어 낼 수 힘이 아니었나 생각해 봤습니다.

전국민이 즐기는 이벤트

중국 내에서 11/11 행사를 지켜보고 있으니 이 행사는 단순히 알리바바 티몰만의 행사가 아니라 전국민, 전체 유통 업체가 즐기는 커머스 대잔치 라는 것을 느낄 수 있었습니다. 2 ~ 3주전부터 엘리베이터 내에 있는 광고는 판에는 모두 11/11 이라는 숫자가 박혔습니다. 대부분의 광고는 티몰이 아닌 다른 쇼핑몰 등에서 진행하는 이벤트였습니다. 2위 사업자에 해당하는 jd.com은 11월이 시작하면서부터 11일 까지 계속해서 일자별로 이벤트를 펼치는 릴레이 이벤트를 진행했습니다. 이 기간 중에 징둥이 올린 매출이 21조라고 하니 11/11일 알리바바의 매출 27조와 큰 차이가 나지 않습니다.

dj_com

관련기사: 中광군제 매출 '알리바바·징둥' 합쳐 무려 50조원

이들뿐만 아니라 일상속에 들어와 있는 많은 생활 애플리케이션들도 이날을 위해 다양한 행사를 진행했습니다. 쿠폰을 주기도 하고, 알리페이 결재시 랜덤하게 구매 금액의 얼마를 할인해주기도 하는 등 11월이 시작되면서 수없이 많은 행사가 고객들에게 즐거움을 주고 있었습니다.

생중계에서 주는 짜릿함

한국에 있을때에는 애플의 신제품 소개를 보면서 제품 발표회를 저렇게 멋있게 할 수도 있구나. 전세계 소비자들을 기다리게 하는 힘이 정말 대단하다고 생각했었는데 알리바바의 쐉쓰이 행사는 전혀 다른 느낌의 새로운 행사였습니다. 몇시간 전부터인지는 모르겠지만 인터넷에서는 쐉쓰이를 축하하는 행사가 실시간으로 중계되고 있었습니다.

11_11_show_1

(축하쇼에서 "双11之歌, 11/11 노래" 를 부르고 있는 가수)

이 행사에는 가수, 해외 유명 운동선수, 영화배우, 중국내 유명 연예인 등이 대거 참석하였습니다. 이 무대에서 마원이 중국 배우들과 함께 촬영한 무술 영화를 상영하면서 행사 분위기를 한껏 올렸습니다.

11_11_show

(좌 니콜키드먼, 우 견자단)

이 생중계의 백미는 11/11일 시작을 알리는 카운트 다운이었습니다. 카운트다운이 끝남과 동시에 바로 매출 숫자가 전체 스크인에 나타나면서 순식간에 믿을 수 없는 숫자가 나오는데, 이 숫자가 레알이냐! 라는 감탄만 나왔습니다.

11_11_number

(카운트다운 바로 직후 숫자)

카운트다운 동영상

여기서 알리바바는 단순히 11/11 이벤트에 대한 내용이 아닌 자신들이 어떤 방향을 가지고 움직이고 있는지에 대한 내용도 자연스럽게 소개하고 있습니다. 즉 애플과 같이 별도의 제품 발표회가 아닌 엔터테인먼트 요소가 가득한 쇼와 함께 소개하고 있는 것입니다. 이를 시청하고 있는 많은 사람들은 즐거움 속에서 기꺼이 좋은 감정으로 새로운 제품, 전략에 대한 좋은 인상을 갖게 될 것입니다.

숫자로 주는 즐거움

사람들은 새로운 기록이라는 숫자에 대해 의미를 많이 부여하고 있습니다. 여기에 알리바바는 많은 흥미로운 숫자를 제시하면서 즐거움을 줍니다. 위 사진의 숫자 오른쪽에 보면 시간이 나오는데 2017.11.11 00:01:03 으로 되어 있습니다. 금액은 32억 위안, 원화로 5400억 정도입니다. 공식적으로는 오프닝과 함께 1분 50초만에 원화로 1조원을 넘었다고 합니다.

실제 위 숫자는 사전 예약 판매된 숫자를 보여줬을 가능성이 많습니다. 알리바바와 이 행사에 참여하는 유통업체들이 판매 제품 준비, 빠른 배송을 위한 선 배송 등을 위해 1주일 정도 전부터 사전 예약을 받고 있었습니다.

어쨋든 이런 어마무시한 숫자들이 이 행사에 참여하는 소비자들과 함께 공유함으로써 소비자들의 참여를 더 끌어 들이고 전세계 언론이나 이야기꾼들이 이야기를 만들어 퍼뜨리게 하는 요소가 아닐까 합니다.

모든 것이 이날을 하루를 위해!

11/11일을 준비하기 위해 몇달전, 아니 올해가 시작하면서 준비했다고 해도 과언이 아닙니다. 하루 하루 기능 개선되고, 운영되는 것은 이날을 위한 연습이고 준비였던 것입니다. 올해 초부터 준비해왔던 과정을 중에 몇가지 애피소드 몇가지 내용을 적어 봅니다.

6/18 징둥 행사는 예행연습

11/11일 이외에도 중국에는 매월 다양한 인터넷 쇼핑몰에서 행사를 진행합니다. 그중 가장 큰 행사중의 하나는 징동(jd.com) 에서 개최하는 6/18일 행사가 있습니다. 회사에 따라 다르겠지만 11/11대비 몇십% 정도 매출이 발생하는 큰 규모의 행사입니다.

시스템을 준비하는 입장에서 이 행사가 11/11 행사 준비를 위한 변곡점이 되었습니다. 작년 행사에는 현재의 시스템이 아닌 다른 시스템을 사용했고 올해부터 새로 만들어진 시스템으로 운영 중에 있었기 때문에 이 시스템이 실제 11/11 상황에서는 어떻게 동작할 것인지 전혀 예측할 수 없었습니다.

미리 돌 맞는 느낌으로 나름 준비해서 6/18일 행사에 돌입했습니다. 행사 오픈 후 몇십분 지난 시점에 DB 서버의 CPU가 100% 올라가고 있었습니다. 그때까지만 해도 저는 이 서비스보다는 다른 서비스쪽에 신경을 쓰고 있던 상황이라 시스템의 세부적인 내용까지 알지 못하는 상황에서 시스템 운영을 지원했습니다.

DB CPU 부하는 임시 방편으로 해결하고 나니, 이제는 디스크 부족 현상이 발생하였습니다. Docker를 사용하고 있는데 Docker container의 이미지, 웹 서버의 access log, 애플리케이션 서버의 개발자들의 생각없이 작성한 로그, Kafka message 큐 등등 다양한 파일들이 폭주하기 시작했습니다. 가장 중요한 Kafka 큐만 남기고 삭제해서 겨우 이 행사를 넘길 수 있었습니다.

행사 당일은 넘어 갔지만 정산도 만만한 작업이 아니었습니다. Alipay 인터페이스가 계속 에러를 발생시키면서 데이터를 주지 못했던 것입니다. 간간히 데이터를 받아 오지만 많은 경우 실패가 발생하였고 2 ~ 3일 지난 후에야 정상적으로 데이터를 받을 수 있었습니다.

쐉쓰이 준비

이렇게 정신없는 6/18 이벤트가 정리되고 나니 이제 11/11일을 위해 무엇을 준비해야 하는지 대충 감을 잡았습니다. 이제 남은 4개월 조금 더 남은 상황... 이후부터 작업한 내용을 대략 정리해보면 다음과 같습니다.

SQL 튜닝
- DB 서버 트레이싱 결과를 이용하여 성능이 느린 질의 지속적으로 튜닝
데이터베이스 서버 추가 및 분리
- 상품, 재고 등과 같은 기준 정보와 트렌젝션이 많은 주문/배송 정보를 다른 데이터베이스로 분리
- 애초에 마이크로 서비스로 구성되어 있어 분리하는데 아무런 어려움 없이 데이터 마이그레이션 후 DB 접속 URL만 변경하여 해결
MongoDB 튜닝
- MongoDB에 인덱스 잡히지 않은 컬럼 확인 후 생성
- 과도한 검색 조건으로 조회하는 질의 재 조정
Kafka 파티션 개선
- Async 처리를 위해 도입한 kafka의 파티션 정책 조정으로 Sequence 한 처리를 병렬 처리로 변경
모든 요청에 대한 로그를 기록하고 각 요청간의 호출 정보를 확인할 수 있는 연결 관계 구성
- 사실 이 부분은 아직 완전하게 구현은 안되어 있지만 당일날 몇가지 정보를 확인해서 위기를 넘어가는데 큰 도움이 되었음
성능 테스트 클러스터 구성 및 테스트 프로그램 개발
- 지속적인 튜닝에 대한 성능 결과를 확인하기 위해 별도의 클러스터에 운영과 유사한 테스트 환경 구성
- Async 처리 등으로 인해 단순 API call에 대한 성능 지표만으로는 전체 성능에 대한 수치를 확보하기 어려워 실제 시나리오와 비슷하게 실행할 수 있는 테스트 프로그램 개발
- 이를 통해 여러 장애 상황을 재현되어 미리 조치할 수 있었음

이외에도 제가 다 알지 못하는 많은 내용을 서비스 운영 팀에서 준비한 것 같습니다.

그날을 위해서라면 서비스 중지도 오케이!

이렇게 준비하는 과정에서 코드 리뷰 중에 이상한 내용의 코드가 리뷰 요청이 올라 왔습니다. 특정 일자, 시간에 시스템의 특정 기능(택배)을 Disable 시키는 코드였습니다. 코드 개발자에게 왜 이런 코드를 만들었는지 확인해보니 택배 회사가 실제 운영 환경에서 테스트를 그 시간대에 수행하기 때문에 그 시간 동안에 택배 요청 기능을 잠시 막아 두기 위한 코드라고 하였습니다. 물론 그 택배 회사는 현재 회사와는 다른 회사이며 아무런 관계가 없는 회사 입니다.

이런 상황이 허용되는 이유는 11/11을 위한 준비이기 때문에 어쩔수 없다. 또는 이렇게라도 해서 잘 준비해서 11/11일 안정적인 서비스를 운영하는 것이 더 좋이 않냐라는 서로간의 암묵적인 동의가 있었기 때문이 아닐까 생각해 보았습니다.

위 사례뿐만 아니라 프로그램 코드 여기저기에 11/11일을 위한 코드가 존재합니다. 보통은 이런 경우 환경설정이나 DB에 있는 설정 정보를 이용하도록 유도하는데 딱 하루만을 위한 로직이고, 내년 행사에는 또 바뀔 것이기 때문에 코드 리뷰시에 그냥 넘어가는 경우도 많습니다.

11_11_source_code02

D-Day

결전의 날. 제 화면에는 제플린^[2]으로 만든 4개의 그래프만 나타나는 노트북만 있었습니다. 이 노트북은 Kafka로 들어오는 Order의 각 상태 변화에 대한 Topic을 Producer와 Consumer 가 몇개씩 처리했는지를 나타내는 노트북입니다. 각 그래프에서 Producer가 작으면 앞 단계의 Consumer가 문제 있다는 의미이기 때문에 어디 단계에서 부하가 발생했는지 쉽게 파악할 수 있습니다.

11_11_zeppelin

오픈 즉시 문제 발생 및 해결

이벤트 오픈과 동시에 첫번째로 문제가 발생하였는데 구매 목록을 조회하는 첫화면부터 문제가 발생하였습니다. Log 확인을 해보니 특정 API의 성능이 과도하게 느린것을 파악해서 해당 프로그램에 대한 내용을 확인하고 문제가 MongoDB에 특정 컬럼의 인덱스가 빠진 것을 발견하고 바로 조치를 취했습니다. 문제가 된 이 컬럼은 11/11 몇일전에 추가 되었다고 합니다.

mongodb_11_11

(Alicloud의Managed MongoDB Service Dashboard 화면)

이 문제를 제외하고는 몇가지 간단한 문제는 대부분 쉽게 해결되었습니다.

이번에도 디스크 부족

디스크 부족 문제는 6/18에서 발생하였기 때문에 딱 필요한 정보만 저장하고자 했습니다. 다만 비용 등의 문제로 스토리지 증설은 하지 않았습니다. 하지만 이것 역시 1 ~ 2주일 전에 추가한 Docker log를 직접 HDFS에 저장하도록 한 기능에서 생각보다 많은 디스크를 사용하면서 문제가 발생하였습니다.

다행히 11/11에는 서비스가 문제 없이 잘 운영되었는데 11/12 새벽에 디스크 부족으로 Kafka 서버 중 한대에 장애가 발생하였습니다. 물론 Kafka 서버 자체가 이런 장애에 잘 동작하도록 설계되어 있기 때문에 실제 서비스에는 아무런 영향이 없었습니다. 다만 일부 Kafka 파티션 re-balancing 상황에 대비를 하지 않았던 프로그램(제가 만든 kafka-to-hdfs 입니다.) 에서 문제가 발생하여 재시작으로 해결했습니다.

1
2
3
4
17/11/11 16:26:57 INFO kafkahdfs.KafkaTopicRunner: Error occurred, but re-starting fetch kafka topic.
17/11/11 16:26:57 INFO kafkahdfs.KafkaTopicRunner: ==&gt; Rolling current log file. Saved records=105282, totalRecord=35100252
17/11/11 16:26:57 ERROR kafkahdfs.KafkaTopicRunner: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records.
org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records.

(로그 시간은 UTC)

매출 올라가는 소리

메신저로 매출 얼마 달성했다는 소리가 들려 오면서 실제 매출 관련 부서(상하이에 있음)에서는 특정 금액 도달 시마다 이벤트를 합니다. 보내온 동영상을 보니 1억 위안 달성할 때 꽹과리 치고 난리가 났습니다. 위챗 메신저 상에서도 홍바오(红包)^[3]라고 하는 기능을 이용하여 작은 돈이지만 랜덤하게 부서원들에게 돈을 보내기도 합니다. 이런 광경을 보면서 단순히 소비자만을 위한 축제가 아니라 참여하는 모든 인원이 즐기는 축제라는 느낌을 받았습니다.

서로 진화

앞에서 6/18일 행사에서 Alipay 데이터 인터페이스에 문제가 있었다고 했는데 외부 서비스라 어쩔수 없다고 생각했습니다. 11/11일 시작부터 지난 행사때와 다르게 안정적으로 데이터를 받아올 수 있었습니다. 그 서비스 개발팀도 6/18 이후로 계속 개선 작업을 진행한 것 같습니다. 이렇게 서로 모르는 개발팀이지만 서로 진화하고 발전해나가는 과정을 지켜볼 수도 있었습니다.

11_11_dbserver_cpu

(DB Server CPU)

쐉쓰이를 마치며...

이렇게 1년 남짓 서비스를 준비하면서 평소 트래픽이었으면 신경을 쓰지 않아도 되는 부분임에도 불구하고 다양한 기술과 시스템의 아키텍처를 진화시켜 나가면서 많은 준비를 했지만 불과 하루만에 순식간에 지나갔습니다. 약간은 싱겁게 끝나서 한편으로는 아쉽기는 했습니다.

다음 날 식사 중에 같이 준비한 개발자 한분이 이런 의미 심장한 말을 던졌습니다.

중국의 IT 서비스 기술은 쐉쓰이 때문에 발전하는 것 같다.

이 말을 듣는 순간 바로 떠오른 것은 한국의 서비스 환경이었습니다. 한국에서의 서비스 환경은 일부 몇개 서비스에 의해 사용자가 갇혀 있는 상황이지만, 중국에서는 티몰이나 위챗과 같이 시장을 지배하고 있더라도 여러 작은 서비스 또는 업체와 공존할 수 있는 길이 많이 열러 있다는 것에 차이가 있는 것 같습니다.

주석

[1] 알리바바 본사는 항저우에 있으며 북경 왕징에 있는 이 건물은 어떤 용도인지는 알지 못하지만 관련글을 찾아보니 제2의 본사라고한다. 이 건물은 주변 건물과 다르게 밤 늦도록 불이 항상 켜져 있는 건물이다.

[2] Zeppelin은 단순하지만 강력한 도구로 개발자, 분석가가 쉽게 데이터를 분석하게 할 수 있는 환경을 제공하는 오픈소스 솔루션이다.

[3] 홍바오는 온라인 새배돈과 비슷한 개념으로 특정 채팅 그룹 등에 정해진 금액을 랜덤하게 뿌릴 수 있다. 대상이 된 사용자는 해당 메시지를 클릭하면 랜덤한 금액이 당첨된다. 필자의 경우 3.5위완(600원 정도)를 받아보기도 했다.

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.