기술적인 스코프 확장에 초점을 맞춰라 챌린지팀의 스코프는 기능의 많고 적음이 아니라 기술적인 부분이 어느정도 포함 되어있냐가 기준이다.
가령 메인 페이지에 공연 정보가 나열 되어 있을 때 그 정보들을 사용자에게 얼마 만큼 빠르게 보여줄지를 고려한다던지 기존의 RDBMS의 검색 기능 **성능**을 높이기 위해 엘라스틱서치를 도입한다던지 이런걸 말하는 것.
좌석 선택의 경우, 인터파크나 다른 서비스처럼 좌석 하나 하나 있는게 아닌, List 형태로 Select하는 방향도 좋음(좌석 선택 페이지 구현은 프론트가 처리해야 하는 부분) 기술적인 스코프의 예시로는
이러한 방식을 통해 어떠한 기술을 개선해가며, 기술적인 스코프를 확장해 나가는 것이 챌린저팀의 핵심 목표이다.
시퀀스 다이어그램을 제작 시퀀스 다이어그램은 우리가 어떻게 서비스를 설계할 지 방향성을 잡아준다. 현재 방향성 잡기가 쉽지 않아 보이는데, 시퀀스 다이어그램을 제작해보고, 방향성을 다시 잡아주는 것이 좋아보임
Transaction 관련 질문 티켓 신청 → 좌석 선택 → 결재 이 부분에 있어서, 하나의 트랜잭션이라는 개념은 틀린 개념이다. 각각 하나씩 Transaction을 걸어줘야 하며, 티켓 신청 시 Transaction 진행 후 Commit → 좌석 선택 Transaction → 결재 Transaction을 진행해야 한다. 이 부분도 시퀀스 다이어그램 내용과 어느 정도 공유되는 부분
Row의 잠금을 길게 가져가는게 아니다.
좌석 선택 관련 너무 어렵게 구현할려고 하지 마라. React를 쓰는 것은 권장 단, 우리는 어떠한 서비스를 보여줄려고 하는 게 아닌, 기술적인 스코프에 Focus를 맞춰야 하므로, 정말 대충 짜도 상관없다. 좌석 선택의 경우, 그냥 좌석마다 List를 쫙 나열하고, Select 하는 방식도 상관 없음
MQ를 통한 예약 방법
Producer를 통해 예약 신청을 Queue에 넣어두고, 이를 Consumer가 받아 DB booking Table에 등록하는 방법 이를 통해, Booking Table에 Transaction을 걸어야 할 필요가 없어지며, TPS적인 부분도 속도가 상승한다. Kafka 는 Broker가 적어도 3개 이상 존재해야 하며, Leanring Curve가 조금 있으니, Redis로 구현하는 것을 추천한다. 또한, MSK, Kinesis등 다양한 스트리밍 서비스가 있다.
Redis의 분산 Lock : RedLock → 다음 멘토링 시간에 설명해주나, 미리 알아보자. Redis의 Pub/Sub 기능을 통해 Message Queue를 구성할 수 있다. 또한, DB의 Booking Table에서 Counting 하는 것을, Redis로도 Count가 가능하다 (DB에서 카운트를 샐 때마다 락이 걸려서 나오는 카운트도 다를거고 난리가 난다. 그래서 DB 에서 모든 역할을 하기 떄문에 redis 로 카운트를 뺀다.) Ex) **booking:{bookingId}:count
@**부킹을 그룹바이를 하면 락이 걱정되고 성능에 문제가 생길 수 있음 근데 레디스에서 하면 락을 걱정하지 않아도 된다.
티켓, 좌석 업데이트 도중의 동시성 제어 상태가 바뀌는 도중에, 동시성 제어는 어떻게 할 것인가? → Redis Message Queue System 혹은 Transaction을 걸어서 사용하기.
그래서 우리가 지금 해봐야 하는 것은??
1. DB만 사용하는 방식으로 시퀀스 다이어그램을 그린다. 2. 이걸 구현한다. (api/v1) 3. 테스트 방법을 준비한다. 4. Redis 큐 예약 방법 시퀀스 다이어그램을 그린다. 5. Bull.js, 컨슈머, 로직 검토해야 한다. 6. 예약 프로세스 v2 api를 만든다. 7. 테스트