[K6] 대용량 엑셀 다운로드 API 부하 테스트 - XSSF vs SXSSF 성능 비교 - 1편

[K6] 대용량 엑셀 다운로드 API 부하 테스트 - XSSF vs SXSSF 성능 비교 - 1편

목차

1. 테스트 배경
2. 테스트 환경
3. 테스트 시나리오
4. 결과 — XSSF (레거시)
5. 결과 — SXSSF (개선)
6. 비교 분석
7. 한계 및 다음 과제

 

1. 테스트 배경

파이널 프로젝트에서 구현한 호텔 예약 내역 엑셀 다운로드 기능에 대해, XSSF → SXSSF 리팩토링을 통해 메모리 구조를 개선하였음. 다만 구조 개선만으로는 실제 성능이 어떻게 달라졌는지 정량적으로 확인하기 어려웠음. 따라서 K6를 활용하여 리팩토링 전/후 성능을 수치로 비교하고자 함. 리팩토링 상세 내용은 하기 링크에 첨부함.

 

참고 : 

https://lhk9311.tistory.com/4

[Spring/Java] 대용량 엑셀 다운로드 시 OOM(OutOfMemoryError) 해결 : Apache POI XSSF에서 SXSSF로 리팩토링

---

 

2. 테스트 환경

항목	내용
부하 도구	K6 v1.7.1
서버	Spring Boot 3.4.5 , 로컬 (port 9081)
DB	Oracle XE, 예약 데이터 10,112건
테스트 대상 API	GET /admin/reservation/excel

---

 

3. 테스트 시나리오

export const options = {
  stages: [
    { duration: '1m', target: 3 },   // 3명까지 ramp-up
    { duration: '3m', target: 3 },   // 3명 유지
    { duration: '1m', target: 10 },  // 10명까지 올리기
    { duration: '2m', target: 10 },  // 10명 유지
    { duration: '1m', target: 0 },   // 종료
  ],
  thresholds: {
    http_req_duration: ['p(95)<10000'],  // p95 10초 이내
    http_req_failed: ['rate<0.05'],      // 실패율 5% 미만
  },
};

 

VU(가상 사용자)를 3명 → 10명으로 단계적으로 올려서 동시 접속 상황을 재현함.(10명이 동시에 엑셀 다운로드 클릭)

※ VU(Virtual User) = 동시에 요청을 날리는 가상 사용자 수

 

 

4. 결과 - XSSF (레거시)

주요 수치 :

지표	값
평균 응답시간 (avg)	236ms
p95 응답시간	501ms
최대 응답시간 (max)	2.16s
에러율	0%
총 요청 처리 수	10,615건
임계값 통과 여부	통과

 

XSSF 처리 방식

DB에서 10,112건 전체 조회
→ Java 힙 메모리에 전부 적재
→ XSSFWorkbook으로 Excel 생성
→ 응답

---

 

5. 결과 - SXSSF (개선)

 

주요 수치 :

지표	값
평균 응답시간 (avg)	38.79s
p95 응답시간	46.29s
최대 응답시간 (max)	48.15s
에러율	0%
총 요청 처리 수	68건
임계값 통과 여부	❌ 초과

 

※ 임계값 통과 여부 : 내가 설정한 기준(p95가 10초(10000ms) 미만이어야 한다)에 미달되어서 실패한 것. 임계값은 실제 서비스 허용 기준에 맞게 설정해야함.

 

SXSSF 처리 방식 :

DB에서 1,000건씩 페이징 조회 (총 11회)
→ 조회 즉시 Excel Row 작성
→ 메모리에는 항상 100행만 유지
→ 응답

---

 

6. 비교

항목	XSSF	SXSSF
평균 응답시간	236ms ✅	38.79s ❌
p95 응답시간	501ms ✅	46.29s ❌
에러율	0% ✅	0% ✅
총 요청 처리수	10,615건	68건
메모리 안전성	❌ 위험	✅ 안전

 

