🔧 k6 부하테스트

1. 부하 테스트 대상 선정 및 목적

• 테스트 대상:

  • 대기열 서비스의 조회 API를 대상으로 진행되었습니다.
  • 토큰 생성, 대기열 정보 조회, 콘서트 일정 및 좌석 조회, 좌석 예약 API가 대상이었습니다.

• 테스트 목적:

  • 서비스의 성능 측정: 동시 사용자 수가 급증할 때 시스템의 반응 시간 및 안정성을 확인하고, 서버의 처리 능력을 평가합니다.
  • 서비스의 처리 능력 파악: 시스템이 100명의 가상 사용자(VUs)로 부하를 처리할 수 있는지 확인하고, 요청 처리 시간, 오류율 등을 분석합니다.
  • 최적화 필요성 분석: 응답 시간이 길어지거나 오류가 발생할 경우, 서버의 리소스 확장이나 최적화가 필요한지 파악합니다.

---

2. 부하 테스트 시나리오

• 테스트 대상: 대기열 서비스 (최대 100명 동시 접속, 활성화된 대기열 토큰 10명)
• 시나리오 기간: 20초 동안 가상 사용자가 루프 방식으로 요청을 반복하며 실행됩니다.
• 컨테이너 리소스 제한:
  • 테스트 중인 Spring 애플리케이션의 Docker 컨테이너는 2 CPU와 4GB 메모리로 리소스가 제한되어 있습니다.
  • 이를 통해 테스트 기간 동안 서버의 리소스를 관리하고, 과도한 리소스 소비를 방지하기 위해 리소스를 일정 범위 내로 유지하도록 설정되었습니다.

시나리오 세부 동작:
1. 토큰 생성 API 호출 - 사용자가 콘서트 예약을 시작하기 전에 토큰을 생성합니다.
2. 대기열 정보 API 호출 - 대기열에 대한 정보를 조회합니다.
3. 콘서트 일정 조회 API 호출 - 사용자가 원하는 콘서트의 일정을 확인합니다.
4. 콘서트 좌석 조회 API 호출 - 사용자가 원하는 콘서트의 좌석 정보를 조회합니다.
5. 콘서트 좌석 예약 API 호출 - 사용자가 원하는 콘서트의 좌석을 예약합니다.

스크립트

import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
    vus: 100, // 동시 요청 수
    duration: '20s', // 테스트 지속 시간
};

