주제
- 예매 사이트 컨셉은 가져감
- 테스트 툴을 만들면서 동시에 예매 연습 기능을 제공하는 컨셉으로 변경
- 예매 연습 기능을 완성하면 실제로 예매 기능도 쉽게 추가할것으로보임
- 예매 연습 기능을 통해서 대용량 데이터 + 트래픽 을 다뤄보면서 배울게 많아보임
이 서비스를 왜 다른 플랫폼은 왜 안했을까? 생각을 해보았나
- 티켓 베이와 같은 새로운 플랫폼은 확인 해봤으면 좋았을거같음
- 단점 하나에만 꽂히면 내가 원하는 결론으로 이끌어가고자 하기 때문에 다양한 플랫폼을 비교해보는것이 좋음
- 기존이랑 동일한 부하를 주면서 개발 하는것이 관건임, 우리가 생각하는 방향성은 달라보임
- 기획에서 상품성을 챙길피요가 없지않나?
- 그거는 맞다 하지만
- 예매 시스템을 새로운 형식으로 디자인하는데 → 기존환경이랑 다르면 테스트 하는 환경과는 상관이 없는것 아닌가?
- 지금 목적은 기존 것을 연습 하는 기능을 만들고자 하는것 아닌가
- 기획에 따라서 구현하는 방향이 달라짐 → 명확한 방향성을 가질 필요가 있음
- 기존 방향 → 기존 예매 사이트를 테스트하는 사이트
- but, 기존 사이트들의 낡은 화면, 즉각적으로 반영안하는 것들을 개선하고자함
- 기존사이트들이랑 다른 환경 그럼 뭐를 테스트하나?
- 일관성이 없는 느낌이 들음
- UX나 시스템 개선은 OK, 프로젝트의 핵심가치는 테스트 중점을 언급 방향이 맞지 않음
- 제 1가치가 어떤것인지 명확하게 정해라
- 기존 예매 시스템 개선이 목적인지, 테스트가 목적인지
- 방향을 어떻게 정하느냐에 따라서 설계가 달라질것으로 보임
- 뱡향성을 제대로 잡아라
- 핵심 가치를 어떻게 할건지 정해라
- UX개선의 목적을 둔다면 어느정도까지 부하를 둘지 결정해라
- 아키텍처 구조를 먼저 그려라 → 제일 중요함
- 봇(테스트)에 너무 집중해서 서버가 제대로 설계되어 있찌 않음
- 주제를 명확하게 정해라!!
- 봇은 어떻게 구현하려했나?
- API요청으로만 구현하려했음
- 이게 잘못하면 봇서버 구현하는게 아무 이득이 없음
- 이 형태로만 하면 우려가많음 → 작업 분배가 애매해질 문제가 있음
- 봇들도 웹 소캣 연결 → 클라이언트 2명을 구현
- 웹 소캣 쓰는거 자체는 문제x → 웹소켓이 담당하는 범위가 어디까지인지
- 예전 어떤 팀 웹 소캣 을 써버리니 모든 기능에느 웹소캣을 써버림
- 웹 소캣 사용하면 이벤트 드리븐으로가버림 → 리팩토링 힘들어짐
- 웹소캣이 담당하는 범위를 명확하게 정해라
- 멘토님 일단 드는 생각 실시간 풀링만해도 상관없음
- long polling을 사용해도 될것같음
- 요청을 보내면 서버에서 응답x → 변경이 있으면 서버에서 응답을 보냄
- 고민해보면 좋을거 같음
- 좌석 선점 되는거만 처리되고싶으면 sever sent event 사용해도 좋을거같음
- 클라이언트에서 좌석 선점 일반 리퀘스트 처리해도됨
- 웹소켓 같은경우 연결을 계속 지속하다보니까 서버에서 부하 컨트롤하기가 힘듬
- 제일 걱정되는거 웹 소켓은 코드 구조 제어하기가 애매함
- 실시간 구현 방법 → long polling, sse, 웹소켓 비교하고 어떤거 사용할지 정하기
- 큐면 선입선출 순서대로 나가는게 보장됨
- 대기열 같은 경우 구현 방식에 따라다름
- 롱 폴링, SSE, 웹 소켓 을 통해서 순서를 보장할 수 있음
- 대기하는 입장에서는 웹소켓을 사용하는게 좋음
- DB에 사용자가 왜없나?
- Bottle neck은 사용자 정보조회 등에서 발생하기 떄문에 User가 없으면 실제처럼 구현하기 힘들어짐
- UX개선, 테스트 두가지중 어느 방향으로 가냐에 방향성이 달라짐
- DB는 MYSQL만 사용하나?
- a : MYSQL이랑 Redis를 생각중
- a : Redis 좌석 선점에 쓰일예정이고, 실제 좌석 예매는 확정되면 MYSQL에 저장되는 구조
스키마
- 코멘트를 어느 장단에 맞춰야할지 모르겠찌만
- 단순히 테스트만을위하여 간략하게 한건지
- 예매사이트라고 하기에는 너무 간략함
- 어디까지 할건지 의견을 다시 모아봐라
- 솔직히 말해서 테스트면 RDBMS필요없음