[우아콘2020] 배달의민족 마이크로서비스 여행기 - 김영한

https://www.youtube.com/watch?v=BnS6343GTkY 

 

김영한 님의 우아콘 2020 발표 배달의민족 마이크로 서비스 여행기에 대한 내용을 요약한 글입니다.

 

 

배달의 민족 서비스의 역사

주문수가 년 평균 2.3배씩 증가

 

2015년도

하루 주문 수 5만건 이하

MS SQL + PHP, ASP

대부분 스토어드 프로시저 방식 사용 (SQL문법의 함수와 같은 느낌, 여러 SQL문을 하나의 요청으로 묶음)

루비 DB 장애 시 전체 서비스 장애

 

레거시 개선을 위해 빅뱅을 생각하였으나 테이블 700개 스토어드 프로시저 4000건 정도로 방대한 모놀리틱이었습니다.

 

2016년도

하루 주문수 10만 돌파

PHP -> Java

마이크로 서비스 도전 시작

결제, 주문중계 독립

IDC -> AWS 클라우드 인프라로 이전 시작

 

기술적인 선택보다는 생존을 위해 MSA를 선택

 

결제가 죽더라도 전화로라도 주문을 할 수 있도록 결제를 떼어냄

주문중계 : 사장님이 앱, 단말, PC로 주문현황을 받을 수 있는 서비스

 

치킨 디도스

DAY1

프런트 서버 -> 주문 -> 결제 프로레스를 거쳐야 함.

예상보다 너무 많은 트래픽이 들어와 프런트 서버가 죽어버림

 

DAY2

프론트 서버를 AWS로 이관하여 100대 증설

이제는 주문 서버가 죽어버림

 

DAY3

주문 서버로 AWS로 이관하여 100대 증설

이번에는 성공했나 싶었지만 결제를 대행해주는 외부 PG사, 카드사들이 죽어버림

 

DAY4

외부 PG, 카드사 2배 장비 투입으로 이벤트 성공

 

2017년도

하루 주문수 20만 돌파

대 장애의 시대

시스템이 장애 나면 사장님들의 하루의 장사가 망하게 됨

 

가게 목록 + 검색 (Elasatic Serach로 떼어냄)

 

2018년도

전사 1순위 과제: 시스템 안전성

 

1인 1 광고 -> 1인 N 광고 계획을 가지고 있었음(회사 매출에 도움이 되는 프로젝트)

 

이 프로젝트를 폭파하고 장애 대응 TF 창설

 

1~5분 주기로 배치를 돌려 루비 DB를 AWS 다이나모 DB로 데이터를 퍼올립니다.

 

레거시 3 대장

- 주문 : 데이터 지분 1위, 하루 100만 데이터

- 가게/업주 : 시스템 연관도 1위

- 광고 : 프로시저 1위

 

 

주문 시스템

주문 -> 사장님 접수 -> 라이더스 -> 레거시 DB 싱크 -> 리뷰 시스템 전달(주문이 완료되면)

이렇게 되면 리뷰 시스템이 장애가 되면 주문 시스템에 에러가 발생

 

주문을 이벤트 기반으로 하기로 결정

전사적으로 명확하게 이해할 수 있는 이벤트를 정의하여 발행

 

따라서 레거시 DB, 라이더스 시스템, 리뷰 시스템이 주문 시스템을 consume 해서 사용합니다.

 

 

남은 레거시 2 대장

가게와 광고는 1:1 관계 , 가게 테이블 안에 광고 데이터가 들어가 있음 , 칼럼이 100개

배민의 역사를 함께한 레거시

 

광고를 손대려면 가게를 손대야 함 -> 전체 시스템에 영향

가게에 손대려면 광고에 손대야함 -> 전체 시스템에 영향

 

프로젝트 먼데이

3~4달 동안 개발팀이 프로젝트 안정성에 집중하며 광고 1:N 구축

- 회사 입장에서는 1:N 관계를 도입할 수 있게 됨

- 개발자 입장에서는 프로젝트의 안정성에 집중함

 

 

CQRS 모델을 활용하여 가게 상세 -> 가게 노출로 분리

 

 

API 조회 형식으로 서비스를 구성하면 간단하다

 

하지만 이렇게 되면 장애가 전파된다 (광고 시스템에 장애가 생기면 광고 시스템을 호출하는 모든 시스템이 연쇄적으로 장애 발생)

 

또한 이벤트 시 대량의 트래픽이 순간적으로 몰려오면 연관된 모든 시스템에 트래픽이 전파됩니다.

사실 광고 같은 서비스는 대량의 트래픽 처리보다는 정확도가 중요합니다.

 

먼데이 아키텍처 고려사항

- 성능

메인, 가게 리스트, 가게 상세 API는 초당 15,000회 호출

모든 시스템이 대용량 트래픽을 감당하기 어려움

 

- 장애 격리

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

 

- 데이터 싱크

MSA로 인하여 데이터가 분산되어 있음

 

배민 서비스 전체를 CQRS로 구성하기

광고, 가게/업주를 Command 사이드에 배치합니다.

 

광고 리스팅, 가게 노출, 검색 등을 Query 사이드에 배치합니다.

 

1. 전체 어드민 또는 사장님 사이트에서 데이터 변경이 일어납니다.

2. Command 사이드에서 DB 변경이 발생하고 변경 이벤트를 조회 사이드로 넘깁니다.

3. 조회 사이드는 이벤트를 consume 합니다.

 

이벤트 전파와 동기화

최종적 일관성 - 데이터는 언젠가는 다 맞추어진다 (늦어도 싱크는 1~3초 정도 소요)

문제 발생 시 해당 시스템이 이벤트만 재발행

Zero-PayLoad 방식 - 이벤트에 식별자(가게 id)와 최소한의 정보만 발행

 

장애 격리

- 각 시스템이 내부에 필요한 데이터 보관

- 내부 서비스의 모든 변경 내역이 이벤트로 저장

- 장애 시 데이터 싱크가 늦어져도 고객 서비스 가능

 

데이터 싱크 과정에 장애가 발생하는 경우

- 이벤트 재발행

- 큐 장애 발생 시(빈도수는 적음) : 전체 API에 대해 싱크를 맞추거나 배치로 N분간 발생한 업데이트 데이터를 제공하여 데이터 싱크를 맞춤

 

기타

- 적극적인 캐시 사용

- 비동기 Non-Blocking 시스템 적용

- 서킷 브레이커