export default function () {
    const userId = Math.floor(Math.random() * 100000) + 1;
    const tokenUrl = `http://localhost:8082/api/queue/tokens/users/${userId}`;

    // 1. 대기열 토큰 생성 요청
    const tokenHeaders = {
        'Content-Type': 'application/json',
    };

    const tokenResponse = http.post(tokenUrl, JSON.stringify({}), { headers: tokenHeaders });

    check(tokenResponse, {
        'Token creation is status 200': (r) => r.status === 200,
    });

    if (tokenResponse.status !== 200) {
        console.error(`Failed to create token for userId: ${userId}, Status: ${tokenResponse.status}`);
        sleep(1);
        return;
    }

    const tokenData = tokenResponse.json();
    const queueToken = tokenData.queueToken; // 생성된 대기열 토큰

    // 2. 대기열 정보 폴링 조회
    const queueInfoUrl = 'http://localhost:8082/api/queue/tokens/users';
    const queueInfoHeaders = {
        'Content-Type': 'application/json',
        'QUEUE-TOKEN': queueToken, // 대기열 토큰 설정
    };

    let queuePosition = -1;
    let queueInfoResponse;

    // 대기열 상태가 -1이 아닐 경우 계속 폴링하여 상태 확인
    while (queuePosition !== -1) {
        queueInfoResponse = http.get(queueInfoUrl, { headers: queueInfoHeaders });

        check(queueInfoResponse, {
            'Queue info is status 200': (r) => r.status === 200,
        });

        if (queueInfoResponse.status !== 200) {
            console.error(`Failed to fetch queue info with token: ${queueToken}, Status: ${queueInfoResponse.status}`);
            sleep(1);
            return;
        }

        const queueInfo = queueInfoResponse.json();
        queuePosition = queueInfo.queuePosition;

        if (queuePosition !== -1) {
            console.log(`Waiting for position to be -1, current position: ${queuePosition}`);
            sleep(3); // 일정 시간 후 다시 대기열 상태를 확인
        }
    }

    // 3. 콘서트 스케줄 조회
    const concertScheduleUrl = 'http://localhost:8082/api/concerts/1/schedules';
    const concertScheduleHeaders = {
        'Content-Type': 'application/json',
        'QUEUE-TOKEN': queueToken, // 대기열 토큰 설정
    };

    const concertScheduleResponse = http.get(concertScheduleUrl, { headers: concertScheduleHeaders });

    check(concertScheduleResponse, {
        'Concert schedule is status 200': (r) => r.status === 200,
    });

    if (concertScheduleResponse.status !== 200) {
        console.error(`Failed to fetch concert schedule with token: ${queueToken}, Status: ${concertScheduleResponse.status}`);
        sleep(1);
        return;
    }

    // 4. 콘서트 좌석 정보 조회
    const concertSeatsUrl = 'http://localhost:8082/api/concerts/1/schedules/1/seats';
    const concertSeatsHeaders = {
        'Content-Type': 'application/json',
        'QUEUE-TOKEN': queueToken, // 대기열 토큰 설정
    };

    const concertSeatsResponse = http.get(concertSeatsUrl, { headers: concertSeatsHeaders });

    check(concertSeatsResponse, {
        'Concert seats is status 200': (r) => r.status === 200,
    });

    if (concertSeatsResponse.status !== 200) {
        console.error(`Failed to fetch concert seats with token: ${queueToken}, Status: ${concertSeatsResponse.status}`);
        sleep(1);
        return;
    }

    // 5. 좌석 예약 요청
    const reservationUrl = 'http://localhost:8082/api/reservations';
    const reservationHeaders = {
        'Content-Type': 'application/json',
        'QUEUE-TOKEN': queueToken,
    };

    const seatNumber = Math.floor(Math.random() * (172 - 120 + 1)) + 120;
    const seatIdsArr = [seatNumber];

    const reservationPayload = JSON.stringify({
        concertId: 1,
        scheduleId: 1,
        seatIdsArr: seatIdsArr, // 배열로 설정
        userId: userId
    });

    const reservationResponse = http.post(reservationUrl, reservationPayload, { headers: reservationHeaders });

    check(reservationResponse, {
        'Reservation is status 200': (r) => r.status === 200,
    });

    if (reservationResponse.status === 200) {
        console.log(`Reservation succeeded for userId: ${userId}, Seats: ${seatIdsArr}`);
    } else {
        console.error(`Reservation failed for userId: ${userId}, Status: ${reservationResponse.status}`);
        console.error(`Reservation failed. Response: ${reservationResponse.body}`);
    }

    sleep(1); // 요청 간 간격
}

3.부하 테스트 결과

지표	값
성공적인 요청 비율	50.94% (1028/2018)
성공적인 요청 (200 OK)	90% (9/10)
HTTP 요청 실패 비율	49.05% (990/2018)
평균 응답 시간	518.26ms
최대 응답 시간	6.3s
요청 수 (전체)	2018
요청 성공 비율	50.94%
동시 사용자 (VUs)	평균 31명, 최대 100명
테스트 진행 시간	평균 2.06초

4. 성능 지표 분석

4.1. 성공적인 요청 비율

• 테스트에서 50.94%의 성공 요청 비율은 대기열에서 동시 처리할 수 있는 활성 사용자 수의 제한으로 인해 일부 요청에서 실패가 발생하였습니다.
• 콘서트 일정 조회 API에서 활성화된 대기열 토큰 10명이기에 10개만 성공하는 것은 정상 응답입니다.
• 예약 API에서 10개 중 9개는 정상 처리되었고, 나머지 1개는 동일한 좌석에 대해 동시에 예약 요청이 들어와 실패했습니다. 이는 동시성 문제로 인해 발생한 정상적인 처리로, 2개 중 하나만 예약이 성공한 상황입니다.

4.2. 응답 시간

• 평균 응답 시간은 518.26ms였고, 최대 응답 시간은 6.3초로 상당히 큰 차이를 보였습니다.
• 일부 요청이 과도하게 긴 시간을 소요하는 경우가 있음을 알 수 있었습니다.

4.3. HTTP 요청 실패

• 요청 실패 비율이 49.05%로, 전체 테스트에서 상당히 높은 실패율을 보였습니다.
• 요청 실패의 주요 원인으로는 데이터베이스 연결이나 대기열 처리 로직에서의 동시성 문제, 리소스 부족 등이 있을 수 있습니다.

