실시간 대기열 시스템 만들기 (2) - 설계

기본 설계

저는 1편 마지막에 소개한 아래 설계를 기본 가닥으로 잡았습니다.

제가 설계할 대기열 시스템은 신청을 누르고 대기하다가 자신의 차례가 되면 해당 페이지에 접속하고, 페이지에서 유저가 직접 결제하는 방식의 시스템입니다.

이 시스템은 트래픽이 몰려 대기열 시스템이 필요한 경우와 그렇지 않은 경우로 나눌 수 있습니다.

if(트래픽이 몰렸으면) {
	대기열 시스템을 이용한다
} else {
	대기열 시스템을 이용하지 않고 응답한다
}

평상시

트래픽이 몰리지 않았을 경우 아래의 내용을 고민해볼 수 있습니다.

1. 트래픽이 몰리지 않았으면 Queue를 이용하지 않고 곧바로 API Server를 호출한다. API Server로 부터 얻어온 응답값을 반환한다.

제가 생각한 해당 방식의 장/단점은 다음과 같습니다.

• 장점
  • Apply Server가 반환해야 할 값이 명확하다.
• 단점
  • 트래픽 여부에 따라 API Server의 동작 또는 호출하는 API가 달라진다.
  • Queue에 처리해야 할 값이 남아 있는데 곧바로 API Server를 호출할 경우 순서가 꼬이게 될 수 있다.

2. 트래픽이 몰리지 않았어도 여전히 Queue를 이용한다.

제가 생각한 해당 방식의 장/단점은 다음과 같습니다.

• 장점
  • 트래픽 여부에 관계 없이 동일한 API를 호출하며 API Server의 동작 역시 동일하다.
  • 직접 호출로 순서를 어기게 될 위험이 없다.
• 단점
  • Apply Server가 전달할 응답값이 모호하다. Apply Server 또는 Client가 API Server에게 주기적으로 요청을 보내 응답값을 받아야 합니다. 또는 Apply Server가 응답을 받기 위한 Queue를 추가로 만들 수도 있습니다.

어떤 방식을 사용할까?

저는 트래픽이 몰리지 않았어도 여전히 Queue를 사용하는 방식을 선택했습니다. SSE를 통해 응답값을 전달할 수 있으며 API서버의 일관적인 동작을 통해 설계의 복잡도를 낮추는 게 더 유의미하다고 판단했습니다.

대기큐 사용

1. Apply Server로부터 Redirect URL을 받아 대기 페이지로 이동합니다.
2. SSE를 통해 지속적으로 자신의 대기순번을 전달받습니다.
3. SSE를 통해 자신의 차례가 됐다는 토큰을 전달받습니다. 토큰을 가지고 목표 페이지로 이동합니다.

참고자료

• https://dev.gmarket.com/46
• https://junuuu.tistory.com/881
• https://github.com/wlwlsus/allback-with-k8s?tab=readme-ov-file#kafka%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%8C%80%EA%B8%B0%EC%97%B4-%EC%8B%9C%EC%8A%A4%ED%85%9C