부하 테스트: 유저 행동 기반 시나리오로 시스템 한계 측정과 SLA, SLO 검증

 

들어가며

부하 테스트는 시스템의 최대 처리량(TPS), 안정성, SLA(서비스 수준 계약) 및 SLO(서비스 수준 목표)를 검증하는 중요한 과정입니다. 이번 글에서는 콘서트 예약 서비스에서 유저 행동을 기반으로 한 두 가지 시나리오를 중심으로, Docker 환경에서 자원을 조절하며 성능 테스트를 수행한 내용을 정리해보겠습니다.

 

 

 

1. 테스트 시나리오 설계

유저의 행동을 기반으로 두 가지 테스트 시나리오를 설계했습니다. 각각의 시나리오는 시스템의 서로 다른 상태(유저 비활성/유저 활성)를 테스트하기 위해 선정했습니다.

 

- 시나리오 1 : 유저 대기열 비활성

• 목표: 대기열 시스템에서 토큰 발급 및 상태 조회의 처리량 측정
• 행동 흐름
  1. 유저가 대기열 토큰 발급 요청
  2. 유저가 1초 간격으로 토큰 상태 조회
• 중점
  • 대기열 시스템의 안정성 확인
  • 단순 조회 작업에서의 최대 TPS 및 평균 RPS 측정

 

- 시나리오 2 : 유저 대기열 활성

• 목표: 콘서트 예약 및 결제 과정의 처리량 측정
• 행동 흐름
  1. 유저가 콘서트 정보를 조회
  2. 유저가 특정 회차의 좌석 정보를 조회
  3. 유저가 좌석 예약 요청
  4. 유저가 예약 결제 요청
• 중점
  • 복잡한 트랜잭션(예약 및 결제) 처리에서의 안정성 확인
  • 여러 API 호출이 연속적으로 이루어지는 시나리오의 TPS/RPS 측정
• 특이사항
  • 하나의 콘서트 스케줄에 대한 좌석을 5만 개로 설정했습니다. 이는 실제 콘서트가 경기장에서 열릴 때를 고려하여 설정했습니다.

 

 

 

2. 테스트 환경

 

AWS 등 외부 클라우드 비용을 절약하기 위해, 로컬 Docker 환경에서 테스트를 진행했습니다.

 

- 환경 구성

• Docker Compose로 실행
  • Spring Boot 애플리케이션
  • MySQL
  • Kafka
  • Redis
• 리소스 제한
  • CPU: 0.5 vCPU ~ 2 vCPU
  • 메모리: 512M ~ 4G

 

- 테스트 도구

• k6
  • 부하 테스트 스크립트 작성 및 실행
  • 목표 TPS 설정과 SLO 검증
• Prometheus + InfluxDB + Grafana
  • Spring Boot Actuator와 연동해 메트릭 수집 및 시각화
  • k6 결과와 함께 성능 모니터링

 

 

3. 목표와 검증 기준

 

- 시스템 한계 측정

테스트의 주요 목표는 다음과 같습니다:

1. 최대 TPS: 시스템이 동시에 처리할 수 있는 요청의 최대 개수
2. 평균 TPS: 지속적인 부하 상황에서 처리 가능한 평균 요청 개수
3. 평균 RPS (Requests Per Second): 초당 요청 처리량

 

- SLA / SLO 기준

서비스의 품질 목표를 다음과 같이 설정했습니다:

1. SLO
   • p99 응답 시간: 400ms 이하
   • 성공률: 99% 이상
2. SLA
   • 평균 응답 시간: 200ms 이하
   • 초당 요청 처리량: 최소 50 TPS
   • 최대 부하 조건에서 서비스 중단 발생률: 0%

 

 

 

4. 테스트 설계와 스크립트

 

- 테스트 설계

각 테스트는 시나리오 별 Docker 리소스 스펙(3개)와 테스트 전략(2개)의 조합으로 총 6개로 설정했습니다.

 

1. Docker 스펙

• 0.5vCPU, 512MB
• 1vCPU, 1GB
• 2vCPU, 2GB

2. 테스트 전략

• VU 증가 테스트 - 점진적 증가로 최대 처리량 확인

export let options = {
    stages: [
        { duration: '10s', target: 10 },  // 10초 동안 10 VU로 증가
        { duration: '10s', target: 30 },  // 10초 동안 30 VU로 증가
        { duration: '10s', target: 50 },  // 10초 동안 50 VU로 증가
        { duration: '10s', target: 100 }, // 10초 동안 100 VU로 증가
        { duration: '10s', target: 200 }, // 10초 동안 200 VU로 증가
        { duration: '10s', target: 0 },   // 10초 동안 0으로 감소
    ],
    thresholds: {
        http_req_duration: ['p(99)<400'], // p99가 400ms 이하
        http_req_failed: ['rate<0.01'],   // 실패율이 1% 이하
    },
};

 

