일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 우아콘
- auth method
- gitlab-ctl
- 명령어 대체
- hashicorp
- Approval Test
- KMS
- 멱등성
- 샤미르
- JSR-330
- 하만카돈 #오라 #스튜디오 #2 #harman #kardon #aura #studio #fix #repair #수리 #shutdown #bluetooth
- Session invalidate
- shanta #bahadur
- InheritableThreadLocal
- MSA
- Shamir
- approle
- json.tool
- CQRS
- Vault
- AWS SNS
- external_url
- RequestFacade
- gitlab.rb
- 제어역전
- WooWaCon
- backtick
- AWS SQS
- secretid
- Unseal
- Today
- Total
인생은 여행
우아콘2020 - 배달의민족 마이크로서비스 여행기 본문
www.woowacon.com
2020 우아한테크콘서트 2020.12.16 ~ 18
배달의민족 마이크로서비스 여행기(김영한)
배달의민족의 급격한 성장
매년 2.3배 주문 증가
MSA 전환은 단순한 유행 기술이 아니라 생존의 문제였음
2015년 상황
하루 주문수 5만 이하
모노리딕 구조 - MS SQL + PHP, ASP
MS SQL Stored Procedure 방식 사용
2016년
하루 주문수 10만 돌파
루비라는 이름의 거대 MS SQL 레거시
PHP -> Java 전환 결정(대용량 트래픽 수용, 개발자 풀)
마이크로서비스 도전 시작
결제, 주문중계 독립
IDC -> AWS 클라우드 인프라로 이전 시작
결제 서비스 독립, 마리아DB 사용, 아직은 IDC 내
주문중계 서비스
- 주문건 G/W 서비스
처음은 node.js 였으나 나중에 Java로 전환
2016년 치킨 디도스 에피소드
프론트서버 - 주문 - 결제
1일째 프론트서버 장애로 실패 --> AWS 로 프론트서버 이전
2일째 주문서버 장애로 실패 --> AWS 로 주문서버 이전
3일째 외부 PG사 장애 --> PG사 서버 확충
4일째 성공
2017년
하루 주문수 20만 돌파
대 장애의 시대
메뉴, 정산, 가게목록 시스템 독립
장애 발생하면 전국민의 역적이 됨
2018년 상반기
전사 1순위 과제: 시스템 안정성
시급한 캐시카우 N 광고 프로젝트 폭파 -> 장애대응 TF 창설
가게상세 재개발(주요 장애 포인트)
쿠폰, 포인트 탈 루비(MSA 화)
오프라인 모드 적용
가게상세(프론트서버) PHP -> 자바 전환
AWS 다이나모 DB에 배치로 메인 DB와 동기화
2018년 하반기
주문 탈 루비
레거시 3대장
주문: 데이터 지분 1위, 하루 100만 건 발생
가게/업주: 시스템 연관도 1위 - 모든 시스템과 얽혀있음
광고: 프로시저 사용 1위, 캐시카우
주문
콘웨이의 법칙; 조직과 시스템은 닮는다
주문서비스는 e커머스 시스템에서 가장 상관관계가 복잡
새로 데이터베이스 설계
기존에 API를 직접 호출하던 것을 이벤트 기반으로 변경
주문시스템 --> AWS SNS --> 각 시스템의 AWS SQS <-- 각 시스템 구독
직접적인 연관관계 제거, 장애 회복력 상승, 시스템 확장 용이
가게/업주 : 광고
너무 복잡, 1:1 관계
프로젝트먼데이 출범(그냥 시작하는 날이 월요일이였음)
먼데이아키텍처
- 장애 격리: 단순한 API 호출 구조는 장애 전파될 수 있음
- 성능: 고성능 조회가 발생하면 모든 시스템으로 트래픽이 전파되는 경향이 있음
- 데이터 동기화 고민 필요
CQRS
핵심 비즈니스 명령(Command) 시스템과 조회(Query) 서비스를 철저히 분리
이벤트 기반으로 AWS SNS - AWS SQS 서비스 사용
Eventually Consistency(최종적 일관성) 모델
동기화 delay 1~3초
Zero Payload 방식 - 이벤트에는 키 값만 전송하고 수신자가 발신자 API를 호출하여 데이터 동기화
각 서비스는 최소한의 필수 데이터만 유지
Polyglot Database
- 조회(고성능)
- 가게노출: DynamoDB, MongoDB, Redis
- 광고리스팅, 검색: Elasticsearch
- 바로결제 라이브: Redis
- 명령(안정성)
- 광고: 오로라DB(RDB) - mysql 호환
- 가게/업주: 오라로DB(RDB)
가게목록조회 - 통합, CQRS Query Model
조회와 명령을 분리하여 성능 보장 및 장애 격리
데이터 싱크 장애 대응
- 이벤트 재발행
- 큐 장애 발생시
- 임포트 API 제공 - batch sync
- 부분 동기화 API 제공(분단위)
캐시 적극 사용
Circuit Breaker 사용
비동기 Non-Blocking 사용 - WebFlux, Reactor
배달의민족은 거대한 CQRS
성능이 중요한 외부 시스템, 비즈니스 명령이 많은 내부 시스템으로 분리
이벤트 발행을 통한 Eventually Consistency(최종적 일관성) 제공
각 시스템은 API 또는 이벤트 방식으로 연동
(모든 시스템이 이벤트 방식으로 제공되는 것은 아님)
2019.04.01 먼데이프로젝트
2019.11.01 탈루비 끝!
마이크로서비스를 꼭 해야하나요?
규모의 경제가 되어야 함
MSA는 비용이 많이 소요되므로 그 비용을 상쇄할 트래픽, 고객 수 등을 충족해야함
후기
배달의민족이 지난 5년여간 급격한 성장을 겪으며 발생하는 문제 극복기
구체적인 사용 기술과 AWS의 서비스를 이해하기 쉽게 설명해서 좋았고 배달의민족의 대용량 트래픽 처리와 장애 격리에 대한 철학을 알 수 있는 기회였다.
핵심 키워드 CQRS + Event-Driven MSA