🛎️ 김명국 멘토님의 말씀

티켓 예매 시스템을 구상하고 계시는군요. 동시성 제어 등 기술적인 부분을 다루기에 적절한 주제를 선정하신 것 같습니다. 다만 4명의 인원을 고려해도 개발 스코프는 작아 보이는 것이 사실입니다.

티켓예매 시스템도 참고할 사이트가 많이 있고 챌린지팀 입장에서 기술적으로 다룰 수 있는 내용이 많이 있어 보이니 조금만 스코프를 넓히는 고민을 해봤으면 좋겠습니다. (티켓 예매에서 좌석을 선택하는 기능이라든지, 이미 다른 사람이 예매를 진행 중일 때 선택한 좌석을 몇 분간 점유할 수 있도록 하는 기능이라든지의 디테일을 추가해도 좋습니다)

Websocket으로 실시간 채팅 구현을 할 때 Websocket의 로드밸런싱에서 sticky session도 고려해야 합니다. 많이 헤매는 부분이다 보니 초창기부터 sticky session에 대한 개념을 이해해서 실시간 채팅을 구현하는 데 어려움이 없기를 바랍니다.

지금 문서를 통해서는 실시간 채팅을 어떤 방식으로 풀어낼지에 대한 정보를 얻기가 좀 어려운데 어떤 채팅을 구현할지에 대해 상세하게 정해보셨으면 좋겠습니다.

티켓 예매 시스템을 한정된 예산 내에서 높은 TPS를 보여주기 위해서는 RDBMS만으로 구현하기보다는 Queue 시스템을 활용하는 것이 좋습니다.

Kafka를 스트리밍 메시지 큐로 많이들 활용하는데, Producer, Broker, Consumer 등의 개념을 6주라는 짧은 시간 내에 이해해서 구현까지 이뤄내는 데에는 어려움이 있을 수 있습니다.

그래서 Kafka로 구현하는 부분은 알아두면 좋지만 비추하고 Redis에도 Pub/Sub을 통해서 이를 구현할 수 있습니다. 그래서 RDBMS만을 활용해서 티켓예매 시스템을 구현하기보다는 Redis를 십분 활용하여 한정된 예산에서 높은 성능을 뽑아낼 수 있는 데 집중했으면 합니다. Redis의 분산락을 활용해 볼 수도 있고, Redis의 클러스터 구성에 대해서도 한 번 확인해 보세요.

RDBMS는 기본적으로 수평적 확장이 그리 쉽지는 않습니다. Master-slave 등으로 구성하여 slave를 읽기 전용으로 사용하는 방법이라든지, Cluster로 구성하거나 샤딩을 사용한다든지 여러 가지 방법이 있습니다. 수평적 확장을 고려한다면 NoSQL Database를 고민해 볼 수도 있겠죠. 전체 서비스에서 무조건 하나의 데이터베이스를 선택하는 게 아니라 필요에 따라 RDBMS, NoSQL, Cache를 복합적으로 활용합니다. 사용하지 않더라도 어떤 특징을 지녔고 어떤 데이터에 적합하고 우리는 왜 쓰는지, 왜 쓰지 않는지에 대한 적절한 검토가 이루어졌으면 합니다.

티켓 예매도 예매인데 큰 규모의 공연 데이터를 저장하고 다루는 입장도 신경을 써봤으면 합니다**. 실제 공연 데이터를 보통 인터파크나 yes24 크롤링을 통해 진행하고, 공공데이터 포탈을 통해 예술 관련된 정보를 얻어서 공연으로 입력**할 수도 있을 것입니다. 이렇게 진짜 공연 데이터를 가져오는 것 외에도 mock up 데이터를 몇천만 건 추가하여 수천, 수만의 유저들이 공연 시스템에 접근할 때 무리가 없는 시스템을 구축하는 고민도 해보면 좋을 것 같습니다. 여기서도 Cache가 많은 역할을 할 겁니다.

ERD는 비교적 단순하여 크게 손볼 부분은 없는 것 같고 대기열 시스템에 Redis 등을 활용한다면 standby 등의 테이블은 없어도 될 것 같고요. admin을 별도의 테이블로 분리하셨는데 이렇게도 많이 쓰지만 users 테이블에 통합하고 user 별로 권한을 부여하여 사용하기도 합니다. 한번 고민해 보세요.

API 엔드포인트는 login, signup 등이 /api/ 내에 따로따로 존재하는데 /api/auth 내에 모아서 진행해야 일관성 있는 설계로 보이고요. 공연 게시글이라고 post를 사용하셨는데, 제가 보기엔 공연을 게시글이라고 보기에는 좀 무리가 있고요.

인터파크 티켓의 경우 goods(상품), 예스24는 Perf(performance?)로 지칭해 사용하고 있는데 적절하게 다루는 자원(ticket, performance, concert 등…) 을 지칭하는 단어를 찾아서 사용하는 게 좋아 보입니다. 공연 참가 신청도 api/post/:postId를 POST로 요청하는 게 약간 어색해 보이는데요.

api/perfomance/:performanceId/attend 처럼 참가를 위한 자원 표시를 따로 가져가는 게 좋겠습니다.

앞으로 6주간 재미있는 서비스를 만들어보시죠. 잘 도와보겠습니다.