박종훈 기술블로그

231220 - 우아한 테크 세미나 정리 (대규모 트랜잭션 처리, Module Federation)

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

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

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

성장하면서 겪은 문제들

problems

단일 장애 포인트 해결하기

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

problems-2

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

before-denormalization

problem-by-normalized-db

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

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

CQRS 아키텍처 적용

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

쓰기 처리량 한계 해결하기

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

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

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

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

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

after-sharding

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

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

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

internal-event-and-external-event

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

isolating-services-based-on-spring-events

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

unify-event-handling-entity

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

transaction-outbox-pattern

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

final-architecture

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

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

typescipt type 공유 : native-federation-typescript

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

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

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