확장성 테스트로 용량 한계와 SLO 운영 범위 찾기

트래픽 증가가 드러내는 시스템의 실제 한계

기능이 정상 동작하는 상태에서도 트래픽이 늘면 처리량, 지연, 비용, 실패 양상은 함께 변한다. 확장성 테스트는 부하를 의도적으로 늘리고 형태를 바꾸면서 자원 증가에 따른 처리량 향상, 지연 한계, 실패 모드, 비용 효율을 수량화하는 비기능 시험이다.

목표는 목표 SLO를 지키는 안전한 운영 범위와 임계점을 찾는 데 있다. 측정 대상에는 처리량(RPS, msgs/s), 지연(p95/p99), 실패율, CPU·메모리·IO·GC 사용률, 큐 길이와 락 대기 같은 포화도, 원/RPS 단위의 비용·성능, 처리량 증가율과 자원 증가율의 관계가 포함된다.

테스트는 관찰하려는 상황에 따라 나눈다. 소량 부하에서 안정 상태를 확인하는 베이스라인, 목표 부하를 재현하는 로드, 임계점을 넘기는 스트레스, 짧은 급증을 다루는 스파이크, 장시간 안정성을 보는 소크·엔듀런스, 그리고 튜닝 전후를 비교하는 회귀 테스트가 있다.

워크로드가 현실을 닮아야 결과도 쓸 수 있다

사용자 행동을 시나리오로 바꾸고 요청 믹스와 경로별 확률 분포를 정한다. 도착률을 고정하는 오픈 모델과 동시 사용자 및 생각시간을 두는 클로즈드 모델 중 서비스 특성에 맞는 방식을 선택한다.

시간대별 도착률, 백엔드 키 분포(Zipf), 캐시 적중률, 데이터 세트 크기도 워크로드에 반영한다. 장애와 재시도, 타임아웃, 서킷브레이커를 빼면 실제 장애 상황과 다른 결과가 나올 수 있다. 읽기:쓰기 비율, idempotency, 핫키와 스캔 패턴, 멱등·중복 처리의 경계도 함께 검증 대상이 된다.

환경은 프로덕션과 유사해야 한다. 인스턴스 타입, 버전, 네트워크 레이턴시를 맞추고 오토스케일 정책도 동일하게 적용한다. 데이터 시딩과 캐시 워밍 뒤 리밸런싱이 끝날 때까지 기다리며, 결제나 3rd party 같은 외부 의존성은 샌드박스와 모킹을 함께 사용한다. 테스트는 스테이징 전용 VPC 또는 네임스페이스에서 격리하고, 비용과 안정성을 보호할 가드레일을 둔다.

램프 프로파일과 SLO로 합격선을 정한다

부하는 단계적으로 올리고 내리거나 스텝 증분과 스파이크 프로파일로 구성한다. 일정과 혼합 시나리오를 함께 고려한다. 베이스라인은 10~~20분, 로드는 30~~60분, 소크는 6~24시간을 권장하며, 이 과정에서 GC·캐시·커넥션 풀의 안정화를 관찰한다.

테스트는 SLO 위반, 에러율 급등, 자원 포화, 비용 한도 도달을 종료 기준으로 삼아 중단하고 분석한다. RED/USE 메트릭, 분산 트레이싱, 로그 상관분석을 활성화하고 p95/p99와 히스테리시스를 포함한 오토스케일 신호를 검증한다.

합격 기준은 SLO와 에러버짓에 연결한다. 예를 들어 가용성 99.9%, p95<300ms, 실패율<1%를 기준으로 둘 수 있다. DB 락 대기, 스레드·코루틴 풀, 큐 길이, GC STW, 커넥션 오류, 브로커의 리밸런스·압축 영향을 추적하면 병목의 위치를 좁힐 수 있다.

서비스 경계마다 달라지는 검증 대상

대규모 세일 이벤트를 준비하는 전자상거래에서는 트래픽 예측 뒤 CPU·요청 지표와 쿨다운을 기준으로 오토스케일을 튜닝하고, 캐시 계층을 미리 워밍한 다음 스파이크 시험과 카트·결제 경계 테스트를 수행한다. 재시도 폭증은 백오프로 제어하고, 피크는 큐 기반 비동기 처리로 흡수하며, 재고 락과 아이템 단위 예약을 점검한다.

API 게이트웨이와 엣지에서는 TLS 핸드셰이크 비용을 분리하고 Keep-Alive·HTTP/2를 최적화한 뒤 레이트리밋·토큰버킷과 WAF 규칙의 비용을 검증한다. 커넥션 풀, CPU 핀닝, 커널 파라미터, ELB/ALB 리밸런스도 함께 확인한다.

데이터베이스와 메시징 계층은 파티셔닝 키의 카디널리티, Hot partition, 컨슈머 그룹 확장, Exactly-once·At-least-once를 중심으로 본다. 락 경합, WAL·체크포인트, 브로커 압축과 배치 사이즈가 병목에 미치는 영향도 측정한다.

