부하 테스트 전략과 성능 튜닝 체크리스트

💡 실무에서 자주 빠뜨리는 것:
  
  1. Soak test를 안 한다 → 배포 3일 후 메모리 누수로 장애
  2. Spike test를 안 한다 → 이벤트 오픈 시 서킷브레이커 폭발
  3. Stress test만 한다 → "어디까지 되는지"만 알고 "왜 무너지는지"를 모름

SLI (Service Level Indicator): 측정하는 지표
  → 예: "주문 조회 API의 응답 시간"

SLO (Service Level Objective): 목표 수준
  → 예: "p95 < 200ms, 에러율 < 0.1%"

SLA (Service Level Agreement): 고객과의 약속
  → 예: "가용성 99.9%, 위반 시 크레딧 환불"

주문 조회 (GET /api/orders)
  └─ p95 < 200ms, p99 < 500ms, 5xx < 0.1%

주문 생성 (POST /api/orders)
  └─ p95 < 500ms, p99 < 1s, 5xx < 0.05%

검색 (GET /api/search)
  └─ p95 < 300ms, p99 < 800ms, 5xx < 0.5%

실제 서비스 트래픽 분석 결과:
  - 상품 목록 조회: 50%   (GET /products)
  - 상품 상세 조회: 30%   (GET /products/{id})
  - 장바구니 추가:  10%   (POST /cart)
  - 주문 생성:      5%    (POST /orders)
  - 결제:           3%    (POST /payments)
  - 기타:           2%

❌ 안 좋은 시나리오: 모든 API를 균등하게 1:1:1 호출
✅ 좋은 시나리오: 실제 비율을 반영

실제 사용자는 쉬지 않고 요청을 보내지 않습니다.

페이지 열람: 5~15초
장바구니 담기 전 고민: 10~30초
결제 정보 입력: 30~60초

Think Time 없는 테스트 → 실제보다 10~50배 높은 RPS
→ "서버가 1000 RPS도 못 버텨요!" (실제 피크는 100 RPS)

❌ 모든 요청이 같은 상품 ID 조회 → 캐시 히트 100% (비현실적)
❌ 모든 요청이 다른 상품 ID 조회 → 캐시 히트 0% (비현실적)

✅ 현실적 분포:
  - 인기 상품 20%가 조회의 80%를 차지 (파레토)
  - zipf 분포 또는 실제 로그 기반 분포 사용

⚠️ 환경 차이가 불가피할 때의 대응:

1. 차이를 문서에 명시: "테스트 환경은 프로덕션의 1/4 스펙"
2. 결과에 보정 계수를 적용하지 않음: 숫자는 그대로 보고
3. 대신 경향(trend)에 집중: "커넥션 풀이 먼저 포화됨 → 프로덕션도 동일 패턴"
4. 정기적으로 프로덕션 환경 테스트 (카나리아/쉐도우 트래픽)

import http from 'k6/http';
import { check, sleep, group } from 'k6';
import { Rate, Trend } from 'k6/metrics';

// 커스텀 메트릭
const errorRate = new Rate('errors');
const orderDuration = new Trend('order_duration');

export const options = {
  // 단계별 부하 증가 (Load Test)
  stages: [
    { duration: '2m', target: 20 },   // 워밍업
    { duration: '5m', target: 50 },   // 정상 부하
    { duration: '3m', target: 100 },  // 피크 부하
    { duration: '2m', target: 0 },    // 쿨다운
  ],
  
  // SLO 기반 임계값
  thresholds: {
    http_req_failed: ['rate<0.01'],              // 에러율 < 1%
    http_req_duration: ['p(95)<200', 'p(99)<500'], // p95 < 200ms
    'http_req_duration{name:order_create}': ['p(95)<500'], // 주문 생성 별도 SLO
    errors: ['rate<0.05'],                        // 커스텀 에러율 < 5%
  },
};

const BASE_URL = __ENV.BASE_URL || 'https://api.example.com';

// 테스트 데이터 (실제로는 CSV/JSON 파일에서 로드)
const PRODUCT_IDS = [101, 102, 103, 204, 305, 406, 507, 608, 709, 810];

