이탈 유저 감지 및 대기열 정합성 유지 전략

1️⃣ 문제 재정의

우리 시스템은 초당 수만 명에서 최대 10만 명 이상의 대기자를 수용해야 합니다. 이때 가장 큰 위협은 **'좀비 유저(Zombie User)'**입니다. 브라우저를 닫거나 네트워크가 끊긴 유저가 대기열에 계속 남아있다면 다음과 같은 치명적인 문제가 발생합니다.

• 순번 왜곡: 실제 대기자는 1,000명인데, 좀비 유저 때문에 번표는 5,000번으로 찍히는 UX 붕괴.
• 가동률 저하: 워커(Worker)가 입장을 시키려 할 때마다 좀비 유저를 뽑게 되어, 실제 예매 창으로 넘어가는 유저의 유입 속도가 현저히 느려짐.

우리의 목표: "최소한의 자원(Redis CPU/Memory)으로 최대한 빠르게 이탈자를 찾아내고 제거한다."

2️⃣ 생각의 흐름: 하트비트(Heartbeat)는 필수인가?

Q1. HTTP의 비연결성을 어떻게 극복할 것인가?

유저가 나갔다는 것을 서버가 즉시 알 방법은 없습니다. 따라서 유저가 주기적으로 "나 여기 살아있어요"라고 신호를 보내는 하트비트(Heartbeat) 방식은 필수적입니다.

Q2. 10만 명의 하트비트를 Redis가 버틸 수 있는가?

10만 명이 1초마다 Redis에 ZADD를 날리면 100,000 TPS입니다. 이는 Redis 단일 노드에 큰 부담을 줍니다.

• 해결책 (ROI 최적화): 유저는 1초마다 폴링(조회)을 오지만, 서버(WAS) 메모리에서 시간을 체크해 Redis 기록은 10초에 한 번만 수행하기로 했습니다. (부하 90% 절감)

3️⃣ 핵심 쟁점: 어떻게 지울 것인가? (방식 A vs 방식 B)

두 가지 선택지가 있습니다.

대안 1: 개별 키 TTL (Lease 방식)

• 생각: 유저마다 lease:userId 키를 만들고 30초 TTL을 건다. Redis가 알아서 지워주니 편하지 않을까?
• 한계: Redis가 키는 지워주지만, 대기열(ZSET) 내부의 유저 ID까지는 지워주지 않습니다. 결국 워커가 유저를 뽑을 때 일일이 EXISTS 명령어로 키가 살아있는지 확인해야 합니다. 100명을 뽑으려면 100번의 네트워크 왕복이 생깁니다.

대안 2: 하트비트 ZSET (벌크 관리 방식)

• 생각: 별도의 ZSET에 {유저ID: 마지막시간}을 몰아넣고 관리하면 어떨까?
• 장점: ZREMRANGEBYSCORE라는 강력한 명령어 한 줄로 **"지금 시각보다 30초 이전인 애들 싹 지워줘"**가 가능합니다. 수천 명을 단 1ms 만에 지울 수 있습니다.