• 스파이크 테스트 - 갑작스러운 부하 복원 능력 확인

export let options = {
    stages: [
        { duration: '10s', target: 100 },  // 10초 동안 100 VU
        { duration: '10s', target: 1000 }, // 10초 동안 1000 VU로 급증
        { duration: '30s', target: 100 },  // 30초 동안 100 VU로 감소
    ],
    thresholds: {
        http_req_duration: ['p(99)<400'], // p99 응답 시간 조건
        http_req_failed: ['rate<0.05'],   // 실패율 조건 (스파이크에서는 5% 허용)
    },
};

 

 

 

- 시나리오 1: 유저 비활성

 

유저 토큰 발급 -> 토큰 상태 조회 (1초 간격으로 5회 반복)

export default function () {
    // 토큰 발급
    let token = getWaitingToken()
    
    // 토큰 상태 조회
    for (let i = 0; i < 5; i++) { // 5회 반복
        getQueueStatus(token)
        sleep(1);
    }
}

 

 

1. 1vCPU, 512MB & VU 증가 테스트

 

 

2. 2vCPU, 1GB & VU 증가 테스트

 

 

3. 2vCPU, 2GB & VU 증가 테스트

 

 

 

5.1vCPU, 512MB & 스파이크 테스트

 

 

5. 2vCPU, 1GB & 스파이크 테스트

 

 

6. 2vCPU, 2GB & 스파이크 테스트

 

 

 

 

 

 

 

- 시나리오 2: 유저 활성

활성 토큰 발급 -> 좌석 조회 -> 좌석 예약 -> 결제

export default function () {
    let token = getActiveToken();

    getConcertSeats(token);
    sleep(2);
    let reservationId = reserveSeat(token);
    sleep(2);
    processPayment(token, reservationId);
    sleep(2);
}

 

 

 

문제 발생

 

시나리오 2의 경우, 해당 콘서트 스케줄에 대한 모든 좌석을 조회하는 로직이 포함되어 있습니다. 시나리오 1과 동일한 조건에서 테스트 해본 결과 아래와 같이 힙 메모리 공간이 부족하여 애플리케이션이 종료되고 말았습니다.

 

2024-11-29 00:22:12 2024-11-28T15:22:11.293Z ERROR 1 --- [concert-reservation] [io-8080-exec-32] h.c.i.api.GlobalExceptionHandler         : Exception: [INTERNAL_SERVER_ERROR] CannotCreateTransactionException - An unexpected error occurred..
2024-11-29 00:22:12 
2024-11-29 00:22:12 org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction
2024-11-29 00:22:12     at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:466) ~[spring-orm-6.1.13.jar!/:6.1.13]


...
2024-11-29 00:22:13 Caused by: java.lang.OutOfMemoryError: Java heap space

...

2024-11-29 00:22:13 2024-11-28T15:22:11.296Z ERROR 1 --- [concert-reservation] [io-8080-exec-47] h.c.i.api.GlobalExceptionHandler         : Exception: [INTERNAL_SERVER_ERROR] CannotCreateTransactionException - An unexpected error occurred..
2024-11-29 00:22:13 
2024-11-29 00:22:13 org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction

...

2024-11-29 00:22:13 Caused by: org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection [HikariPool-1 - Connection is not available, request timed out after 20436ms (total=23, active=23, idle=0, waiting=24)] [n/a]

...

2024-11-29 00:23:34 org.springframework.orm.jpa.JpaSystemException: JDBC exception executing SQL [/* <criteria> */ select s1_0.`id`,s1_0.`created_at`,s1_0.`price`,s1_0.`schedule_id`,s1_0.`seat_number`,s1_0.`status`,s1_0.`updated_at`,s1_0.`version` from `seat` s1_0 where s1_0.`schedule_id`=?] [Java heap space] [n/a]

 

캐시 적용, Hikari 커넥션 풀 개수 증가 등 해결 방법을 모색해보았지만 그에 따른 사이드 이펙트가 존재하여 해당 시나리오는 컨테이너의 자원을 2vCPU, 4GB로 고정하고, 시나리오도 아래와 같이 변경하여 진행하였습니다. 추후 해당 문제에 대해 분석해볼 예정입니다.

 

export let options = {
  stages: [
    { duration: '10s', target: 10 },  // 10초 동안 10 VU로 증가
    { duration: '10s', target: 15 },  // 10초 동안 20 VU로 증가
    { duration: '10s', target: 20 },  // 10초 동안 30 VU로 증가
    { duration: '10s', target: 25 }, // 10초 동안 50 VU로 증가
    { duration: '10s', target: 30 }, // 10초 동안 50 VU로 증가
    { duration: '10s', target: 0 },   // 10초 동안 0으로 감소
  ],
  thresholds: {
      http_req_duration: ['p(99)<400'], // p99가 400ms 이하
      http_req_failed: ['rate<0.01'],   // 실패율이 1% 이하
  },
};

 

 

 