ML 추론 서비스에서는 모델 로딩과 콜드스타트 비용을 측정하고 배치·동시 실행을 조정한다. GPU/CPU 혼합 오토스케일, 동적 배칭, 캐시 히트율, 프리미엄·베이직 QoS 분리가 주요 검증 범위다.

측정부터 재검증까지 이어지는 흐름

⤢✕

확장 방식에 따라 달라지는 관찰 지점

전략	성능	확장성	일관성	안정성	운영 편의
수직 확장(Scale-up)	단일 인스턴스 지연 감소	한계 명확	단순	단일 장애점 위험	관리 용이
수평 확장(Scale-out)	처리량 증가	높음(네트워크 비용 존재)	세션/상태 분리 필요	재조정 영향	자동화 요구
캐싱/CDN	히트율에 비례	원본 부하 경감	TTL/스티일 비일관	캐시 무효화 리스크	간편(관리 정책 필요)
파티셔닝/샤딩	병렬 처리	핫키 리스크 관리 필요	교차 샤드 트랜잭션 복잡	리밸런스 비용	운영 난이도 높음
비동기/큐잉	피크 흡수	컨슈머 확장 용이	최종 일관성 수용 필요	백프레셔 필수	모니터링 중요

k6로 오픈 모델 부하를 자동화하는 예시

전제조건은 k6 v0.46+ 설치 또는 Docker 사용, 테스트 대상 URL 접근 가능, 스테이징 환경 권장이다. 실행은 TARGET_URL=https://staging.example.com k6 run script.js로 한다.

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

export const options = {
  scenarios: {
    steady: {
      executor: 'ramping-arrival-rate',
      startRate: 100,        // 초당 요청 시작값
      timeUnit: '1s',
      preAllocatedVUs: 200,
      maxVUs: 2000,
      stages: [
        { target: 200, duration: '5m' },   // 베이스라인
        { target: 1000, duration: '10m' }, // 목표 부하
        { target: 0, duration: '2m' }      // 정리
      ],
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<300', 'p(99)<800'],
  },
};

export default function () {
  const res = http.get(`${__ENV.TARGET_URL}/api/v1/search?q=test`, { tags: { name: 'GET /search' } });
  check(res, { 'status 200': r => r.status === 200 });
  sleep(1); // 생각시간 모형
}

피크 트래픽에서 필요한 용량을 계산하는 방식

시간당 피크 활성 사용자 30,000명, 사용자당 분당 4요청, 동시성 계수 0.3을 가정한다.

분당 요청수 = 30,000 × 4 × 0.3 = 36,000 rpm
초당 요청수(RPS) = 36,000 / 60 = 600 rps
목표 SLO: p95 < 300ms, 실패율 < 1%, CPU < 70%

인스턴스를 5에서 10으로 늘렸을 때 처리량이 600에서 1080 rps가 됐다면, 이론 대비 효율은 1080 / (600 × 2) = 0.9 = 90% 효율이다. 오토스케일 트리거는 CPU 60% 또는 요청 지연 p95 250ms 중 높은 값 기준으로 설정하고, 쿨다운 120초를 적용하는 방식을 권장한다.

측정 결과를 운영 의사결정에 연결하기

확장성 테스트는 처리량 최대치와 임계점을 가시화하고, 스케일링 효율 및 비용·성능의 최적점을 도출한다. 장애율과 시간을 줄이는 데도 활용할 수 있다. 병목 위치가 분명해지면 운영 플레이북을 고도화하고 아키텍처 개선 우선순위를 정하며 리스크 커뮤니케이션을 강화할 수 있다.

부하 테스트 게이트를 CI/CD에 통합해 기준선 대비 회귀를 판단하고, IaC와 테스트 코드를 결합한 인프라형 테스트를 적용한다. 비용·성능 곡선, 스케일링 효율, 포화 지점, 자원에서 지연으로 이어지는 상관분석을 자동으로 보고하고, 튜닝 항목과 릴리즈 영향, 운영 플레이북 변경 사항을 추적한다.

부하를 만들 때 지켜야 할 운영 경계

테스트 데이터는 비식별화하고 3rd party 호출은 모킹한다. 레이트리밋과 WAF를 우회하지 않으며, 부하 트래픽 출처는 화이트리스트로 관리한다.

타임아웃·재시도·서킷브레이커는 회복력과 직결된다. 백프레셔가 구현되지 않으면 큐 폭주 위험이 있다. 세션은 외부화하고 캐시 TTL·무효화 정책을 관리하며, 캐시 일관성과 성능 사이의 트레이드오프를 판단한다.

저장소에서는 파티셔닝 키 선택과 교차샤드 트랜잭션 비용을 검토한다. 읽기 복제본을 사용한다면 지연과 리플리케이션 랙을 고려해야 한다. 오토스케일의 히스테리시스·쿨다운, 스팟 인스턴스 혼용 시 프리엠션 대비, 관측성 샘플링율과 비용의 균형도 운영 조건에 포함된다.