WOOWACON(우아콘) 2023 후기 - 1

2023년 11월 15일 수요일 woowacon 2023이 진행되었습니다.
좋은 기회로 현장참여를 할 수 있었고, 자세한 내용은 곧 오픈될 영상으로 확인할 수 있으니 메인으로 들었던 백엔드 세션에 주관적인 후기를 기록하려 합니다.

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

푸드주문서버개발팀 강홍구님

첫 세션은 푸드주문서버개탈팀의 강홍구님이 진행하셨습니다.

주문시스템은 가게, 메뉴, 주문, 결제, 배달 등 수많은 시스템과 통신하고 있고, 일평균 3000만건의 주문건을 저장하고, 수년간의 데이터를 보관하고 관리한다고 합니다.
대규모 트랜잭션 속에서 데이터의 정합성 보장, 조회성능을 위해 고민했고 그 과정 속에서 선택한 아키텍쳐를 소개해주셨습니다.

• 하나의 시스템 장애가 전체 시스템 장애로 퍼지게 됨 -> 단일 장애 포인트
• RDBMS 조인 연산으로 조인 성능이 안좋아짐 -> 대용량 데이터
• 주문수 증가로 저장소의 쓰기 처리량 한계 도달 -> 대규모 트랜잭션
• 규칙없는 이벤트 발행으로 서비스 복잡도가 높아짐 -> 복잡한 이벤트 아키텍처

고민하였던 포인트는 위처럼 크게 4가지로 나뉘었습니다.

단일 장애 포인트

중앙으로 집중된 DB에 장애가 발생하면 전체 시스템으로 장애가 전파되는 문제발생

• 각각의 도메인이 각자 데이터베이스를 보유
• messageQueue를 이용해 이벤트 기반 통신
  과 같이 변경해 시스템간 영향도를 분리합니다.

이 부분에 대해서는 기존 MSA 학습시 이론에 맞추어 간단하게 진행을 해봐서 그런지 익숙하게 다가왔습니다.
물론 실제 운영되고 있는 데이터베이스를 도메인별로 쪼개고, 메세지 큐를 도입한다는게 쉽지 않다는걸 알기에 멍해지긴 했지만요

대용량 데이터

주문의 저장과 조회가 함께 일어나는 구조일 때 정규화된 애그리게이트는 조회시에 조인연산을 필요로 하고, 그 과정에서 성능저하가 일어났다고 합니다.

• mongoDB 단일 도큐먼트로 역정규화
• 주문이벤트 발행 후 수신한 이벤트 처리기가 mongoDB에 조회
• 커맨드 모델과 조회 모델을 분리해서 조회모델 역정규화로 해결

내부 이벤트에서 messageQueue에 필요한 키만을 전달 -> 이벤트처리기에서 조회 -> 각각의 필요한 지점에 메세지 발행

이 부분에서 우아콘 오길 참 잘했다 라고 생각했던 것 같습니다.
매번 이론으로 CQRS를 접했는데, 실제로 잘 정리된 내용을 보니 한번에 이해가 되었습니다.
RDBMS만 활용해왔던 저에게 당장 실무에서 Nosql을 적용했을 때 이점이 될 포인트가 보였고, 이벤트를 잘 활용한다면 시스템 아키텍처에도 긍정적인 영향을 얻을 수 있을 것이라 생각했습니다.
아키텍처 적용에 대한 내용은 두번째 세션모놀리식에서 점진적 서비스 분리에서 느낀점을 더 적겠습니다.

대규모 트랜잭션

주문 수 증가로 저장소 쓰기 처리량 한계 도달
AWS RDS의 최고 성능으로도 쓰기처리량이 부족했다는 상황입니다.
실시간 조회는 replica 스케일아웃으로 해결할 수 있지만 write DB는 하나로 구성되어있는 클러스터 특성을 해결했던 내용이였습니다.

• 샤드 클러스터를 직접 구성해서 쓰기부하를 분산 (aurora db는 샤딩을 지원하지 않는다.)
• 즉, 애플리케이션 샤딩을 구성
• 여러 샤드에 있는 데이터를 애그리게이트 하는 방법을 고민했고, 키 베이스 샤딩과 디렉토리 베이스 샤딩을 적절하게 이용해 해결했다.

아직 당장 실무에서 적용하기에는 이정도 트래픽을 견딜 일이 없다보니…크게 와닿지는 않았습니다. (나도 이런 서비스 해보고싶다!)
샤딩에 대한 개념을 조금이나마 배울 수 있었습니다.
샤딩을 지원하지 않는 AWS RDS를 애플리케이션 수준의 샤딩으로 클러스터링을 설계한 것이 현재 있는 자원 안에서만 생각하지 않아야겠다는 생각을 했습니다.
그리고 도메인 단위로 데이터베이스를 나눈것이 이런 데이터베이스 클러스터화 과정에서 큰 이점으로 다가오지 않았을까 싶었습니다.

복잡한 이벤트 아키텍처

규칙없는 이벤트 발행 과정에서 서비스 복잡도가 높아진 것을 해결했던 내용입니다.

• 주문 도메인 이벤트는 내부 이벤트로 정의
• 서비스 로직은 외부 이벤트로 정의
• 내부 이벤트는 ZERO Payload 전략 이용
  • DB 조회가 가능하기 때문
• 이벤트 처리 주체의 단일화
  • feign과 같은 네트워크를 이용한 데이터 송수신 방법이 있지만, 네트워크 비용보다 이벤트 처리 주체 단일화에 이점이 있다.
• 이벤트 발행 실패시 처리를 위해 트랜잭션 아웃박스 패턴 적용

사실 앞 내용만으로도 머리가 꽉 차버려서 완전히 이해하지는 못했습니다.
이벤트 처리기를 두고, 해당 이벤트 처리기에서 서비스 로직을 수행하면서 서비스에서 처리하는 주체를 한 곳으로 집중하면서도 복잡하지 않게 잘 나누었다고 생각했습니다.
트랜잭션 아웃박스 패턴을 새로 알게 되었는데, 이벤트 발행 실패시 아웃박스엔티티를 통해 유실된 이벤트 중복발행 가능성은 있지만 완전유실은 막는다는 말이 이상적이였습니다.

마무리

 

현재 팀에서 서비스 시스템 아키텍처를 구성하는 입장에서 모두는 아니지만 일부는 적용해봐도 괜찮겠다는 생각과 messageQueue를 이렇게 사용하면 되겠구나 싶었습니다.
CQRS를 듣기만 했지 실제로 적용한 내용을 보면서 복잡한 조회성 요청을 풀어낼 방법을 다른 방향으로 풀어낼 고민을 하게 되었습니다.

다음은 우아콘 가길 잘했다 싶었던 모놀리식에서 점진적 서비스 분리: 사업과제와 병행하여 시스템 개선하기입니다.

읽어주셔서 감사합니다.

강홍구님 계속 옆으로 왔다갔다 하셨는데…붙잡고 뭐라도 더 물어볼걸 그랬습니다 흑흑