지난 3편에서의 CQRS 개념까지 반영해, 길고길었던 설계를 마무리하고 다음과 같은 산출물이 나왔다.
이벤트 스토밍
구성도
대기 순번 계산
- Redis의 SortedSet을 사용해 유저들을 대기 순번 기준으로 정렬해 큐처럼 사용
- 현재 순위(순번) 조회가 많이 발생할 것으로 예상되어, 해당 작업에 O(N)이 발생하는 큐 대신 SortedSet 선정
- 현재 순위 조회 : O(logN), ZRANK
- 전체 대기자 수 : O(1), ZCARD
- 예약 완료 또는 예약 중 이탈 여부 판단
- JWT는 대기 ~ 예약 입장까지만 사용하고, 입장권 검증이 완료되면 예약 과정은 웹소켓 세션 연결해 진행
- JWT로 관리 했을 때 계산하기 어려운 예약 중도 이탈 시 카운트, 현재 예약 중인 유저 수를 쉽게 구할 수 있음
- 현재 예약 진행 중인 실제 유저 수를 알 수 있으므로, 보다 정확한 트래픽 제어 가능
빠른 좌석 상태 반영을 위한 이벤트 기반 데이터 처리 (Kafka, Kafka Connect)
- 배치 기반 데이터 처리 방식은 처리 단위의 앞쪽에 있는 데이터가 뒤쪽에 있는 데이터가 처리될 때까지 대기해야 한다는 특징을 가짐
- 따라서, 좌석 상태의 변화를 조금이라도 빠르게 유저에게 전달하기에는 부적합하기때문에 메시지 브로커 Kafka를 이용한 이벤트 기반 아키텍처 도입
- 해당 시스템에서 발생하는 이벤트들은 모두 DB 데이터 변경을 수반하기 때문에, DB에 쌓이는 로그를 Kafka Connect를 이용해 Kafka로 전달하는 CDC 플랫폼 도입, DB의 변경 데이터를 Kafka의 CDC 토픽에 쌓음
매일 발전