export default function () {
  const headers = {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${__ENV.TOKEN}`,
  };
  
  // ── 시나리오 1: 상품 목록 조회 (50%) ──
  group('상품 목록 조회', () => {
    const res = http.get(`${BASE_URL}/api/products?page=1&size=20`, {
      headers,
      tags: { name: 'product_list' },
    });
    
    check(res, {
      'status is 200': (r) => r.status === 200,
      'has products': (r) => JSON.parse(r.body).content?.length > 0,
    }) || errorRate.add(1);
  });
  
  sleep(Math.random() * 3 + 2); // Think time: 2~5초
  
  // ── 시나리오 2: 상품 상세 조회 (30%) ──
  if (Math.random() < 0.6) {  // 60% 확률로 상세 조회 진행
    group('상품 상세 조회', () => {
      const productId = PRODUCT_IDS[Math.floor(Math.random() * PRODUCT_IDS.length)];
      const res = http.get(`${BASE_URL}/api/products/${productId}`, {
        headers,
        tags: { name: 'product_detail' },
      });
      
      check(res, {
        'status is 200': (r) => r.status === 200,
      }) || errorRate.add(1);
    });
    
    sleep(Math.random() * 5 + 5); // Think time: 5~10초
  }
  
  // ── 시나리오 3: 주문 생성 (5%) ──
  if (Math.random() < 0.1) {
    group('주문 생성', () => {
      const startTime = Date.now();
      
      const payload = JSON.stringify({
        productId: PRODUCT_IDS[Math.floor(Math.random() * PRODUCT_IDS.length)],
        quantity: Math.ceil(Math.random() * 3),
      });
      
      const res = http.post(`${BASE_URL}/api/orders`, payload, {
        headers,
        tags: { name: 'order_create' },
      });
      
      orderDuration.add(Date.now() - startTime);
      
      check(res, {
        'status is 201': (r) => r.status === 201,
        'has orderId': (r) => JSON.parse(r.body).orderId !== undefined,
      }) || errorRate.add(1);
    });
    
    sleep(Math.random() * 10 + 10); // 결제 후 대기: 10~20초
  }
}

// 테스트 시작 전 실행 (데이터 준비 등)
export function setup() {
  console.log(`Target: ${BASE_URL}`);
  // 사전 조건 확인
  const healthCheck = http.get(`${BASE_URL}/actuator/health`);
  if (healthCheck.status !== 200) {
    throw new Error('서버가 준비되지 않았습니다');
  }
}

// 테스트 종료 후 실행 (정리)
export function teardown(data) {
  console.log('테스트 완료. 결과를 확인하세요.');
}

# .github/workflows/load-test.yml
name: Load Test
on:
  schedule:
    - cron: '0 3 * * 1'  # 매주 월요일 새벽 3시
  workflow_dispatch:       # 수동 실행 가능

jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install k6
        run: |
          sudo gpg -k
          sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg \
            --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D68
          echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | \
            sudo tee /etc/apt/sources.list.d/k6.list
          sudo apt-get update && sudo apt-get install k6
          
      - name: Run Load Test
        env:
          BASE_URL: ${{ secrets.STAGING_URL }}
          TOKEN: ${{ secrets.TEST_TOKEN }}
        run: k6 run --out json=results.json tests/load-test.js
        
      - name: Upload Results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: k6-results
          path: results.json
          
      - name: Check Thresholds
        if: failure()
        run: echo "⚠️ 부하 테스트 SLO 위반!" >> $GITHUB_STEP_SUMMARY

부하 테스트 초반 1~2분은 결과에서 제외해야 합니다.

이유:
1. JVM JIT 컴파일: 인터프리터 → 네이티브 코드 전환 (수십 ms → 수 ms)
2. 캐시 워밍업: 첫 요청은 모두 Cache Miss
3. 커넥션 풀 워밍업: lazy init이면 초반에 커넥션 생성 비용
4. 오토스케일: 반응 시간 30초~3분

k6에서의 처리:
  stages: [
    { duration: '2m', target: 20 },  // ← 워밍업 (결과 분석에서 제외)
    { duration: '5m', target: 50 },  // ← 실제 측정 구간
    ...
  ]

패턴 1: 레이턴시가 서서히 올라감
  → 메모리 누수 또는 GC 빈도 증가
  → 확인: jvm_gc_pause_seconds, jvm_memory_used_bytes 추이

패턴 2: 특정 RPS에서 갑자기 에러 폭증
  → 리소스 포화 (커넥션 풀, 스레드 풀, DB 커넥션)
  → 확인: hikaricp_connections_active == hikaricp_connections_max

패턴 3: 레이턴시가 일정하다가 계단식으로 뜀
  → GC Full GC 발생 또는 오토스케일 전환점
  → 확인: jvm_gc_pause_seconds에서 Major GC 확인

패턴 4: RPS가 올라가도 처리량이 안 늘어남
  → 동기 병목 (락, 동기화, 외부 API 대기)
  → 확인: 스레드 덤프에서 BLOCKED/WAITING 스레드

풀 크기만 무작정 키우면 안 됩니다. 근거가 있어야 합니다.

기본 공식 (PostgreSQL 가이드):
  pool_size = (core_count * 2) + effective_spindle_count
  
  예: 4 vCPU 서버 → pool_size = (4 * 2) + 1 = 9~10

실무 조정:
  1. 평균 쿼리 시간이 길면 (> 100ms) → 풀 약간 키움
  2. 외부 API 호출이 많으면 → 별도 스레드 풀로 분리
  3. 절대 DB max_connections보다 크면 안 됨
  
  인스턴스 4대 × pool_size 10 = 총 40 커넥션
  DB max_connections = 100 → 나머지 60은 배치/모니터링/마이그레이션용 여유

튜닝 루프:

1. 측정 (Baseline): 현재 성능 기록
2. 가설: "슬로우 쿼리가 p99를 올리고 있다"
3. 변경: 인덱스 하나 추가 (한 가지만!)
4. 재측정: 같은 시나리오, 같은 환경
5. 비교: p99가 내려갔는가?
6. 반복

⚠️ 흔한 실수:
  - 인덱스 추가 + 풀 크기 변경 + GC 옵션 변경을 동시에
  → 뭐가 효과가 있었는지 알 수 없음
  → 오히려 성능이 나빠져도 어디를 되돌려야 할지 모름

# 부하 테스트 리포트

## 개요
- 날짜: 2026-03-23
- 대상: 주문 서비스 v2.1.0
- 테스트 종류: Load Test (피크 100 VU)
- 환경: staging (프로덕션의 1/2 스펙)

## SLO 결과
| 지표 | SLO | 결과 | 판정 |
|------|-----|------|------|
| GET /orders p95 | < 200ms | 185ms | ✅ PASS |
| POST /orders p95 | < 500ms | 620ms | ❌ FAIL |
| 에러율 | < 0.1% | 0.05% | ✅ PASS |

## 병목 분석
- POST /orders가 SLO 초과: HikariCP 커넥션 풀 고갈 확인
- 원인: 재고 확인 쿼리가 테이블 락을 잡고 평균 200ms

## 개선 계획
1. 재고 확인 쿼리에 SELECT FOR UPDATE SKIP LOCKED 적용
2. 커넥션 풀 10 → 15로 증가 (DB max 100, 현재 총 40)
3. 개선 후 동일 시나리오로 재테스트

## 환경 상세
- 인스턴스: 2 vCPU, 4GB × 2대
- DB: PostgreSQL 16, 데이터 50만 행
- 캐시: Redis 7, 1GB

동시 사용자 = 도착률(RPS) × 평균 체류 시간(초)

예: 100 RPS, 평균 응답 200ms
  → 동시 요청 = 100 × 0.2 = 20

스레드 풀이 20개면 이론상 커버.
실무에서는 2~3배 여유: 40~60개

평상시 트래픽: 100 RPS
피크 배율: ×5 (이벤트/프로모션)
안전 마진: ×1.5

필요 용량 = 100 × 5 × 1.5 = 750 RPS

현재 서버 1대 한계 = 300 RPS (Stress Test 결과)
→ 최소 3대 필요 (LB behind)
→ 오토스케일: min=3, max=6, target CPU=70%