k6 터미널 실행 방법 - 100-hours-a-week/KTB4-7th-Cloud GitHub Wiki

실행 환경

Mac의 로컬 Backend 앞에 테스트용 Nginx를 두고 실행한다.

k6 → Nginx(127.0.0.1:8088) → Backend(127.0.0.1:8080) → Backend에 설정된 DB

k6, Docker가 설치돼 있고 Backend가 8080에서 실행 중이어야 한다.
Backend의 DB 연결 대상을 먼저 확인한다. 로컬 Backend도 RDS를 사용할 수 있다.
현재 실행 가능한 스크립트는 SLI-1 매출 분석 조회다. 로그인, 업로드, 재처리, AI 생성은 부하에서 제외한다.
아래 Cloud 저장소 경로는 본인의 경로에 맞게 바꾼다.

1. Backend와 Nginx 준비

터미널 1 — Backend 확인

curl -sS -o /dev/null -w 'HTTP %{http_code}\n' \
  http://127.0.0.1:8080/v1/auth/csrf-token

HTTP 204이면 Backend 준비가 끝났다. 다음 단계에서 테스트용 Nginx를 실행한다.

HTTP 204가 나오지 않을 때

cd "/Users/jake/Documents/ChatGPT/Final Project/repos/KTB4-7th-BE-ci-mail-env"

./gradlew \
  -Dorg.gradle.java.installations.paths=/opt/homebrew/opt/openjdk@25/libexec/openjdk.jdk/Contents/Home \
  -I '/tmp/codex-k6-bootrun.XXXXXX.gradle' \
  bootRun \
  --args='--spring.profiles.active=local --server.port=8080 --app.sales.storage-directory=/tmp/codex-memme-k6-storage'

서버가 올라오면 새 터미널에서 다시 확인한다.

curl -sS -o /dev/null -w 'HTTP %{http_code}\n' \
  http://127.0.0.1:8080/v1/auth/csrf-token

HTTP 204가 나오면 Nginx 준비로 넘어간다. 연결은 되지만 다른 상태 코드가 나오면 Backend 로그에서 오류를 확인한다.

터미널 2 — 테스트용 Nginx 실행

cd "/Users/jake/Documents/ChatGPT/Final Project/repos/KTB4-7th-Cloud"

docker compose -f tests/k6/nginx/compose.yaml up -d
docker compose -f tests/k6/nginx/compose.yaml ps

curl -sS -o /dev/null -w 'HTTP %{http_code}\n' \
  http://127.0.0.1:8088/v1/auth/csrf-token

HTTP 204이면 Backend까지 연결됐다. 502이면 Backend 연결을 확인한다. Nginx는 백그라운드에서 실행되므로 이 터미널을 계속 열어둘 필요는 없다.

터미널 3 — Nginx 로그

cd "/Users/jake/Documents/ChatGPT/Final Project/repos/KTB4-7th-Cloud"

docker compose -f tests/k6/nginx/compose.yaml logs -f --tail=0 k6-nginx

테스트 요청은 JSON 로그의 load_test=k6로 구분한다. 응답 코드, request_time, upstream_response_time을 확인한다. Ctrl+C는 로그 출력만 종료한다.

2. 매출 분석 부하 실행

자동 준비 방식과 수동 방식 중 하나를 선택한다. 두 방식 모두 Backend, Nginx 준비와 모니터링을 먼저 수행한다.

터미널 4 - 로컬 자동 준비 후 실행

현재 Mac에 있는 준비 스크립트로 테스트 계정 생성, 로그인, 합성 매출 업로드, Q1/Q2 사전 확인을 수행한 뒤 k6를 실행한다. Cookie를 별도로 입력할 필요가 없다. 계정 생성과 업로드는 준비 단계이며 k6 부하 표본에 포함하지 않는다.

PROFILE=smoke bash "/Users/jake/Documents/ChatGPT/Final Project/local-k6-monitor/run.sh"

Smoke 결과를 확인한 후 Load를 별도로 실행한다.

PROFILE=load bash "/Users/jake/Documents/ChatGPT/Final Project/local-k6-monitor/run.sh"

샘플 날짜와 Q2 범위는 서울 시간 기준 이번 달 1일부터 2일 또는 오늘 중 더 이른 날까지 자동 생성한다.
10월 1일에는 둘 다 10월 1일을 사용한다. 미래인 10월 2일 데이터를 넣지 않는다.
각 실행마다 새 테스트 계정과 데이터를 준비한다. 출력된 날짜와 데이터 조건을 결과에 기록한다.
Q1=COMPLETED, Q2=COMPLETED 확인 후 [5/5] k6 실행이 나와야 부하가 시작된다.
요약은 /tmp/k6-sli1-프로필-YYYYMMDD-HHMMSS-summary.json에 저장한다. 실행 시 실제 경로를 출력하며 이전 결과를 덮어쓰지 않는다.
이 스크립트는 현재 Mac의 임시 파일이다. 다른 PC에서는 같은 경로가 없으므로 아래 수동 방식 또는 별도 데이터 준비가 필요하다.

3. 자원과 DB 지표 확인

부하 실행 전에 Backend 모니터링과 RDS CloudWatch를 열어 둔다.

Backend CPU와 메모리

별도 터미널에서 8080을 사용하는 PID를 확인한다. top에서 해당 Java 프로세스와 k6의 CPU, 메모리를 함께 본다. MEM은 JVM 힙 사용량과 다르다.

lsof -nP -iTCP:8080 -sTCP:LISTEN
top -o cpu

DB 지표는 CloudWatch에서 확인

Backend가 연결된 RDS 인스턴스의 CloudWatch에서 CPU, 가용 메모리, 연결 수, 읽기 지연을 확인한다. 테스트 시작 전부터 종료 후까지 같은 시간대로 보고, k6 결과와 함께 기록한다.

4. 다른 SLI를 추가할 때

대상	준비할 항목
SLI-2 — 오늘의 솔루션	배포 API 경로, 상태 계약, 이미 생성된 카드, 전용 스크립트. API 성공과 결과 제공률을 분리
SLI-3 — 업로드 상태	테스트 매장 소유의 uploadId, 전용 스크립트. 유효 상태 조회와 FAILED 업무 결과를 분리

두 스크립트는 아직 없다. 요청, 검증 로직을 만든 뒤 각각 Smoke부터 실행한다. 다른 매장의 uploadId 접근 차단도 단건 확인하되 부하 표본과 분리한다. 결과 파일은 SLI별로 저장한다.

5. 기록과 종료

k6 요약, Nginx 로그, Backend 자원 지표, CloudWatch의 RDS 지표를 같은 SLI, 프로필, 시작/종료 시각으로 묶는다. 실행 버전, 환경, 데이터, 실제 RPS, 오류도 남긴다. 요약 파일 이름의 sli1-load는 실행에 맞게 바꾼다.

응답 지연과 Backend CPU, GC, CloudWatch의 RDS 지표를 대조한다. 목표 RPS를 못 보냈다면 k6 CPU와 dropped_iterations도 확인한다. 연결 풀 대기는 Backend 지표가 필요하다.

테스트 종료 후 Cloud 저장소 루트에서 프록시를 중지한다.

docker compose -f tests/k6/nginx/compose.yaml down
unset COOKIE_HEADER