파킹 페이지와 대기열 큐 질문입니다.

작성한 질문수 1

0

안녕하세요. 좋은 질문입니다. 세 개 다 실제로 만들 때 고민하는 지점이라 순서대로 답변드리겠습니다.

먼저 한 가지만 짚어두면, 강의에서 보여드린 도면은 제가 참여했던 프로젝트를 공개 가능한 수준으로 재구성한 것입니다. 회사 내부 구현을 그대로 옮긴 건 아니라서, "그 회사가 정확히 이랬다"보다는 "이런 구조에서 어떤 선택지가 있고 무엇을 포기하게 되는가"로 답변드리겠습니다.

1. 직접 만드는가, 기성 솔루션을 쓰는가

둘 다 씁니다. 판단 기준은 보통 이겁니다.

기성 솔루션(Cloudflare Waiting Room, AWS의 Virtual Waiting Room 템플릿, Queue-it 같은 상용 서비스)은 발매 이벤트가 1년에 몇 번 없고, 그때만 트래픽이 수십 배 뛰는 경우에 유리합니다. 대기열은 평소에 안 쓰다가 제일 중요한 날에 처음 돌아가는 컴포넌트라, 직접 만들면 "그날 처음 터지는" 위험이 큽니다.

직접 만드는 건 발매가 일상이고(매일 드롭이 있다거나) 대기 화면을 서비스 브랜드에 맞춰 세밀하게 통제하고 싶을 때입니다. Redis의 Sorted Set이나 Stream으로 순번을 관리하고 입장 토큰을 발급하는 수준이면 구조 자체는 복잡하지 않습니다. 어려운 건 만드는 게 아니라 민원/운영 대응이나 장애 대응입니다.

2. 대기열은 어디에 있는가

WAS 안쪽은 안 됩니다. 이게 핵심입니다.

필터나 인터셉터로 막으면 이미 톰캣 스레드와 커넥션을 하나 점유한 뒤에 "기다리세요"를 응답하는 겁니다. 10만 명이 몰리면 대기열이 있으나 없으나 WAS는 똑같이 죽습니다. 앞단에서 막는다는 말의 의미가 "WAS에 요청이 도달하기 전에 끊는다"여야 합니다.

그래서 보통 이렇게 나눕니다.

- 파킹 페이지 자체는 정적 파일이라 CDN에서 내려줍니다. 오리진 부하가 0입니다.

- 입장 토큰 검사는 CDN의 엣지 함수나 API 게이트웨이에서 합니다. 토큰이 없으면 애플리케이션까지 못 갑니다.

- 순번과 입장 토큰 같은 상태만 Redis에 둡니다.

주의하실 점은 대기열 컴포넌트 자체가 단일 장애점이 된다는 겁니다.

대기열이 죽으면 아무도 못 들어옵니다. 대기열이 죽었을 때 전원 통과로 열어줄지 전원 차단으로 막을지를 미리 정해두셔야 합니다.

3. 나간 걸 어떻게 감지하는가

결론부터 말씀드리면, 정확히는 감지 못 합니다. 그래서 대부분 감지하지 않는 쪽으로 설계합니다.

창을 닫는 건 사실상 감지가 안 됩니다. 브라우저 종료 시점에 신호를 보내는 방법이 있긴 한데 모바일에서는 거의 안 날아옵니다. 그래서 이걸 전제로 만들면 유령 세션이 쌓여서, 실제로는 아무도 없는데 "정원이 찼다"고 판단해 입장이 막히는 상황이 생깁니다.

실무에서는 두 가지를 씁니다.

- 입장 토큰에 TTL을 겁니다. 예를 들어 10분짜리 토큰을 주고, 결제 완료되면 즉시 회수, 아니면 10분 뒤 자동 만료입니다. 명시적 퇴장 대신 만료로 처리하는 겁니다. 3-5에서 본 TTL 재고 복구와 같은 발상입니다.

- 동시 접속 인원을 맞추는 대신 입장 속도를 조절합니다. "안에 1,000명 유지"가 아니라 "초당 50명씩 넣는다"입니다. 질문에 쓰신 두 번째 방식이 이쪽이고, 실제로 훨씬 안정적입니다. 유령 세션 문제가 아예 없고, 뒷단이 버티는 속도를 그대로 숫자로 쓸 수 있습니다.

그러면 초당 몇 명이 맞느냐가 남는데, 이건 미리 정하는 게 아니라 부하 테스트로 찾습니다. 뒷단 응답시간 p95와 DB 커넥션 사용률을 보면서 올려보다가 꺾이는 지점 바로 아래로 잡습니다. 운영 중에는 이 지표를 보고 입장 속도를 자동으로 조절하기도 합니다.

감사합니다.