우아콘 2020 배민 마이크로서비스 여행기

김영한님

배달의 민족 서비스의 주문수는 년 평균 2.3배 증가하였다.

2015년

하루 주문수 5만이하
MS SQL + PHP, ASP
대부분 루비DB(MS SQL) 스토어드 프로시저 방식 사용
루비 DB장애시 전체 서비스 장애

스토어드 프로시저(SP, Stored Procedure)란

일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합.

데이터베이스에 대한 일련의 작업을 정리한 절차를 관계형 데이터베이스 관리 시스템에 저장한(지속성) 것으로, 영구저장모듈(Persistent Storage Module)이라고도 불린다.

최종적으로 테이블이 700이상, 스토어드 프로시저 4000개 이상 존재 => 거대한 모놀리틱 시스템

루비DB는 굉장히 고스펙이었다. CPU모니터링 화면을 켜면 모니터링 화면이 다 안들어올정도..

한 테이블에서 장애가 생기면 모두 영향을 미치며 장애가 전파되는 현상 발생

2016년

하루 주문수 10만 돌파
언어는 PHP -> 자바
마이크로서비스 도전
결제, 주문중계 독립
IDC -> AWS 클라우드 인프라로 이전시작

치킨 디도스

선착순 결제 할인 이벤트 -> 치도스
선착순 1000명 치킨 7000원 할인

DAY 1

IDC -> AWS로 이전하는 계획이 원래는 1달이었지만, 하루만에 프론트 서버를 AWS로 교체

DAY 2

이번에는 주문 서버가 죽어버려서, 새벽에 AWS로 교체

DAY 3

외부 PG사 장애

DAY 4

PG사 / 카드사의 장비 증설로 성공

2017년

하루 주문수 20만 돌파
대 장애의 시대
메뉴, 정산, 가게 목록 시스템 독립

2018년 상반기

전사 1순위 과제 : 시스템 안전성
쿠폰, 포인트 탈 루비DB
오프라인 모드 적용

2018 하반기

주문 탈루비
리뷰 탈루비

레거시 3대장

주문

데이터 지분 1위
하루 100만 데이터

가게/업주

시스템 연관도 1위

프로시저 사용 1위

주문시스템과 연관되어있는 리뷰 시스템 전달, 레거시DB 싱크, 라이더시 시스템 이 셋중 하나만 터져도 주문시스템에도 영향을 끼친다.

그래서 주문시스템 부분을 이벤트기반으로 주문의 라이프라이클을 정의하자 -> 이벤트 기반 마이크로소프트아키텍처 구조. AWS SNS와 SQS를 사용해서 구현.

프로젝트 먼데이

서비스 조회용 가게 데이터를 가지고있는 쿼리모델이 가게노출 시스템.

먼데이 아키텍처 고려사항

성능

대용량 트래픽 대응
메인, 가게 리스트, 가게 상세 API는 초당 15000회 호출

장애 격리

가게, 광고 같은 내부 서비스나 DB에 장애가 발생해도
고객 서비스를 유지하고 주문도 가능해야함

데이터 동기화

데이터가 분산되어있음

해결방안 : CQRS 아키텍처

이벤트 전파와 동기화

Eventually Consistency(최종적 일관성)
데이터는 언젠가는 다 맞추어 진다.
데이터 싱크 1초~3초
문제 발생 시 해당 시스템이 이벤트만 재발행
대부분 Zero-Payload 방식 사용
- 이번트에 식별자와 최소한의 정보만 발행
- 이벤트를 받은 시점에 조회 API로 필요한 데이터를 조회해서 저장

우아콘2020 배달의민족 마이크로서비스 여행기