본문 바로가기

프로그래밍/우아한Tech

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

728x90
반응형

거대한 모놀리틱 서비스를 마이크로서비스로 이전한 지난 5년간의 여정을 공유합니다.

 

🎤 발표자 : 우아한형제들 김영한

----------------------------------------------------------------------------

2020년 12월 16일 우아한형제들의 첫번째 기술 이야기 우아한테크콘서트가 시작됩니다.

www.woowacon.com

 

대한민국 대표 푸드테크 기업으로 2016년 클라우드 전환을 시작한 이래 4년이라는 시간동안 200%의 성장을 한 우아한형제들의 배달의 민족 서비스!

 

지난 4년간 매우 빠른 속도로 성장하는 비즈니스를 뒷받침 하는동안 개발자들도 함께 성장했습니다. 우아한형제들의 지난 4년간의 성장을 담은 우아콘의 Opening 영상! 우아한형제들 4년간의 Cloud Journey 를 영상으로 함께해주세요.

 

해당 동영상을 보고 정리한 글입니다.

 

2015

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

2016

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

주문 중계 서비스

  • 가게 사장님이 앱으로도 PC로도 받을 수 있는 주문을 받을 수 있게 해주는 게이트웨이
  • 서비스 성장하면서 NODE JS 를 JAVA로 변경

치킨 디도스

  • 선착순 결제 할인 이벤트
  • DAY 1 : 프론트 서버 장애 => AWS 로 이전 100대 증설
  • DAY 2 : 주문 서버 장애 => AWS로 이전 100대 증설
  • DAY 3 : 외부 PG 장애 => 2배 장비 투입

2017

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

2018 상반기

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

 

2018 하반기

  • 주문 탈루비
  • 리뷰 탈루비

배민 라이더스 : 배달의 민족 전용 라이더

  • 배달의 민족과 비슷하게 새로 만듬
  • 나중에 시스템 통합

 

 

먼데이 아키텍처 고려사항

  • 성능
  • 장애 격리
  • 데이터 동기화

성능

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

장애격리

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

 

데이터 동기화

  • 데이터가 분산되어 있음

CQRS

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

이벤트 전파와 동기화

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

데이터 저장소

  • 조회(고성능)
  • ㄴ가게노출 : DynamoDB, MongDB(NoSQL), Redis(Cache)
  • ㄴ광고리스팅, 검색 : Elasticsearch(검색엔진)
  • ㄴ바로결제 라이브 : Redis(Cache)
  • 명령(안정성)
  • ㄴ광고 : 오로라DB(RDB)
  • ㄴ가게/업주 : 오로라DB(RDB)

장애 격리

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

데이터 싱크 장애 대응

  • 이벤트 재발행
  • 큐 장애 발생시
  • ㄴ전체 IMPORT API 제공
  • ㄴ부분 IMPORT API 제공
  • ㄴㄴ최근 업데이트 데이터를 분 단위로 부분 제공

기타

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

정리

  • 배달의민족 시스템은 거대한 CQRS
  • 성능이 주요한 외부 시스템과 비즈니스 명령이 많은 내부 시스템으로 분리
  • 이벤트 발행을 통한 Eventually Consistency(최종적 일관성)
  • 각 시스템의 API 또는 이벤트 방식으로 연동

 

728x90
반응형