1. 2vCPU, 4GB & VU 증가 테스트

 

 

 

 

 

5. 테스트 결과와 분석

 

- Docker 리소스 조정과 테스트 전략에 따른 성능

Docker 스펙	테스트 전략	p95 응답 시간(ms)	최대 RPS	성공률(%)
1vCPU, 512MB	VU 증가 테스트	13.1	239	100%
1vCPU, 512MB	스파이크 테스트	3830	555	100%
2vCPU, 1GB	VU 증가 테스트	5.26	239	100%
2vCPU, 1GB	스파이크 테스트	1150	950	100%
2vCPU, 2GB	VU 증가 테스트	6.69	240	100%
2vCPU, 2GB	스파이크 테스트	1420	948	100%

 

 

- 분석

1. 1vCPU, 512MB 리소스 환경

• VU 증가 테스트
  • p95 응답 시간은 13.1ms로 매우 우수하며, SLO 기준(p99 < 400ms) 충족
  • 최대 RPS 239로 동시 요청 처리량은 제한적
  • 제한된 리소스 내에서는 CPU와 메모리 사용량이 안정적
• 스파이크 테스트:
  • p95 응답 시간이 3830ms로 SLO 기준 미달
  • 순간 부하에서 CPU와 메모리 부족으로 인해 처리 속도 저하 및 병목 발생

 

2. 2vCPU, 1GB 리소스 환경

• VU 증가 테스트
  • p95 응답 시간이 5.26ms로 매우 우수하며, 모든 SLO/SLA 기준 충족
  • 최대 RPS 239로 동시 요청 처리량은 제한된 환경과 동일하지만, CPU와 메모리 사용량이 여유로움
• 스파이크 테스트
  • p95 응답 시간이 1150ms로 SLO 기준 미달
  • 최대 RPS 950으로 스파이크 부하를 처리할 수 있으나, 연결 병목이 발생
  • 동시 요청 처리량 증가 시 I/O 병목으로 인해 응답 속도가 느려짐

3. 2vCPU, 2GB 리소스 환경

• VU 증가 테스트
  • p95 응답 시간이 6.69ms로 매우 우수하며, 모든 SLO/SLA 기준 충족
  • 최대 RPS 240으로 동시 요청 처리량이 안정적
  • 부하 분산이 잘 이루어졌으며, 병목 없이 처리 가능
• 스파이크 테스트
  • p95 응답 시간이 1420ms로 SLO 기준 미달
  • 최대 RPS 948로 높은 트래픽을 처리할 수 있으나, 순간적인 요청 폭주에서 지연 발생
  • I/O 처리 병목으로 인한 지연 가능성

4. 시나리오 2 미해결 문제

• 높은 스파이크 트래픽을 처리하는 데 있어 모든 환경에서 Redis나 DB 연결 병목이 발생 가능
• Redis 커넥션 풀 부족 또는 DB의 트랜잭션 처리 한계가 병목의 주요 원인일 가능성이 높음
• 제한된 CPU/메모리에서 스파이크 트래픽 시 병목 현상이 심화됨

 

 

 

6. 결론

 

• 시스템 한계 측정
  • 제한된 리소스 환경에서는 CPU와 메모리 부족이 성능 병목의 주요 원인
  • DB 커넥션 풀 크기 증가 및 쿼리 최적화 필요
• SLA/SLO 검증
  • 2vCPU, 2GB 환경에서 최대 TPS 948과 평균 응답 시간 200ms 이하로 SLO 기준 충족
  • VU 증가 테스트에서는 SLO 기준을 모두 충족했으나, 스파이크 부하에서는 모두 성능 병목이 발생
• 향후 계획
  • AWS 환경에서 실제 배포를 시뮬레이션하여 더 높은 트래픽 처리 성능을 검증
  • 캐싱, 비동기 처리, 데이터베이스 최적화 등으로 성능을 추가 개선

 

 

마치며

이번 테스트를 통해 Docker 환경에서 자원 조절과 부하 테스트 조합으로 시스템의 안정성과 성능 한계를 확인할 수 있었습니다. 실제 운영 환경에서도 성능을 개선하기 위해 어떤 점을 고려해야 할 지 생각해 볼 수 있는 시간이었습니다.

기본 함수 내보내기() { let token = getActiveToken(); getConcertSchedules(토큰); 수면(1); getConcertSeats(토큰); 수면(1); bookingId = ReserveSeat(token); 수면(2); processPayment(토큰, 예약 ID); 수면(2); }