• 1부: 대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화
• 2부: 프론트엔드 개발의 미래, Module Federation의 적용

들었던 내용들은 가볍게 정리하기 위해 이 글을 작성한다.

1번 세션에 관심이 더 있었기 때문에 좀 더 집중해서 들었다.

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

성장하면서 겪은 문제들

단일 장애 포인트 해결하기

초기 : RUBY 라는 중앙 저장소를 사용, 이는 단일 장애 포인트가 됨. MSA 를 통한 탈중앙 을 시도

대용량 데이터 성능 이슈 해결하기

정규화된 애그리거트 : 조인 연산 -> 성능 저하 조회 성능을 높이기 위해 단일 도큐먼트로 역정규화를 진행

그러면 데이터 동기화는 어떻게 진행? 주문 이벤트 처리기에서 진행 후 몽고 DB에 동기화

CQRS 아키텍처 적용

CQRS(Command Query Responsibility Segregation) : 저장모델과 조회모델을 분리

쓰기 처리량 한계 해결하기

쓰기 DB 스케일 업 최대한 했는데도 감당 안됨 → 샤딩 하기로 결정 → but, aws 오로라는 샤딩을 지원하지 않음 → 어플리케이션 샤딩으로 진행하기로 결정

sharding 에는 크게 3가지 방식이 있음.

• key based
  • e.g. 주문 번호를 기준으로 샤딩
• range based
  • e.g. 주문 금액을 기준으로 샤딩
• directory based
  • lookup table 사용

최종적으로 key based로 처리하기로 했고 Spring 의 AOP 설정 통해서 진행

다건 조회시 데이터 애그리게이트 이슈가 있음.(샤드에 분산된 데이터를 어떻게 한번에 보내줄 것인가.)
다건 조회시에는 몽고DB 활용하여 해결. CQRS를 적용해둔것이 샤딩 적용시 도움이 됨.

샤딩으로 인해 쓰기 요청 증가를 스케일 아웃으로 대응이 가능해짐.

규칙 없는 이벤트 발생으로 인한 서비스 복잡도 해결하기

이벤트 기반으로 관심사를 분리

내부 이벤트와 외부 이벤트 정리

내부 이벤트는 스프링 이벤트를 기반으로 서비스 분리

외부 이벤트는 SQS를 기반으로 이벤트 처리 주체 단일화

트랜잭션 아웃박스 패턴을 이용하여 이벤트 재발행 수단을 보장

재실행은 될 수 있지만 유실은 되지 않도록 보장

모의 장애 훈련을 통해 장애 상황 대비

2부: 프론트엔드 개발의 미래, Module Federation의 적용

typescipt type 공유 : native-federation-typescript

아직 관련 라이브러리들이 unstable

의존성은 불리했지만, 구성의 어려움은 존재

다른 모듈러 (e.g. vite) 들도 module federation을 시도하고 있지만 아직까지는 그래도 webpack쪽이 가장 활성화 되어 있음. 과거 NHN에서 진행하는 행사에 참여했을 때도 webpack module federation을 사용한다고 들은바 있음.