dev 부하테스트: 전용 DB·부하기 구성과 앱 한계 탐색

[m-a-king]

왜

prod DB 를 자체 관리 EC2 MySQL 로 이관(#899)하고 앱이 t4g.small 에서 도는 현 구성에서, 앱 계층이 어느 부하까지 버티는지 실측한 적이 없다. 그런데 dev 에 그냥 부하를 쏠 수는 없다:

• dev MySQL 은 앱 박스 동거 컨테이너라 부하 데이터가 dev 데이터를 오염시킨다.
• 등록 경로는 파싱 큐를 통해 prod 와 공유하는 extractor 박스를 자동 호출한다 (ItemParsingScheduler 1초 주기, 끄는 스위치 없음).
• nginx IP 레이트리밋(전역 초당 20/IP, 등록 POST 분당 30/IP)이 부하 자체를 차단한다.

무엇을

격리된 부하테스트 환경을 임시 구성해 앱 한계(TPS 상한, 병목 지점)를 실측하고, 종료 후 완전 원복한다.

• terraform 에 부하테스트 전용 리소스 추가: 전용 DB 박스(넉넉한 스펙, 백업·prevent_destroy 없음), 부하기 박스(k6 + extractor stub, EIP 고정), SG 배선. -target apply/destroy 로 생애주기 관리.
• nginx dev conf 에 부하기 EIP 레이트리밋 제외(geo + map). 부하테스트 브랜치에만 두고 dev 머지 없이 workflow_dispatch 배포로 윈도우 동안만 적용, dev 브랜치 재배포로 원복.
• dev JVM 을 prod 와 동일(768m/Xmx512)하게 브랜치 한정 상향, HikariCP 풀은 SSM 파라미터(relaxed binding)로 상향. prod 이전 가능한 결과를 얻기 위함.
• extractor stub: 계약 기준 2xx 고정 응답 + /actuator/health 200(배포 가드 통과) + 지연 시뮬레이션. GH dev environment 의 EXTRACTOR_PROD_ADDRESS override 로 dev 배포만 stub 을 보게 한다.
• 합성 시드 데이터(PENDING 0, 전부 READY), k6 시나리오(게스트 토큰 사전 발급, 조회 mix + 등록·쓰기), 윈도우·원복 런북.
• 산출물: 한계 TPS, 병목 지점, prod 적용 권고 리포트.

[m-a-king]

부하테스트 런북 (#911)

브랜치 infra/911-dev-loadtest 의 준비물(terraform·nginx 예외·stub·seed·k6)을 실제로 돌리는 절차. 이 브랜치는 dev 에 머지하지 않는다 — 윈도우 동안 dispatch 배포로만 적용하고, dev 브랜치 재배포가 곧 원복이다.

구성: 앱 = 기존 dev 박스 그대로(JVM 만 prod 동급으로 상향 배포). DB = 신규 박스 1대, prod DB 박스 완전 미러(t4g.micro·MySQL 384m 캡·버퍼풀 64M·max-conn 60) + extractor stub 동거(8090). 부하기 = 로컬 머신(k6 직접 실행, nginx 예외는 로컬 공인 IP). HikariCP 5·Tomcat 스레드 25 를 application.yml 에 명시(초기값 점검 결과: DB 2vCPU 공식값 정렬 + 스레드를 풀에 정렬한 보수적 용량 설계) — 이 브랜치 배포에 포함되며, 테스트로 실증한 뒤 dev 에 별도 PR 로 올린다.

사전 확인

• 이 브랜치가 push 돼 있다 — dispatch 배포는 CI 아티팩트가 아니라 자체 bootJar 빌드를 쓴다(deploy.yml 의 dispatch fallback). CI 는 dev/main push·PR 전용이라 이 브랜치엔 안 돈다
• 팀 공지: 윈도우 동안 dev 는 부하 DB 를 보므로 기존 dev 데이터가 안 보이고 응답이 불안정하다. 윈도우 중 다른 사람의 terraform plan 은 loadtest 리소스를 삭제 대상으로 표시한다(단일 state)
• AWS admin 자격을 세션 한정 export (terraform/README.md 방식)
• 로컬 공인 IP 확정: curl -s ifconfig.me (ssh_ingress_cidr 값과 일치하는지 확인, 유동 IP 면 윈도우 중 변경 주의)
• 측정 주의: 로컬 회선 왕복이 지연에 포함된다 — 절대값보다 램프에 따른 추세·꺾임 지점으로 판독

1. 인프라 생성 (terraform, 수동 apply)

cd terraform
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
echo "bucket = \"piki-tfstate-$ACCOUNT\"" > backend.hcl
export TF_VAR_image_bucket_name="piki-images-$ACCOUNT"
export TF_VAR_db_backup_bucket_name="piki-db-backup-$ACCOUNT"
terraform init -backend-config=backend.hcl
terraform plan  -target=aws_instance.loadtest_db
terraform apply -target=aws_instance.loadtest_db
terraform output   # loadtest_db_private_ip · loadtest_db_public_ip

-target 이 SG 의존성을 함께 끌고 온다. plan 에 loadtest 외 리소스가 잡히면 apply 전에 멈추고 확인.
주의(실측): worktree 에는 gitignored terraform.tfvars·backend.hcl 이 없다 — 메인 체크아웃에서 복사해야 한다. tfvars 없이 apply 하면 ssh_ingress_cidr 이 placeholder 로 적용돼 SSH 가 막힌다.

2. nginx 예외 IP 치환 (배포 후, dev 박스에서)

커밋하지 않는다 — public repo 라 개인 공인 IP 를 박을 수 없다. placeholder(203.0.113.99) 채로 dispatch 배포(6단계)를 먼저 하고, 배포가 conf 를 박스에 깐 뒤 dev 박스에서 치환한다:

sudo sed -i "s/203\.0\.113\.99/<로컬 공인 IP>/" /etc/nginx/sites-available/dev.api.piki.day.conf
sudo nginx -t && sudo systemctl reload nginx

재배포가 conf 를 되덮으므로, 윈도우 중 재배포했다면 이 단계를 반복한다(8단계 반복 목록과 동일 성격).

3. DB 박스 프로비저닝

박스에 key pair 가 없다 — EC2 Instance Connect 로 키를 푸시하고 들어간다:

aws ec2-instance-connect send-ssh-public-key --instance-id <id> --instance-os-user ubuntu \
  --ssh-public-key file://~/.ssh/piki-ec2-connect.pub
ssh -i ~/.ssh/piki-ec2-connect ubuntu@<loadtest_db_public_ip>   # 60초 안에 접속

첫 접속에서 cloud-init status --wait 로 docker 설치 완료를 확인한 뒤, loadtest/ 를 업로드하고:

# SSM dev 값을 로컬에서 조회해 env 로 전달 (박스는 IAM role 이 없어 SSM 을 못 읽는다)
aws ssm get-parameter --name /piki-core/dev/db-name     --with-decryption --query Parameter.Value --output text
aws ssm get-parameter --name /piki-core/dev/db-username --with-decryption --query Parameter.Value --output text
aws ssm get-parameter --name /piki-core/dev/db-password --with-decryption --query Parameter.Value --output text
# 박스에서 (mysql + extractor stub 을 함께 띄운다):
MYSQL_DATABASE=<db-name> MYSQL_USER=<db-username> MYSQL_PASSWORD=<db-password> ./provision-loadtest-db.sh
# dev 앱 박스에서 stub 교차 확인:
curl -sf http://<loadtest_db_private_ip>:8090/actuator/health

4. SSM 백업·재지정 (윈도우 진입점)

# 백업 — 로컬 보관, 커밋 금지
aws ssm get-parameters-by-path --path /piki-core/dev/ --recursive --with-decryption \
  > ~/piki-loadtest-ssm-backup-$(date +%Y%m%d).json

# db-host 만 부하 DB 로 (name/username/password 는 같은 값으로 프로비저닝했으므로 그대로)
aws ssm put-parameter --name /piki-core/dev/db-host --type SecureString --overwrite \
  --value <loadtest_db_private_ip>

HikariCP(5)·Tomcat 스레드(25)는 SSM 이 아니라 application.yml 에 명시돼 이 브랜치 배포에 이미 포함된다 — SSM 쪽 풀 파라미터는 만들지 않는다.

5. GH dev environment 의 extractor override

gh secret set EXTRACTOR_PROD_ADDRESS --env dev --body "<loadtest_db_private_ip>:8090"

repo 수준 secret 은 그대로라 prod 배포는 영향 없다. 배포 가드(curl $URL/actuator/health)는 stub 이 200 을 주므로 통과한다.

6. dispatch 배포 + 확인

gh workflow run Deploy --ref infra/911-dev-loadtest

• 배포가 SSM 을 새로 pull → 앱이 부하 DB 로 기동 → Flyway 가 빈 DB 에 전체 스키마 생성
• 확인: curl -s https://dev.api.piki.day/api/v1/dev/users 가 200 (data 는 아직 빈 목록)

7. 시드 적재 (DB 박스)

docker exec -i piki-loadtest-mysql mysql -u<user> -p<pw> <db> < seed.sql

말미의 검증 셀렉트가 users 2000 / items 50000 / READY 100000 / 비READY 0 / wishes 90000 / 고아 0 이어야 한다.

8. dev 박스 정돈 (배포 직후)

동거 mysql 은 내리지 않는다 — 실측 111MB·CPU 약 1%라 측정 왜곡이 미미하고, 그만큼 불리한 채 잰 한계는 prod 앱 박스(동거 mysql 없음)의 보수적 하한이 된다. 절차도 준다.

# 요청당 INFO 접근로그 차단 (Loki 폭증 방지, 재배포 시 자동 리셋)
ACTIVE=$(cat /etc/nginx/team3-upstream.conf)   # server localhost:8080|8081
curl -s -X POST localhost:<활성포트>/actuator/loggers/com.depromeet.piki.common.web.AccessLogFilter \
  -H 'Content-Type: application/json' -d '{"configuredLevel":"WARN"}'

주의: 윈도우 중 재배포하면 로거 레벨이 리셋되고 nginx conf 도 placeholder 로 되덮인다 — 재배포 후엔 이 단계와 2단계(nginx sed)를 반복.

목표 기준 (2 vCPU 산정)

측정은 "지금 dev 그대로(동거 mysql 포함)"의 한계이며, prod 앱 박스는 동거 mysql 이 없어 이보다 낫다 — 여기서 나온 숫자는 prod 의 보수적 하한이다.

• CPU 예산 프레임: 앱 2 vCPU = 초당 2,000ms CPU. 이론 상한 = 2,000 / (요청당 앱 CPU ms). 요청당 3-6ms 로 추정하면 이론 상한 약 330-660 req/s. R1 기준선에서 실측 계수(앱 CPU% x 2,000 / 실제 req/s)로 이 추정을 교정해 상한 예측치를 확정한다.
• DB 축: 풀 5 x 트랜잭션 약 5ms = 초당 약 1,000 tx 공급 가능. DB 도 2 vCPU 라 쿼리 CPU 가 먼저 막히면 그쪽이 knee — hikari pending 과 DB CPU 로 판별.
• 통과 하한 (PASS 기준): 지속 100 req/s 에서 p95 300ms 이하 + 에러율 0.1% 미만 (로컬 회선 왕복 포함 기준). 현 실사용 대비 큰 여유 배수라 이걸 통과하면 용량은 당분간 걱정 없음.
• 기대 knee: 약 300-600 req/s 구간. 램프(R2 이후)가 실측으로 확정한다.
• 플로우 기준: 등록→READY 전이 p95 10s 이내(유입이 워커 소화력 약 3.2/s 이하일 때) / register 5/s 초과 유입 구간에선 3분 마감 종결보증이 실제로 동작하는지 확인 / 토너먼트 완주 성공률 99% 이상 / 게스트 발급 성공률 99% 이상.
• t4g 크레딧 주의: 10분 러닝은 크레딧 안에서 풀버스트라 "코어 2개를 온전히 쓰는" 측정이 된다. 장시간 지속 부하의 실력은 baseline(코어당 20%)이 별도 기준 — 크레딧 그래프로 구분 판독.

9. k6 실행 (로컬 머신, repo 루트에서)

docker run --rm -i -v "$PWD/loadtest/k6":/scripts grafana/k6 run /scripts/scenario.js \
  -e BASE_URL=https://dev.api.piki.day \
  -e BROWSE_RATE_MAX=150 -e REGISTER_RATE=5 -e TOURNAMENT_RATE=1 -e GUEST_RATE=2 \
  --summary-export /scripts/summary-$(date +%H%M).json

• 러닝 중 로컬 머신 절전·네트워크 전환(무선→유선 등) 금지 — 공인 IP 가 바뀌면 nginx 예외가 풀려 429 로 오염된다
• 등록 쿼터(아이템 등록 사용량 한도와 게스트 권한 정리 #904, prod parity 로 켠 채 측정): 등록은 유저당 10건/1h(Redis 고정 윈도우, 429 WISH-010). 시나리오가 TOKEN_USERS 600 + round-robin 으로 유저당 5건이라 기본 러닝은 안 걸린다. 1시간 안에 러닝을 반복하면 잔량을 공유하므로 러닝 사이 dev 박스에서 쿼터 키를 지운다:
  docker exec team3-redis sh -c 'redis-cli --scan --pattern "quota:item:*" | xargs -r redis-cli del'
• 429 원인 구분법: 응답 body 에 code 필드가 있으면 앱 쿼터(WISH-010/TOURNAMENT-037), code 없는 고정 JSON 이면 nginx 레이트리밋(예외 IP 미적용 신호)
• 1차 러닝(R1)은 BROWSE_RATE_MAX=60 으로 기준선을 잡고, 이후 150 → 250 → 400 으로 올려가며 p95·에러율이 꺾이는 지점을 찾는다
• 관찰: Grafana(hikaricp_connections_active 가 5 에 포화·pending 적체 여부·http_server_requests p95·JVM heap/GC), 앱 박스 CPU, DB 박스 CloudWatch CPUCreditBalance(prod 미러라 크레딧 절벽까지가 측정 대상), stub 로그는 침묵이 정상. 풀 pending 이 쌓이는데 DB CPU 가 놀면 풀 5 가 병목이라는 신호 — 값을 올려 2차 러닝으로 비교
• 429 가 보이면 nginx 예외가 안 먹는 것 — 2단계 IP 치환·배포 반영·현재 공인 IP 를 확인

10. 원복 체크리스트 (윈도우 종료)

• SSM 원복: db-host 를 백업 값으로 put(--overwrite)
• gh secret delete EXTRACTOR_PROD_ADDRESS --env dev
• dev 브랜치 재배포: gh workflow run Deploy --ref dev — conf·JVM·extractor 배선·로거가 전부 원상 (동거 mysql 은 애초에 안 건드렸다)
• 확인: dev.api 가 기존 dev 데이터를 보여주고, 파싱(위시 등록 1건)이 실 extractor 로 정상 동작
• terraform destroy:

  terraform destroy -target=aws_instance.loadtest_db -target=aws_security_group.loadtest_db

• 결과 리포트(한계 TPS·병목·prod 권고)를 이 이슈에 남기고, 브랜치·worktree 정리 후 이슈 닫기

리스크 메모

• 부하 윈도우 동안 dev 에 접속한 실사용자의 쓰기는 부하 DB 에 들어갔다가 버려진다 (공지 필수)
• 단일 terraform state: destroy 전까지 다른 체크아웃의 plan 이 loadtest 리소스 삭제를 제안한다 — apply 금지 공지
• guest 닉네임 풀 소진은 숫자 suffix 확장(게스트 닉네임 풀 소진 시 숫자 suffix 로 확장 + 소셜 가입 닉네임 race 교정 #921)으로 해소 — GUEST_RATE 상향 여지 있음(기본 2/s 는 실유입 비율 반영)
• DB 내부 지표: prod 는 mysqld_exporter(DB 내부 지표를 mysqld_exporter 로 수집한다 #915)가 붙었지만 부하 DB 박스는 IAM 없는 소모품이라 미부착 — 필요 시 러닝 중 docker exec piki-loadtest-mysql mysql ... -e "SHOW GLOBAL STATUS LIKE 'Threads_%'" 샘플링으로 대체
• 로컬 부하기 특성: 측정 지연에 로컬 회선이 포함되고, 로컬 다운로드 대역폭이 처리량 상한이 될 수 있다 — 서버측 지표(Grafana p95)와 k6 지표를 함께 본다

---

[m-a-king]

연결 시도 1 기록 (2026-08-11) — 배선 원복 완료, 박스 유지

부하는 쏘지 않고 연결 검증까지만 진행한 뒤 사용자 판단으로 배선을 원복했다. dev 는 기존 DB·실 extractor 로 완전 원상 (재배포 확인: 외부 200 + 기존 데이터 노출). 부하 DB 박스(piki-loadtest-db, 10.0.1.112)는 가동 유지 — 재연결 때 그대로 쓴다.

연결 검증에서 잡은 것 (부하 전 중단의 수확)

1. nginx reload 조용한 실패 (해결됨, a1bba63) — limit_req_zone 은 살아 있는 shm zone 의 키 변수 변경을 reload 로 거부한다 (uses ... key while previously ... emerg). nginx -t 는 새 프로세스라 통과하는데 런타임 reload 만 실패해, 배포의 blue-green 전환이 옛 업스트림(8081)에 묶여 dev 가 502 전멸했다. 레이트리밋 예외 체인이 piki_general 의 키를 바꾼 것이 트리거. zone 을 piki_loadtest_general 로 rename 해 이번 방향·원복 방향 모두 reload 를 깨끗하게 만들었다.
   • 파이프라인 개선 후보(별건 이슈 감): 배포가 reload 를 exit code 로만 성공 처리한다 — 워커 세대 교체나 emerg 로그 검증이 없어 이런 실패가 조용히 지나간다.
2. 앱 컨테이너 → stub 호출 일시 실패 (미해결) — 등록 스모크 1건이 attempt 2회 모두 transient 실패로 FAILED. 컨테이너 env 는 stub 주소를 정확히 갖고 있었고(EXTRACT_REMOTE_BASE_URL=http://10.0.1.112:8090), 박스(호스트)에서의 계약 호출 재현은 200 이었다. 로그의 status=502 는 원격 응답이 아니라 core TRANSIENT_FAILURE 에러코드의 표기라 실제 원인(연결 거부/타임아웃/클라이언트 예외)은 미확정. 재연결 전 규명 필수 — stub 요청 로깅을 켜고(현재 무로그라 수신 여부조차 구분 불가) 앱 컨테이너 네트워크에서 재현한다.

재연결 절차 (다음 시도)

1. stub 로깅 활성화 + 컨테이너→stub 실패 규명(선행)
2. SSM db-host → 10.0.1.112, gh secret set EXTRACTOR_PROD_ADDRESS --env dev --body "10.0.1.112:8090"
3. gh workflow run Deploy --ref infra/911-dev-loadtest (nginx 예외 IP 는 배포 후 박스 sed)
4. 시드 적재 → 접근로그 WARN → 스모크 재검증(READY 확인) → k6 R1

원복 상태 체크: SSM 원복 ✓ / env secret 삭제 ✓ / dev 재배포 ✓ / 기존 데이터 확인 ✓ / 박스 destroy 는 하지 않음(의도).