[Spring Boot] 실전 프로젝트 고도화 (7): 1,000명 동시 접속에도 끄떡없는 서버 증명하기 (부하 테스트)

지난 포스팅 요약:

우리는 지난 글에서 Kafka를 도입해 비동기 아키텍처를 구축했습니다. 하지만 "이론상 빠르다"는 말은 누구나 할 수 있습니다. 오늘은 실제로 서버가 얼마나 튼튼한지 JMeter로 극한까지 몰아붙여 본 결과를 공개합니다.

---

1. 테스트 시나리오: "서버를 죽여보자"

단순히 기능이 동작하는지를 넘어, **시스템의 한계(Capacity)**를 측정하기 위해 공격적인 테스트 환경을 구성했습니다.

• Tool: Apache JMeter
• Users (Threads): 1,000명 동시 접속
• Requests: 유저당 10회 주문 (총 10,000건 요청)
• Data: User ID 1~1000번 랜덤 생성 (실제 유저 분포 시뮬레이션)
• 목표:
  1. 응답 속도: 사용자가 체감하는 대기 시간이 0.1초 미만일 것.
  2. 데이터 무결성: 10,000건 중 단 1건의 유실도 없을 것.
  3. 서버 안정성: 에러율(Error Rate) 0% 달성.

Jmeter

---

2. 1차 관문: 입구 속도 (Ingestion Performance)

먼저 사용자의 요청을 서버(Producer)가 얼마나 빨리 받아내는지 확인했습니다.

[JMeter Summary Report 결과]

• Throughput (TPS): 995.7/sec
  • 초당 약 1,000건의 주문을 문 앞에서 거절 없이 모두 받아냈습니다.
• Average Response Time: 13ms (0.013초)
  • 동기 방식(기존 6초) 대비 약 460배 빨라졌습니다. 사용자는 버튼을 누르자마자 "접수 완료"를 봅니다.
• Error Rate: 0.00%
  • 서버가 단 한 번도 뻗지 않았습니다.

---

3. 2차 관문: 진짜 처리 속도 (Processing TPS) 🔥

"접수만 빨리 받고 나중에 몰래 버리는 거 아냐?"라는 의심을 없애기 위해, DB에 실제로 저장되는 속도를 측정했습니다.

[DB 처리 속도 분석 SQL]

SQL

 

SELECT COUNT(*) / TIMESTAMPDIFF(SECOND, MIN(order_date), MAX(order_date)) as real_tps
FROM orders ...

• Ingestion TPS (입구): 995건/초
• Processing TPS (주방): 303건/초

💡 인사이트 (Engineering Insight):

이 수치의 차이가 바로 Kafka(메시지 큐)가 필요한 이유입니다.

만약 동기 방식이었다면, DB가 처리할 수 있는 한계인 303 TPS를 넘는 순간 서버가 터졌을 것입니다. 하지만 비동기 큐가 버퍼(Buffer) 역할을 해주었기에, 995개의 요청이 쏟아져도 DB는 자신의 페이스(303개)대로 안정적으로 처리할 수 있었습니다.

혹시나 10000개가 제대로 반영됐는지 확인하기 위한 쿼리문

---

4. 3차 관문: 데이터 정합성 검증 (Data Integrity)

비동기 시스템의 최대 난제인 **"데이터 유실"**과 **"로직 오류"**를 검증했습니다.

랜덤으로 선정된 500번 유저를 추적해 보았습니다.

[검증 결과]

1. Input (JMeter): 랜덤 함수 결과, 500번 유저는 총 11번 당첨됨.
2. Output (DB):
   • Orders 테이블 카운트: 11개 (주문서 유실 없음)
   • StockHolding 수량: 11개 (로직 누락 없음)

결론: 입력값과 출력값이 정확히 일치합니다. 데이터 유실률 0%를 증명했습니다.

---

5. 마치며: 6초에서 0.013초로

이번 부하 테스트를 통해 우리 시스템이 대규모 트래픽(High Traffic) 상황에서도 강력한 성능과 안정성을 유지함을 증명했습니다.

구분	변경 전 (동기)	변경 후 (비동기)	성과
응답 속도	6,000ms (6초)	13ms (0.013초)	99.7% 단축 🚀
처리 방식	사용자 대기 (Blocking)	즉시 응답 (Non-Blocking)	UX 개선
안정성	트래픽 폭주 시 장애 위험	버퍼링을 통한 DB 보호	장애 예방

이제 기능과 성능, 두 마리 토끼를 모두 잡았습니다.