우아한테크콘서트에서 본 역사...?

우선 우아한테크콘서트를 보면서 느낀거는

 

 배민이 시스템을 개발하면서 정말 고민을 많이하고 노력을 많이 한게 보였다.

현재 1년차인 내가 봤을 때 우리 회사에서 이렇게 한다면 따라갈 수 있을까?

그런 생각들이 들게하는 콘서트였다.

 한편으로는 저러한 생각들을 하고 실천할 수 있는 환경이랄까 그런게 부러웠고

살면서 저런 기업에서 한번쯤 일해보고 싶다는 동기부여가 된듯하다.

 

 

 

1. 온프레미스 -> 클라우드 마이그레이션
- 라이브시스템 뿐만 아니라 erp까지 마이그레이션함

- 우아한형제들의 경우 막대한 트래픽이 특정 시간대(점심, 저녁)에
  집중되어 있음. 그날 그 시점에 장애가 발생하면 업주, 라이더, 고객까지
  각자의 이해관계가 엇갈리며 피해를 보게됨.
  이러한 주문 한 건이 완료되기까지 만만치 않음.

2. 배민 마이크로서비스 구축
- 2015년도에는 하루 주문건이 5만 이하였음
   MS SQL(스토어드 프로시저 방식 사용), PHP, ASP 가 주력이였음
   DB 장애시 전체 서비스 마비됨.
   테이블은 약 700개, 프로시저가 4000개 정도...

- 2016년 주문건수 10만건 돌파함
  PHP -> 자바 전환, MSA 시작, AWS 마이그레이션 시작
  (넷플릭스 또한 생존의 문제로 MSA, 클라우드로 넘어감)

- 선착순 이벤트 준비(1000명 치킨 할인이벤트)
   프론트서버가 죽어버림. 밤샘해서 aws로 마이그레이션함
   다음날 주문서버가 죽어서 또 밤샘해서 aws로 마이그레이션함
   다음날 결제까지 되었는데 PG사가 죽어버림.(장비 늘림)

- 2017년 하루 주문 20만건 이상. 장애가 정말 많이 남.
  배민 서버가 터짐 -> 요기요로 고객 넘어가서 요기요 터짐
  -> 똑같이 배달통 터짐 -> 고객, 업자 전부 피해
  가게 목록과 검색을 엘라스틱 서치로 바꿈

- 2018 전사 1순위 시스템 안정
  가게 상세를 AWS 다이나모DB를 활용(MS DB에서 1~5분간격으로 배치돌려서 넣어줌)
  순차적 기능별 독립(주문) 시킴
  주문 파트 MS DB -> AWS RDB로 전환(라이더스 + 기존 배민 통합함)
  주문 이벤트 기반 아키텍처 구성 - 어떤 파트가 죽어도 회복이 빠름
  (주문 시스템 -> AWS SNS -> AWS SQS -> 시스템 -> DB)

- CQRS 아키텍처 전환 결정(Command and Query Responsibility Segregation)
  ( 핵심 비즈니스 명령-Command 시스템과
   조회(Query) 중심의 사용자 서비스
   둘을 철저하게 분리)

- 장애 격리
  각 시스템이 내부에 필요한 데이터 보관
  내부 서비스(광고, 검색)의 모든 변경 내역이 이벤트로 전달
  장애시 데이터 싱크가 늦어져도 고객 서비스 가능

- 서비스 자체 데이터 저장소와 동기화
  가게/업주는 RDB, 광고는 엘라스틱서치, 가게노출은 다이나모DB, redis로 해서 이벤트 기반으로 동기화

- 2019 MS DB -> 타 DB 전환 완료