※ p95 : 대부분 사용자(95%)가 경험하는 최대 응답시간

※ 평균 응답시간(파일 받는데 걸리는 시간)이 XSSF는 0.236초 vs SXSSF는 38.78초 걸림.

 

※ 총 요청 처리 수 : 8분 동안 K6가 날린 요청 횟수(엑셀 파일 안의 데이터 건수가 아님)

- XSSF 10,615건 = 8분 동안 엑셀 파일을 10,615번 요청함

- SXSSF 68건 = 응답이 느려서 8분 동안 68번밖에 처리 못함

 

테스트 전 예상은 SXSSF가 더 빠를 것이라고 생각했으나, 결과는 반대였음. 로컬에서 SXSSF가 더 느린 이유는 DB를 1,000건씩 나눠서 총 11번 조회하면서 DB 왕복 횟수가 증가 + sleep 없이 동시 요청이 몰리면서 누적되기 때문으로 추정됨.(반면 XSSF가 0.236초로 빠른 이유는 로컬 개발 환경이 메모리가 충분 (16GB+)하여 10,112건을 한 번에 올려도 OOM이 발생하지 않고, DB 조회가 1번으로 끝나서 왕복 횟수가 적기 때문으로 추정됨.)

XSSF = DB 1번 조회 → 끝
SXSSF = DB 11번 조회 → 각 1000건씩 → 즉시 Row 작성 → 반복

---

리팩토링을 한 후 기존 예상과 다름에도 SXSSF를 선택해야 하는 이유는 로컬 환경과 달리 실제 운영 서버 (AWS EC2 t2.micro 기준 메모리 1GB)에서는 상황이 달라지기 때문임.

 

운영 서버 환경에서의 예상 시나리오

XSSF로 동시 5명 요청 시:
→ 10,112건 전체를 5명이 동시에 메모리에 올림
→ Heap 메모리 급증
→ 운영 서버에서 OOM 발생 가능성 높음 

SXSSF:
메모리에 항상 100행만 유지
→ 동시 요청이 몰려도 서버가 죽지 않음 

 

결론 : XSSF vs SXSSF는 "속도 vs 안전성"의 트레이드오프 관계인 것으로 보임. 서버 안정성 측면에서 SXSSF가 운영 환경에 적합하나, 응답 시간이 느려진 부분은 추가 개선이 필요함.

 

---

 

7. 한계 및 다음 과제

현재 테스트는 로컬 환경 메모리가 충분하여 XSSF의 OOM을 재현하지 못함. 메모리가 제한된 운영 서버에서 다시 테스트를 해야할 필요가 있음. 다음 과제로는 AWS 배포 후 동일 시나리오로 재검증을 할 계획임. 이후, InfluxDB + Grafana 연동으로 시각화를 시도해볼 예정임. 

 

※ InfluxDB = K6 부하테스트 결과를 시간 순서대로 저장하는 DB

Grafana = 저장된 데이터를 그래프로 시각화하는 도구

 

+ SXSSF 응답시간이 느린 부분에 대한 개선으로는 다음 세 가지가 있음.

1. DB 인덱스 추가 → created_at, reservation_status 컬럼 인덱스 추가로 페이징 쿼리 속도 개선 가능

2. 커넥션 풀 튜닝 → HikariCP maximum-pool-size 조정으로 DB 연결 대기시간 단축 가능

3. 비동기 처리 → 엑셀 생성을 백그라운드에서 처리 후 다운로드 링크를 제공하는 방식으로 전환 시 사용자 체감 응답시간 대폭 개선 가능

 

이부분을 위주로 보완이 필요함 !

 

다음편:

https://lhk9311.tistory.com/10

[K6] 대용량 엑셀 다운로드 API 부하 테스트 - XSSF vs SXSSF 성능 비교 - 2편 (feat. AWS 배포 환경 재검증)