대기 서버 구상 - (3), 세부 정책 추가
jaejeong1 opened this issue · comments
- 대기표 발권
- 사용자가 들어오면
- 사용자에게 순번을 발급해서 전달하고
- 발급 순번을 증가
- 대기표 폴링
- 사용자가 발급받은 순번을 건네주면
- 통과 순번과 비교해서(cutoff)
- 아직 때가 되지 않으면 튕겨냄
- 예약 서버 진입
- 사용자가 발급받은 순번을 건네주면
- 통과 순번과 비교해서
- 때가 되었으면 예약 서버로 포워딩
당장 생각나는 성능 최적화 부분
- 대기 순번 조회 풀링이 매우 빠른 간격으로 필요하지 않으니, 대기 순번 write를 일정 크기로 모아서 처리
- 예약 서버에서 cutoff를 수정하기 전까지는 동일한 대기 순번이 조회될 것이므로 해당 대기 순번 read시 캐시 적용
"순번" 이라는 것을 통해 전체적인 메커니즘이 동작하는 것으로 보이는데요.
이 순번은 3.i 에 따라서 사용자가 전달해주는 것을 이용해서 판단(예약 서버로 포워딩을 할지말지 결정)목적으로 사용되는 것으로 이해됩니다.
이 경우 사용자가 보내주는 순번 정보가 조작되지 않았는지를 어떻게 확인할지 궁금하군요.
(딱 드는 생각은 JWT token을 이용해서 위 문제를 해결할 수 있을까 싶군요)
예약을 위해선 클라이언트(웹)과 서버는 여러번의 API 통신을 하게될텐데요(목록조회, 예약, 예약 결과 조회 등)
위 대기 순번이라는 개념은 각 API가 아닌 유저별로 채번되겠지요?
만약 그렇다면 예약을 다한 유저의 경우에는(예약을 성공한 유저) 다시 예약 시도를 하면 대기열에 다시 줄을 서게될까요?
단순히 cutoff 미만의 유저를 예약 서버로 포워딩하게된다면 시간이 갈수록 예약 서버로 포워딩하는 유저의 수가 점점 늘어나지 않을까요?(cutoff 미만의 조건에 걸리는 유저의 수가 순증)
"순번" 이라는 것을 통해 전체적인 메커니즘이 동작하는 것으로 보이는데요.
이 순번은 3.i 에 따라서 사용자가 전달해주는 것을 이용해서 판단(예약 서버로 포워딩을 할지말지 결정)목적으로 사용되는 것으로 이해됩니다.
이 경우 사용자가 보내주는 순번 정보가 조작되지 않았는지를 어떻게 확인할지 궁금하군요.
(딱 드는 생각은 JWT token을 이용해서 위 문제를 해결할 수 있을까 싶군요)
네, 말씀주신 대로 현재 아키텍처에서는 순번 정보를 검증하는 절차가 부재합니다.
JWT를 사용해 검증하는 것이 가장 가볍고 정확한 방식으로 판단되어 해당 방법으로 순번 정보를 검증하는 로직을 추가해 아키텍처 보완할 예정입니다.
예약을 위해선 클라이언트(웹)과 서버는 여러번의 API 통신을 하게될텐데요(목록조회, 예약, 예약 결과 조회 등) 위 대기 순번이라는 개념은 각 API가 아닌 유저별로 채번되겠지요?
만약 그렇다면 예약을 다한 유저의 경우에는(예약을 성공한 유저) 다시 예약 시도를 하면 대기열에 다시 줄을 서게될까요?
네, 말씀주신 컨셉이 맞습니다!
단순히 cutoff 미만의 유저를 예약 서버로 포워딩하게된다면 시간이 갈수록 예약 서버로 포워딩하는 유저의 수가 점점 늘어나지 않을까요?(cutoff 미만의 조건에 걸리는 유저의 수가 순증)
이 부분은 cutoff 기준을 2개로 두어 처리하면 말씀주신 부분을 보완할 수 있을 것으로 보입니다.
예) cutoff_begin : 1000, cutoff_end : 1500 -> cutoff_begin : 1500, cutoff_end : 2000