Scenario templates

기본 1,000 RPS에서 Spring(Tomcat) CPU 63%, MySQL 11% — 3-tier에서 먼저 차는 건 앱이다. 슬라이더를 1,500(CPU 91%) → 1,700(99%, p99 291ms)으로 올리면 앱 한 대의 상한이 보이고, 2,000부터 accept queue가 넘쳐 queue-full 드롭이 시작된다(성공률 89.2%). MySQL은 같은 mix로 ≈8,800 RPS를 감당해서(앱 상한의 5배) 이 토폴로지에선 병목이 되지 않는다 — Spring을 6대로 늘려 10,000 RPS를 통과시켜야 비로소 MySQL CPU가 100%가 된다.

3,000 RPS · cached-read 50 : db-read-light 40 : db-write 10. Client → NGINX → Spring WebFlux → PostgreSQL 구성입니다. WebFlux의 ioWorkerCount=8, R2DBC 풀=30에서 시작해 한 번에 하나씩 바꿔 보세요. worker를 1로 줄이면 CPU 작업 병렬성이, R2DBC 풀을 1로 줄이면 DB 동시 호출이 제한됩니다. 비차단 I/O도 응답까지 커넥션·메모리·timeout을 유지합니다. 이 프리셋에는 Tomcat 비교 노드가 없습니다. 앱 프레임워크까지 바꾸는 별도 실험에서는 기본 CPU 비용과 JVM 설정도 달라지므로 CPU 차이를 컨텍스트 스위치 하나의 효과로 단정하면 안 됩니다.

실제 K8s 계층 — Cluster > Pod > Container. production 클러스터(16c/64GB)에 web-pod(NGINX+Spring, sidecar) + db-pod(MySQL) 두 Pod. limits/replicas는 Pod-level.

NGINX mirror 모듈이 production 트래픽을 v2로 **복제**한다(택일이 아니다). 1,500 RPS · 10초 실측: v1이 15,004건 전량을 처리하고 v2가 사본 14,624건(97.5%)을 받는다 — 빠진 2.5%는 v2에 심어둔 2% error + 50ms 지연 때문에 v2 안에서 죽은 사본(timeout 307)이고, **사용자 성공률은 100%**다. 사본은 root 결과를 정산하지 않으므로 v2가 흔들려도 사용자는 모른다. 대신 값은 치른다: CPU가 v1 60% · v2 63%로 **거의 같다**(비용 2배). shadow_db가 v1의 MySQL과 같은 14,624 : 15,005를 받는 것이 side-effect 격리의 증거 — 이걸 안 나누면 v2의 write가 production 데이터를 오염시킨다.