ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화
    세미나, 영상 요약정리 2023. 12. 31. 00:01
    728x90

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

     

    푸드주문서버개발팀의 강홍구님의 발표를 요약해보고자 합니다.

     

    공유하고 싶은 주제

    개발자가 급속도로 성장하는 서비스의 주문 시스템을 만들면서 고민한 과정들!

    장바구니, 주문하기 시스템을 개발하며  12시, 18시30분 정도에 트래픽이 높은 특성을 가지고 있습니다.

     

    특징1 - MSA

    가게, 메뉴, 주문 ,결제, 배달 등 수많은 시스템이 통신하고 있습니다.

    다른 시스템에 문제가 생겨도 주문이 가능한 방법을 고민합니다.

     

    특징2 - 대용량 데이터 & 대규모 트랜잭션

    일 평균 300만 건의 주문을 저장하면서 데이터 정합성 조회 성능을 고려해야 합니다.

     

     

    특징3 - 여러 시스템과 연계

    이벤트 기반으로 통신!

    이벤트 유실이 발생하지 않아야 한다!

     

     

    트러블슈팅1 - 단일 장애 포인트

    초기에는 Ruby 대용량 저장소를 여러 시스템이 의존하고 있었다.

    중앙 저장소의 부하가 바로 장애로 이어졌습니다.

     

    각 시스템을 분리하는 프로젝트가 진행되었고 시스템 간 통신은 Message Queue 기반으로 통신하게 되었습니다.

    특정 시스템에 문제가 발생해도 그 시스템에 관심이 없는 시스템은 문제 없이 동작합니다.

     

    이벤트는 재발행, 재수신이 가능한 구조여서 장애가 해소되면 다시 정상적으로 복구됩니다.

     

    트러블슈팅2 - 대용량 조회

    과거에는 저장(Command)과 조회(Query)가 하나의 db에서 일어나는 구조!

    정규화로 인한 조인 연산이 필요했고 성능저하로 이어짐

     

    MongoDB를 도입하여 역정규화를 수행하고 조회성능을 개선!

    단순히 id조회만으로 여러데이터를 가져올 수 있게됨

    즉, Command와 Query에 대한 데이터모델을 분리

     

    그러면 동기화는 어떻게..?

    주문 생성, 주문 접수, 배달 완료, 주문 취소 등의 생명주기에서만 도메인 변경이 발생하고 도메인 변경 이벤트를 받아서 몽고DB에 적재합니다.

     

    트러블슈팅3 - DB 분당 쓰기 처리량 한계치 도달

    현재 DB는 primary - replica 구조이므로 primary는 scale-up을 수행했어야함.

    샤딩을 통하여 쓰기 부하를 분산해보자

    하지만AWS aurora는 샤딩을 지원하지 않음..

     

    application에서 샤딩을 지원해보자.

    • 어느 샤드에 접근할지 결정하는 샤딩 전략 -  주문번호 Key의 Hash 기반으로 샤딩
    • 여러 샤드에 있는 데이터를 aggregate 하는 전략 - CQRS를 적용하면서 조회성 정보는 mongoDB에서 조회

     

     

    트러블슈팅4 - 복잡한 이벤트 아키텍처

    알림 전송, 외부 이벤트, 현금 영수증, 데이터 동기화, 분석 로그 등은 이벤트 기반으로 관심사를 분리하고 있습니다.

    spring event를 기반으로 수행했을때 로직을 수행하는 주체를 파악하기 어려웠습니다.

     

    이를 해결하기 위해서 2가지 전략을 수행

    • 이벤트 처리기에 위임을 수행하며 특정 Application 서버에서 로직을 누락하는 문제를 해결
    • 트랜잭션 아웃박스 패턴을 통해 이벤트 발행 실패와 서비스 실패를 격리하고 이벤트 재발행을 편하도록 만들기

     

    Q & A

    Q. 트래픽이 많으면 WebFlux같은 reactive programming 어때요?

    A. 도메인의 특성마다 달라질 것 같고 주문 도메인은 데이터의 정합성이 중요하기 때문에 RDB를 활용해야 했고 RDB가 결국엔 병목이라고 판단하여 MVC를 활용

     

    Q. 트래픽 피크 시간대의 인프라 또는 리소스 자원 관리가 궁금해요

    A. 오토 스케일링을 활용하여 인스턴스 수를 동적으로 활용하고 있습니다.

     

    Q. 아키텍처 리디자인시 사이드 이펙트 발생 유뮤를 어떻게 처리했는가?

    A. A/B테스트 또는 피쳐 토글을 통하여 또는 임직원 대상 먼저 오픈하는 다양한 방식들을 활용하면서 배포합니다.

     

    Q. 트랜잭션 단위로 묶여야하는 상품 쿠폰 재고 등에서 트랜잭션 별로 에러가 발생할 때 어떻게 처리하는가?

    A. 각 도메인별로 트랜잭션 정합성을 보장하며 일 단위로 대사를 통해 보정을 수행!

     

     

     

     

    댓글

Designed by Tistory.