⏰🚨 Enroll 동시성 테스트에서 신청이 거의 발생하지 않은 문제(JMeter)

2026. 2. 15. 17:20·프로젝트/스프링 부트 3 백엔드 개발자 되기 Blog + 선착순 강의 프로젝트

1️⃣ 문제 상황

Redis 기반 대기열 시스템에서 **동시성 테스트(JMeter)**를 진행했다.

테스트 시나리오:

  • 동시 사용자: 100명
  • 각 사용자:
    • enqueue 1회
    • SUCCESS가 나올 때까지 /queue/me 폴링
    • SUCCESS 시 enroll 요청

기대 결과:

  • 정원(capacity) 100명
  • 동시 신청 발생
  • DB에 정확히 100건 저장

그러나 실제 결과는:

  • 02_poll_me 요청은 약 19,000회 이상 실행됨
  • 하지만 03_enroll은 5회만 실행
  • H2 DB 확인 결과, ENROLLMENT 테이블에 5건만 저장됨
SELECT * FROM ENROLLMENT;

결과:

총 5건만 저장됨

즉, 동시성 테스트가 제대로 작동하지 않았다.


2️⃣ 문제 원인 분석

① HTTP 요청은 성공했지만, 실제 상태는 SUCCESS가 아니었음

JMeter에서 대부분의 02_poll_me 요청은 Success로 표시되었지만,

이는 HTTP 200 OK를 의미할 뿐,

대기열 상태가 SUCCESS라는 뜻은 아니었다.

View Results Tree에서 Response Data 확인 결과:

{"lectureId":1,"status":"QUEUED","position":586,"total":998}

대부분의 유저가 "status" : "QUEUED" 상태였다.

② 대기열 규모가 매우 컸음

응답 데이터 중:

"position":586,"total":998

이는 대기열에 약 1000명 가까이 쌓였다는 의미였다.

스케줄러 설정은:

@Scheduled(fixedDelay = 3000)intbatchSize=50;

즉,

  • 3초마다 50명 처리
  • 초당 약 16~17명 처리

1000명 처리하려면 약 60초 이상 소요된다.

③ JMeter 폴링 대기 시간이 부족했음

JMeter 설정:

  • Constant Timer: 200ms
  • maxLoop: 200

즉,

최대 대기 시간:

200 * 0.2초 = 40초

하지만 실제 대기열 처리에는 약 60초 이상 필요했다.

👉 대부분의 유저가 SUCCESS 상태가 되기 전에

👉 maxLoop가 0이 되어 폴링이 종료됨

👉 결국 enroll 요청이 거의 발생하지 않음

이것이 ENROLLMENT가 5건만 저장된 원인이었다.


3️⃣ 해결 과정

✅ 1. 폴링 최대 대기 시간 증가

기존:

maxLoop = 200

수정:

maxLoop = 800

→ 최대 대기 시간 약 160초 확보

✅ 2. 스케줄러 처리 속도 개선 (테스트용)

기존:

@Scheduled(fixedDelay = 3000)intbatchSize=50;

수정:

@Scheduled(fixedDelay = 1000)intbatchSize=50;

→ 초당 50명 처리

대기열 1000명도 약 20초 내 처리 가능

✅ 3. DB 초기화 후 재테스트

DELETE FROM ENROLLMENT;

UPDATE LECTURE
SET ENROLLED_COUNT=0, CAPACITY=100
WHERE ID=1;

이후 JMeter 재실행


4️⃣ 결과

테스트 완료 후 DB 확인:

SELECT COUNT(*)FROM ENROLLMENT;

결과:

100

실행:

SELECT ENROLLED_COUNT, CAPACITY FROM LECTURE WHERE ID=1;

결과:

ENROLLED_COUNT = 100 CAPACITY = 100

동시 사용자 수가 정원을 초과했음에도

DB에는 정확히 100건만 저장됨을 확인하였다.


5️⃣ 배운 점

🔎 1. HTTP 성공 ≠ 비즈니스 성공

JMeter에서 Success는 단순히 HTTP 200 OK일 뿐이다.

실제 상태 값(JSON의 status)을 반드시 확인해야 한다.

🔎 2. 부하 테스트는 “시스템 처리 속도”와 “대기 시간”을 함께 고려해야 한다

대기열이 크면 SUCCESS까지 시간이 오래 걸린다.

폴링 최대 횟수(maxLoop)가 충분하지 않으면 실제 동시성 테스트가 되지 않는다.

🔎 3. 동시성 테스트의 진짜 성공 기준은 DB 정합성이다

중요한 것은 JMeter의 응답 시간이 아니라,

  • ENROLLMENT 건수
  • ENROLLED_COUNT 값

이 정확히 정원(capacity)과 일치하는지 확인하는 것이다.

'프로젝트 > 스프링 부트 3 백엔드 개발자 되기 Blog + 선착순 강의 프로젝트' 카테고리의 다른 글

⏰💡 소셜 로그인 + 선착순 강의 신청 시스템 통합 (JWT 기반 userId 전환)  (1) 2026.02.23
⏰🚨 동시성 테스트 중 500 Internal Server Error 발생 원인과 해결  (1) 2026.02.23
⏰💡 Enroll 동시성 테스트 + 폴링 API 부하테스트 진행 방법(JMeter)  (0) 2026.02.15
⏰💡 폴링 API 부하 테스트 (500명 실험)  (0) 2026.02.15
⏰💡 JMeter 구성 요소 해석해보기  (1) 2026.02.15
'프로젝트/스프링 부트 3 백엔드 개발자 되기 Blog + 선착순 강의 프로젝트' 카테고리의 다른 글
  • ⏰💡 소셜 로그인 + 선착순 강의 신청 시스템 통합 (JWT 기반 userId 전환)
  • ⏰🚨 동시성 테스트 중 500 Internal Server Error 발생 원인과 해결
  • ⏰💡 Enroll 동시성 테스트 + 폴링 API 부하테스트 진행 방법(JMeter)
  • ⏰💡 폴링 API 부하 테스트 (500명 실험)
hak0622
hak0622
개발하면서 “이게 뭐지?”라는 순간마다 궁금한 점을 바탕으로 정리한 개발 블로그입니다.
  • hak0622
    궁금한 개발 이야기 Why?
    hak0622
  • 전체
    오늘
    어제
    • 분류 전체보기 (68)
      • 공부 (36)
        • 1. 자바 ORM 표준 JPA 프로그래밍 - 기본.. (35)
        • 시험 (1)
      • 프로젝트 (32)
        • 스프링 부트 3 백엔드 개발자 되기 Blog + .. (32)
  • 인기 글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.5
hak0622
⏰🚨 Enroll 동시성 테스트에서 신청이 거의 발생하지 않은 문제(JMeter)
상단으로

티스토리툴바