3.4. 동시 사용자 수

• 테스트에서는 최대 100명의 사용자가 동시 접속하였으며, 평균적으로 31명이 동시에 요청을 보냈습니다. 이는 성능에 직접적인 영향을 미치는 지표로, 시스템의 부하를 나타냅니다.
• 동시 사용자 수가 늘어날수록 시스템에 과부하가 걸릴 수 있음을 확인할 수 있었습니다.

5. 시스템 병목 탐색

5.1. 응답 시간 분석

• 응답 시간이 길어진 요청을 분석해보면, 대기열 처리 로직에서 문제가 발생한 경우가 있었습니다.
• 여러 요청이 동시에 대기열에 접근하려고 시도하면서 발생하는 동시성 문제로 인해 일부 요청이 대기 상태에서 길어졌을 수 있습니다.
• 데이터베이스 연결이나 대기열 처리에서의 Lock 문제도 병목의 원인일 수 있습니다.

5.2. 데이터베이스 연결 부족

• JDBC 연결 풀에서 자원 고갈 문제가 발생했었습니다. HikariPool-1 - Connection is not available 오류가 발생한 이유는 데이터베이스 연결 풀 크기가 너무 작거나, 동시 접속 사용자가 많아지면서 커넥션 풀이 고갈되었기 때문입니다.
• 커넥션 풀 설정을 최대 크기 증가 및 타임아웃을 조정하여 데이터베이스 연결 문제를 해결할 수 있었습니다.

6. 성능 개선 방안

6.1. 동시성 처리 개선

• 대기열 상태 관리 로직 개선: 대기열을 효율적으로 관리하기 위해 동시성 제어 및 스케줄링 알고리즘을 개선하여 요청을 빠르게 처리할 수 있도록 개선합니다.

6.2. 데이터베이스 연결 풀 조정

• 커넥션 풀 크기 증가: 현재 커넥션 풀 설정이 부족하여 JDBCConnectionException이 발생하였으므로, 커넥션 풀 크기를 늘리고 타임아웃 설정을 조정합니다.
• HikariCP 설정을 통해 커넥션 풀의 크기를 늘리고, maxLifetime, idleTimeout 등을 조정합니다.

6.3. 응답 시간 개선

• 비동기 처리: 대기열 처리나 데이터베이스 조회 등의 시간이 많이 소요되는 작업을 비동기 처리하여 사용자 경험을 향상시키는 방안을 고려합니다.

7. 가상 장애 대응 계획

7.1. 데이터베이스 장애 대응

• 재시도 로직: 데이터베이스 연결이 실패할 경우, 일정 시간 동안 재시도하도록 설정하여 일시적인 장애를 처리할 수 있습니다.

7.2. 서버 장애 대응

• 로드 밸런싱: 여러 서버로 부하를 분산시키기 위해 로드 밸런서를 설정하고, 서버 장애 시 다른 서버로 자동으로 요청이 전송되도록 설정합니다.
• 서버 모니터링: 서버의 리소스를 실시간으로 모니터링하고, 이상 징후가 발생하면 자동 스케일링을 통해 자원을 확장할 수 있도록 합니다.

7.3. 큐 시스템 장애 대응

• 큐 시스템 모니터링: 큐 상태를 실시간으로 모니터링하여 큐에 쌓인 요청 수가 임계치를 넘으면 알림 시스템을 통해 관리자에게 경고합니다.
• 큐에 대한 모니터링 강화: 큐에 대한 모니터링 지표를 추가하고, 큐 처리 지연 시 자동화된 알림을 통해 장애를 조기에 감지할 수 있도록 합니다.

8. 결론

• 부하 테스트를 통해서 동시성 처리 및 데이터베이스 연결 부족 또는 API 성능 등의 문제점을 발견할 수 있었습니다. 이를 해결하기 위해 성능 튜닝 및 대기열 처리 로직 개선이 필요하다는 걸 알게되었습니다.
• API 응답 시간 분포를 기반으로 병목 지점을 분석하는 것이 중요합니다.
• 가상 장애 대응 계획을 수립하여 시스템 장애 발생 시 즉각 대응할 수 있도록 시스템을 강화하는 것이 중요합니다.
• 응답 시간이 매우 긴 요청이 있을 경우, 시스템에서 과도한 자원을 소비하거나, 특정 서버나 네트워크 병목이 발생할 수 있습니다.