선착순 이벤트에 대한 기술적인 회고록

 

 

쇼핑몰에서 판매하는 상품을 ‘0’원에 뿌리는 이벤트로, 준비된 상품수에 맞추어 선착순으로 주문하는 이벤트였습니다.

 

당시 웹 서버를 담당하는 아키텍쳐 입니다. 회사에서는 모든 서비스가 AWS에서 돌아가는 환경이였습니다.

 

 

기존 서버 스택

• AWS 인스턴스 EC2 4대
• (2대 web 서버, 1대 db서버, 1대 Redis서버)

 

 

문제점

• 이벤트 시작과 동시에 서버 터짐
• db connection connection error
• 트랜잭션이 제대로 작동하지 않아 구매 가능한 상품보다 초과 구매가 된 상황
• CPU, Memory 만땅 (인스턴스 부족)

 

고민

 

위에서 발생한 문제점들을 하나하나 살펴보기 시작했습니다. 

1. DB 서버

• 현재 디비서버는 EC2에서 한대로 운영중이고 Master 한대로 운영중. Select 같은 query는 읽기전용 DB 에서도 충분히 커버가 가능한데,  읽기전용 DB가 구현되어 있지 않다.
• 그 중 AWS의 RDS를 사용하면 자동적으로 백업, Write/Replica 사용가능, 10배 이상 빨라지는 트랙잰션 속도 
• RDS로 옮기자!

2. 캐싱 서버

• DB connection 에러가 나다보니 자연스레 Redis의 의미가 무산되었다. (적절한 Update를 통해 redis도 갱신해야하는데, DB서버 자체가 죽어서 사용할 수 없는 문제상황)
• DB서버를 RDS로 옮겼으니, 현재 쓰고 있는 EC2의 서버를 Redis로만 활용하기보다는 따로 빼내서 Elastic Cache Service로 이용하고, 기존 EC2는 웹서버로 활용하도록 결정

3. 인스턴스 늘리기

• 기존에 동시접속자 수를 받아드릴 수 있는 Instance 자체도 부족
• 기존 Instance에서 Spot을 미리 띄우고 이벤트가 종료되면 Spot도 종료 될 수 있도록 결정  

 

업데이트 된 해결문제들

 

• Ec2에서 운영중인 Mysql을 AWS의 DMS를 통해 RDS로 옮겼습니다.
• 구매버튼 위치에 DB 락을 걸어서 중복구매를 방지합니다.
• Elastic Cache를 통해 Redis 본연의 기능을 수행 할 수 있도록 설정
• ec2 인스턴스 늘리기

 

결과

• 첫번째 이벤트에서 한방에 죽는 경험을 통해 급하게 바꾼 기술스택 입니다.
• 일주일 후 이벤트 다시 진행 결과는 대단히 만족스러웠습니다. 기존 web, db cpu 사용률이 현저히 감소 (안정적)되었고 들어온 순서에 맞게끔 상품이 순차적으로 구매가 되었습니다.