NestJS 마이크로서비스 부하테스트: 전략 설계와 7가지 요구사항

들어가며

주문 처리 시스템의 성능을 검증해야 하는 상황이 생겼습니다. 단순히 "잘 동작하는가"가 아니라, "동시에 얼마나 많은 요청을 처리할 수 있는가"를 정확히 측정해야 했습니다. 그런데 막상 부하테스트를 시작하려니 고민이 많았습니다.

로컬 환경에서 테스트한 결과가 Production에서도 동일하게 나올까? Connection Pool 설정이 다르면 결과가 완전히 달라지지 않을까? 이런 의문들이 계속 들었습니다.

결국 "Production 환경을 최대한 정확히 재현한 상태에서 테스트해야 한다"는 결론에 도달했습니다. 이 글에서는 부하테스트 전략을 설계하면서 정의한 7가지 요구사항과 전체 아키텍처를 공유합니다.

왜 Production 환경 재현이 중요한가

처음에는 로컬 환경에서 간단히 테스트하면 되지 않을까 생각했습니다. 하지만 몇 가지 문제를 발견했습니다.

로컬 환경의 한계

로컬 개발 환경은 대부분 이렇게 설정되어 있습니다:

Connection Pool 설정 비교

로컬 환경 (local.ts)
├─ Read Pool: max 5
├─ Write Pool: max 5
└─ 총 10개 연결

Production 환경 (default.ts)
├─ Read Pool: max 40
├─ Write Pool: max 20
└─ 총 60개 연결

6배 차이입니다. 로컬에서 "Pool이 부족해서 느려졌다"는 결론을 내렸는데, 실제 Production에서는 전혀 다른 병목이 있을 수 있습니다. 반대로 로컬에서 잘 돌아갔는데 Production에서 터지는 경우도 있고요.

컨테이너 리소스 제약

또 하나 간과하기 쉬운 부분이 있습니다. Production은 ECS에서 컨테이너로 동작하는데, CPU와 메모리에 명확한 제한이 있습니다. 로컬 맥북은 리소스가 넉넉해서 이런 제약을 체감하기 어렵습니다.

ECS Task Definition
├─ CPU: 1024 units (1 vCPU)
├─ Memory: 2048 MB
└─ 이 제약 안에서 성능 측정 필요

결국 의미 있는 부하테스트를 하려면 Production과 동일한 조건을 만들어야 한다는 생각이 들었습니다.

7가지 요구사항 정의

테스트 목표를 명확히 하기 위해 요구사항을 정리했습니다. 애매하게 "부하테스트 하자"가 아니라, 구체적으로 무엇을 검증할지 정의하는 게 중요하다고 생각했습니다.

1. 실제 비즈니스 시나리오 반영

단순히 API를 호출하는 것이 아니라, 실제 주문 생성 플로우를 테스트해야 했습니다. 특정 상품의 다양한 옵션 조합으로 주문을 생성하는 시나리오입니다.

2. 옵션 조합 패턴 다양화

실제 사용자 행동을 반영한 옵션 조합이 필요했습니다:

• 단일 옵션: 하나의 옵션만 선택 (50%)
• 복수 옵션: 여러 옵션 동시 선택 (30%)
• 동일 옵션 중복: 같은 옵션 여러 개 (20%)

3. 동시 요청 처리 능력 측정

Rate Limiting을 일시적으로 비활성화하고 순수한 시스템 처리 능력을 측정해야 했습니다. Throttling이 걸려 있으면 진짜 한계점을 알 수 없으니까요.

4. 충분한 테스트 데이터

재고 부족으로 테스트가 중단되면 안 됩니다. 충분한 재고(10만 개 이상)를 확보하고, 품절 옵션은 자동으로 필터링되도록 했습니다.

5. Production 환경 재현

앞서 설명한 대로, Docker 컨테이너에 ECS와 동일한 리소스 제약을 걸고, Production과 동일한 Pool 설정을 사용합니다.

6. Connection Pool 모니터링

각 데이터베이스별로 Pool 상태를 실시간으로 확인해야 했습니다:

• 사용 중인 연결 수
• 대기 중인 요청 수
• Pool 사용률 (%)

7. 컨테이너 리소스 모니터링

CPU와 메모리 사용량도 함께 확인해야 병목 지점을 정확히 파악할 수 있습니다.

전체 아키텍처 설계

요구사항을 충족하는 테스트 환경 아키텍처를 설계했습니다.

부하테스트 아키텍처

┌─────────────────┐
│   k6 Runner     │  ← 부하 생성기
│  (로컬 실행)    │
└────────┬────────┘
         │ HTTP
         ▼
┌─────────────────────────────────────┐
│      Docker Container               │
│  ┌───────────────────────────────┐  │
│  │   NestJS API Server           │  │
│  │   - 1 vCPU, 2GB Memory        │  │
│  │   - Production Pool 설정      │  │
│  │   - Pool Monitor 내장         │  │
│  └───────────────────────────────┘  │
└────────┬────────────────────────────┘
         │
    ┌────┴────┐
    ▼         ▼
┌───────┐ ┌───────┐
│  RDS  │ │ Redis │  ← 스테이징 DB 사용
└───────┘ └───────┘

핵심 구성 요소

k6: 부하 생성 도구로 k6를 선택했습니다. JavaScript로 시나리오를 작성할 수 있고, 다양한 부하 패턴(ramp-up, spike, breakpoint)을 지원합니다.

Docker Container: ECS Task Definition과 동일한 리소스 제약을 적용한 컨테이너입니다. NODE_ENV를 별도로 설정해서 Production Pool 설정을 사용합니다.

Pool Monitor: API 서버 내부에 Pool 상태를 조회하는 서비스를 내장했습니다. 별도 모니터링 인프라 없이도 실시간 상태 확인이 가능합니다.

Breakpoint 테스트 전략

시스템의 한계점을 찾기 위해 Breakpoint 테스트 방식을 채택했습니다.

부하 증가 패턴

RPS (Requests Per Second)
300 ┤                              ╭──
250 ┤                         ╭────╯
200 ┤                    ╭────╯
150 ┤               ╭────╯
100 ┤          ╭────╯
 50 ┤     ╭────╯
 10 ┤╭────╯
    └┴────┴────┴────┴────┴────┴────┴─→ 시간
     30s  60s  90s  120s 150s 180s

30초마다 RPS를 10씩 증가시키면서 시스템이 어느 지점에서 성능 저하가 시작되는지 관찰합니다. 에러율이 급증하거나 응답 시간이 급격히 늘어나는 지점이 바로 시스템의 한계점입니다.

마치며

부하테스트는 단순히 도구를 실행하는 것이 아니라, 무엇을 측정할지 명확히 정의하는 것에서 시작한다는 생각이 들었습니다. 7가지 요구사항을 정리하면서 테스트의 방향이 명확해졌고, 결과를 해석하는 기준도 생겼습니다.

다음 글에서는 Docker로 Production 환경을 재현하는 구체적인 방법을 다루겠습니다. Connection Pool 설정, 리소스 제약 적용, 그리고 Kafka 연결 문제 해결 과정을 공유할 예정입니다.

이 글은 NestJS 마이크로서비스 부하테스트 시리즈의 1편입니다.