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

2015년

단일 서비스

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

프런트 서버, 회원/인증, 리뷰, 쿠폰, 포인트, 정산, 주문, 결제, 주문중계, 가게/업주,광고,메뉴
MS_SQL 데이터 베이스 사용중

리뷰가 장애나서 DB 과부하 시스템 다운,. 주문이 안됨. 리뷰가 장애나도 고객 주문 영향없어야함


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

자바 변환 이유??
대용량트래픽 안정적 제공
대용량 트래틱 처리한 자바 개발자 많음

마이크로서비스 기술적 문제가 아니라 생존의 문제였다.(7년걸림) -넷플릭스-

레거시 3대장
1. 주문 2. 가게/업주(시스템 연관도 1위)  3. 광고(프로시저 사용1위)

마이크로 서비스 결제 장애나면 전화주문 됨!!!!( 돈 관련은 클라우드 올릴 수 없다하여 IDC 사용함)

치킨 디도스 2016년 7월? 9월?
선착순 결제 할인 이벤트 ->치도스
선착순 1000명 치킨 7000원 할인
오후 5시 시작

프론트 서버->주문(IDC)->결제

프론트 서버 AWS 이전(100대증설) ->주문서버 AWS 이전 (100대 증설)
-> 결제 (외부 PG,카드사 ) 죽음..pg 카드사 장비 2대 늘림


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

가게목록+검색을 루비DB에서 때내서 엘라스틱 서치로 때냄


트래픽은 느는데 시스템은 레거씨. 확장못함. 


2018년 상반기
전사 1순위 과제: 시스템 안정성
N 광고 폭파->장애 대응 TF 창설
가게상세 재개발(주요 장애 포인트)
쿠폰, 포인트 탈루비
오프라인 모드 적용

2018상반기 신규 가게상세
화면->가게상세 java -> aws 다이나모 DB  <—루비 DB (배치 1분~5분주기)로 넣음
싱크가 늦고  요구사항 변경시 수천라인 쿼리 수정해야함


2018년 하반기 
주문 탈루비
리뷰 탈루비

메뉴,정산,결제,주문중계,포인트,쿠폰 —>주문
커머스시스템에서 주문이 제일 복잡함. 주문이 다 엮임.

레거시 3대장
주문(데이터 지분1위, 하루 100만 데이터..현재 수백만)
가게/업주(시스템 연관도 1위)
광고( 프로시스 사용1위. 4천개  $$$)


콘웨이의 법칙(Conway's law)
소프트웨어 구조는 개발 조직의 커뮤니케이션 구조를 닮는다.


주문의 생성접수,배달완료, 취소 라이프사이클동안 정말 a많은 api 호출했음

예전에는 큐가 아니라 api였음. 
리뷰 시스템도 장애시 주문시스템도 장애가 났음.


주문의 이벤트 기반의 라이프사이클 아키텍처를 만듬

주문의 이벤트
주문 생성,접수,배달완료, 취소!!!

주문시스템은 이벤트만 발행.필요한곳에서 가져다 사용
리뷰시스템, 레거시DB 싱크, 라이더스 시스템에서 consume해감
리뷰시스템 죽어도 주문에는 영향없다. 리뷰시스템 살아나면 다시 컨슘해감
새로운 시스템 나오면 구독해라라고 하면됨.


남은 레거시 2대장
가게/업주(시스템 연관도 1위)
광고( 프로시스 사용1위. 4천개  $$$)

가게 광고 1:1 서로 정보 너무 많이 얽혀있다
shop 테이블안에 광고 정보 있고

광고 손데도 가게 손데야되고  가게 손데야되도 광고 손데야되고
한개의 가게 광고여러개 가는구조가려면 시스템 먼저 안정화 되야한다


2018년 12월 먼데이 시작


msa api 식으로 개발시 광고시스템 장애시 그 광고시스템 호출한 모든 시스템에서 연쇄적으로 장애가 발생한다.

대량의 트래픽이 쓰나미 몰려오듯이 몰려온다. 그럼 트래픽이 모든 시스템에 다 퍼짐
그럼 가게노출이나 광고리스팅은 대용량 트래픽 맞게 설계할 수 있지만 광고나 가게/업주 시스템은 트래픽을 잘받는거보다 정확하고 안정적으로 시스템 운영하는게 더 중요함

먼데이 아키텍처 고려사항
성능, 장애 격리, 데이터 동기화


1.성능
대용량 트래픽 대응
메인,가게 리스트 ,가게상세 API는 초당 15,000회 호출
모든 시스템이 대용량 트래픽을 감당하기는 어려움


해결방안

CQRS
핵심 비지니스 명령(command) 시스템과
조회(Query) 중심의 사용자서비스 둘을 철저하게 분리
Command and Query Responsibility Segregation(CQRS)

조회(고객의 트래픽 들어오는거): 광고리스팅, 가게노출, 바로결제 라이브 ,검색( 카프카 컨슘)
명령: 광고, 가게/업주 (카프카 프로듀스)

가게 사장님이 가게명을 바꾸면  가게/업주서비스 내부 DB 바꾸고 프로듀스를 함
그럼 조회쪽에서 다 컨슘해서 가져감
 

시스템뿐만 아니라 조직도 분리함!



2. 장애 격리
가게,광고 같은(명령 Command) 내부 서비스나 DB에 장애가 발생해도 고객서비스를 유지하고(조회 query) 주문도 가능 해야함.

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

데이터 싱크 장애 대응
이벤트 재발행
큐 장애 발생시
 1) 전체 import api 제공
2) 부분 import api 제공
최근 업데이트 데이터를 분 단위로 부분 제공


기타
적극적인 캐시 사용
서킷 브레이커
 비동기 Non-blocking 시스템 적용
스프링 webFlux, Reator(RxJava 유사)
가게노출, 광고리스팅, 검색



3. 데이터 동기화
데이터가 분산되어 있음

이벤트 전파와 동기화
Eventually Consistency(최종적 일관성)
데이터는 언젠가는다 맞추어 진다. 데이터 싱크 1초~3초, 문제 발생시 해당 시스템이 이벤트만 재발행. 
대부분 Zero-Payload 방식 사용(순서 보장이 안되서)
이벤트에 식별자(ex 가게ID) 와 최소한의 정보만 발행
이벤트를 받은 시점에 조회 API로 필요한 데이터를 조회해서 저장
ex) 가게/업주 가게명 변경시 변경된 혹은 모든 데이터를 produce하는게 아니라 id만 던짐. 그럼 받는쪽에서 아! 몬가 변경됬구나 하면서 api를 호출해서 가져옴.
만약 변경된 데이터만 보내면 이벤트 순서를 고민해야함. 모든 데이터 담아서 보내기엔 양이 넘 많았다.



최소 데이터 보관의 원칙
polyglot 데이터 베이스: 서비스 자체 데이터 저장소와 동기화

조회(고성능)
가게노출:DynamoDB, MongoDB(NoSQL), Redis(Cache)
광고리스팅, 검색: Elasticsearch(검색엔진)
바로결제 라이브:Redis(Cache)

명령(안정성)
광고: 오로라DB(RDB)
가게/업주: 오로라DB(RDB)

마이크로서비스 ??
규모의 경제가 되야해야한다
1.시스템 규모 2.트래픽 3. 사람도 많아야함