블랙프라이데이처럼 트래픽이 폭증하는 상황에서 Rate Limiting(즉시 거절)이 아니라 "대기"라는 선택지가 있다는 것을 배웠다. DB 커넥션 풀 50개, 주문 처리 200ms 기준으로 이론적 최대 250 TPS인데, 비주문 API 트래픽까지 고려하면 실효175TPS라는 숫자를 직접 산출해보면서 "시스템이 감당 가능한 속도"를 역산하는 사고방식이 생겼다.
Redis Sorted Set으로 대기열을 만들고, 스케줄러가 100ms마다 18명씩 토큰을 발급하고, Interceptor에서 토큰을 검증하는 파이프라인을 구현했다. 처음에는 1초에 175명을 한꺼번에 발급하려 했는데, 그러면 175명이 동시에 주문 API를 때리는 Thundering Herd가 발생한다는 걸 깨달았다. 1초를 10구간으로 쪼개서 18명씩 분산 발급하니까 DB 부하가 균등하게 퍼졌다.
이런 고민이 있었어요
ZADD NX(순번 유지)와 ZADD(새로고침 시 뒤로 밀림) 중 어떤 걸 선택할지 고민이 있었다. 내가 겪어본 대부분의 대기열 시스템(티켓팅, 한정 판매 등)은 새로고침하면 뒤로 밀리는 방식이었다. "새로고침하면 뒤로 밀린다"는 사실 자체가 코드 한줄 없이 재요청을 억제하는 가장 효과적인 수단이라고 판단해서 ZADD를 선택하였다.
10만 명이 2초마다 Polling하면 Redis에 초당 15만 명령이 날아가서 한계에 근접한다는 계산이 나왔다. 고정 주기 대신 Adaptive Polling을 적용해서 앞순번(1~100번)은 2초, 뒷순번(10,001번+)은 30초로 차등을 두니까 92% 감소한 1.2만 명령/초로 떨어졌다. 서버가 nextPollAfterSeconds를 응답에 포함해서 클라이언트의 Polling 주기를 제어하는 방식인데, 이런 서버 주도 back-pressure가 생각보다 강력했다.
앞으로 실무에 써먹을 수 있을 것 같은 포인트
대기열 시스템 관련된 도메인에서 근무하고 있지는 않지만 나중에라도 대기열을 접해야하는 상황이 온다면 어느 포인트를 잡고 설계 하고 트레이드 오프를 고민하면 좋을지 미리 학습할 수 있어서 좋았다.
DB 커넥션 풀 / 처리 시간 / 안전 마진"으로 실효 TPS를 역산하고, 거기서 배치 크기와 스케줄러 주기를 도출하는 과정이 인상적이었다. 앞으로 처리량 제어가 필요한 상황에서 감이 아니라 숫자로 설계할 수 있을 것 같다.
아쉬웠던 점 & 다음에 해보고 싶은 것
토큰 정리가 HTTP 200에서만 발생하도록 구현했는데, 주문이 400(유효성 실패)으로 실패하면 토큰이 남아있어서 active count가 계속 차 있게 된다. 토큰 TTL 300초가 지나면 자연 만료되긴 하지만, 그 사이에 신규 토큰 발급이 지연될 수 있다는 걸 분석 과정에서 알게 됐다. 성공이 아닌 경우에도 토큰을 어떻게 처리할지 좀 더 고민이 필요하다.
이직 첫 주차라 과제에 많이 몰입을 못했던 점이 굉장히 아쉬웠다. 무난하게 병행할 수 있을거라고 생각했는데 아무래도 새로 이직한 환경에 적응하려고 에너지를 많이 소비했다.. 루퍼스도 이제 얼마 안남았는데 잘 마무리 해야겠다...!!!
