Skip to content

Latest commit

 

History

History
130 lines (107 loc) · 8.36 KB

architecture-cases.adoc

File metadata and controls

130 lines (107 loc) · 8.36 KB
Raw

우아한 형제들

대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화

  1. 단일DB로 인한 전체 장애 → 단일DB를 여러 저장소로 분리 (주문/주문중계/가계 등)

  2. 읽기 성능 한계 → 읽기 부하를 Document DB로 분산(메시지큐를 이용한 데이터 동기화)

  3. 쓰기 성능 한계 → DB 샤딩 (주문키 기반 샤딩)

  4. 규칙성 없는 이벤트 발행으로 인한 복잡도 증가, 이벤트 유실 → 이벤트 로직을 단일 어플리케이션에서 처리, transactional outbox 적용

배달의민족 마이크로서비스 여행기

  • Netflix가 MSA로 가는데 7년이 걸렸다고 함

  • 거대 DB에서 분리한 시스템 순서

    • (2016) 결제 서비스를 처음 분리

      • 결제가 장애나도 전화 주문을 할 수 있음.

      • 당시 돈과 관련된 건은 Cloud에 올릴 수 없었음.

    • (2016) 주문 중계

      • 여러 주문 접수 경로로부터 포워딩해주는 게이트웨이 서비스

    • (2017) 메뉴, 정산

    • (2018) 가게 목록 + 검색 시스템

    • (2018) 가게 상세

      • 기존DB에서 1~5분 배치로 AWS DynamoDB로 데이터 동기화

    • (2018) 쿠폰, 포인트

    • (2018) 주문

      • 제일 복잡. 모든 시스템과 다 엮임.

      • 배만과 라이더스를 통합하는 새로운 주문 테이블 설계

      • 이벤트 기반으로 변경

        • 전사 차원의 이벤트 규약 정리. (생성/접수/배달완료/취소)

    • (2018) 리뷰

    • (2019) 광고 + 가게

      • 신규 사업모델을 반영하면서 시스템 구조 개편(사업과 기술조직을 다 만족시키는 방향)

      • CQRS 로 전사 아키첵처를 재구성

        • 가게노출시스템(READ 관점), 광고리스팅, 검색 시스템

      • 조직구조에서도 Command과 Query를 분리

    • (2019) 회원/인증

      • 2019년 11.1일 기존 DB 완전 탈출

  • 2016 치킨 이벤트 대처

    • 1일차 Front 서버 장애. 하루만에 AWS 이전

    • 2일차 주문서버 장애. 주문도 하루만에 서버 AWS 이전

    • 3일차 PG서버 장애. 해당 업체에서 장비를 늘림

    • 4일차에는 성공.

  • 2017 대장애의 시대

    • 하루 주문수 20만 돌파

    • 주말에도 장애나고 해서 개발자/CTO 모두다 괴로워함.

    • 배민 장애나면 사람들이 요기오 → 배달통으로 순서로 주문시도하는데, 차례대로 죽어버림.

  • 2018에 안정성을 최우선의 가치로 선언. 돈버는 과제보다 우선 시.

  • CQRS, Event

    • Query 시스템은 비동기 nonblocking 기술 많이 사용 (Spring WebFlux)

    • Zero payload 방식

      • 이벤트에 가게 ID만을 보내고 consumer에서 HTTP API를 호출하여 필요한 데이터를 얻어옴.

      • 테이블이 수십개라 모든 데이터를 다 메시지에 넣어서 보내는 방법은 현실적이지 않았음.

    • 데이터 저장

      • 최소 데이터 보관 원칙 : 각 시스템은 필요한 최소한의 데이터만 보관. 데이터는 논리적인 의존관계를 만듦

      • CQRS의 역할에 따라서 저장소 솔류션 선택

        • Command 시스템은 안정성이 높은 RDB

        • Query 시스템는 성능이 좋은 NoSql류도 도입 (DynamoDB, MongoDB, Redis, ES)

  • 데이터동기화

    • 장애 대비 : 메시징큐 장애시에 대비해서 전체 데이터를 sync하는 5분 배치가 있음.

    • 데이터 validation 등을 위해 API를 호출해야하는 경우의 정책 보완.

      • API 실패나 일관성이 맞지 않는 데이터에도 가급적 주문은 이루어지도록 기획과 논의

      • 예) 사장님이 음식 메뉴이름을 바꾸었을때 이전 이름으로라도 주문은 되는 것이 낫다.