⏰💡 폴링 API 부하 테스트 (500명 실험)

선착순 강의 시스템에서 가장 우려했던 부분은 “폴링 트래픽”이었다.

 

사용자는 대기 중일 때 1초마다 자신의 순번을 확인한다.
동시 사용자가 많아질수록 이 폴링 요청은 기하급수적으로 늘어난다.

 

그래서 단순히 “잘 되겠지”가 아니라,
실제로 JMeter를 통해 부하 테스트를 진행했다.

---

1️⃣ 테스트 시나리오

• 동시 사용자: 500명
• Ramp-up: 50초
• 사용자 행동:
  1. 대기열 등록 1회
  2. 1초 간격으로 30회 폴링

즉,

500명이 동시에 줄 서고,
1초마다 내 순번을 계속 조회하는 상황을 재현했다.

---

2️⃣ 테스트 결과

📌 enqueue (대기열 등록)

Samples: 901
Avg: 3ms
Max: 11ms
Error: 0%

해석

• 평균 3ms
• 최대 11ms
• 에러 0%

대기열 등록은 Redis ZSET에 insert하는 단순 연산이기 때문에
사용자가 500명으로 늘어도 병목은 거의 발생하지 않았다.

 

👉 대기열 등록 자체는 시스템 병목이 아님을 확인.

📌 poll_me (폴링 API)

Samples: 27,003
Avg: 1ms
Max: 57ms
Error: 0%
Throughput: 약 16 req/sec

이 테스트의 핵심은 여기다.

✔ 요청 수

약 27,000건의 폴링 요청이 발생했다.

 

즉, 짧은 시간 안에 수만 건의 조회 요청이 들어온 상황이다.

✔ 평균 응답 시간

평균 1ms 유지.

 

Redis ZSET에서 ZRANK로 순번을 조회하는 구조이기 때문에
조회 비용이 매우 낮게 유지되었다.

✔ 최대 응답 시간

• 100명 테스트: 약 10ms
• 300명 테스트: 31ms
• 500명 테스트: 57ms

동시 사용자가 증가함에 따라 최대 지연 시간이 점진적으로 증가했다.

하지만:

• 500명에서도 100ms 미만
• 에러 발생 없음

👉 지연은 증가했지만, 폭발적 증가가 아니라 선형적 증가

---

3️⃣ 무엇을 검증했는가?

이 실험의 목적은 단순히 “숫자 자랑”이 아니었다.

확인하고 싶었던 건 다음이었다.

1) 동시 사용자가 늘어나도 서버가 안정적인가?

→ Error 0%

2) 폴링 요청이 서버를 압박하지 않는가?

→ 평균 1ms 유지

3) 부하 증가에 따른 응답 지연이 통제 가능한 수준인가?

→ 100명 → 300명 → 500명
→ 최대 지연이 점진적으로 증가

 

폭발적 상승이나 장애는 발생하지 않았다.

---

4️⃣ 왜 이런 결과가 나왔을까?

이유는 설계에 있다.

✔ 폴링은 DB가 아니라 Redis에서 처리

• ZRANK 기반 조회
• 인메모리 연산
• 트랜잭션 없음

✔ 대기열 처리와 확정 처리를 분리

• Redis: 대기열 & 순번 조회
• DB: 실제 신청 확정

즉,

“읽기 트래픽”은 Redis가 처리하고
DB는 확정 단계에서만 사용한다.

이 구조 덕분에 폴링 트래픽이 증가해도
DB 병목이 발생하지 않았다.

---

5️⃣ 테스트를 통해 얻은 결론

• 500명 동시 사용자 환경에서
• 약 27,000건 이상의 폴링 요청을 처리
• Error 0%
• 평균 응답 1ms 유지
• 최대 응답 57ms

부하가 증가해도 시스템은 안정적으로 동작했다.

이 실험을 통해:

“폴링 구조가 실제 트래픽 환경에서도 충분히 감당 가능하다”는 확신을 얻었다.