77 simulation scenarios and 4 goal builders give you 81 starting points. Pick a card to load it immediately.
기본 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%가 된다.
three-tierOpen →리포트 다운로드 API — 300 RPS인데 응답 버퍼가 512KB라 힙 회전이 CPU보다 빠르다. heap 64MB(parallel)에서 10초 동안 young GC 3회, Spring CPU는 32%(피크 53%)로 한가한데 p99 꼬리는 91.9ms까지 튄다. 같은 트래픽에 heap만 2,048MB로 되돌리면 GC 0회 · p99 51.2ms — 바뀐 건 힙 크기 하나뿐이다. "CPU에 여유가 있으니 괜찮다"가 왜 틀린 말인지 보여주는 프리셋.
gc-pressureOpen →병목은 한 번에 하나씩만 보인다 — 3단 실측(1,500 RPS · 10초). ① 풀 5 + HDD: 성공률 2.4%, 드롭 14,280건 중 queue-full 12,856 · pool-exhausted 1,424(acquireTimeout 1s 만료). 화면만 보면 "풀이 작아서"다. ② 풀만 50으로 늘리면 성공률 2.4% 그대로 — 진짜 상한은 디스크다: HDD 200 IOPS ÷ 요청당 5.7 IOPS(db-read-heavy 8 : db-write 2 가중) ≈ 35 RPS. ③ 디스크를 SSD(5,000 IOPS)로 바꾸면 24.6%로 뛰고, 이번엔 Spring CPU가 100%다(db-read-heavy 15.4ms/req ÷ 3.4코어 ≈ 220 RPS). 노브 하나를 고칠 때마다 다음 벽이 나온다.
pool-exhaustionOpen →Spring threads를 50 ↔ 200 ↔ 400으로 바꿔보세요. 동기 호출이라 thread가 응답 동안 점유되어 처리량이 정확히 비례합니다.
external-depOpen →HAProxy가 3개 Spring backend로 분배. 알고리즘 변경(roundrobin/leastconn/source)으로 분배 패턴 비교 가능.
lb-distributionOpen →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 차이를 컨텍스트 스위치 하나의 효과로 단정하면 안 됩니다.
reactiveOpen →결제 시스템 v1 — LB → Spring 3종(각 2대) → 단일 MySQL. 세 step은 부하가 완전히 같다: 평균 7,000 RPS에 burst ×3 / 주기 4초(1.33초 동안 21,000 RPS, 나머지 2.67초는 0). 평균만 보면 MySQL 상한(≈12,500 RPS)에 여유가 있지만 꼭대기 21,000은 못 받는다 → 10초 실측 MySQL CPU 피크 100%, 앱 스레드가 DB를 기다리다 accept queue가 넘쳐 성공률 65.6%(드롭 29,120건 전부 queue-full). read·write·이벤트가 전부 한 DB로 몰리는 게 원인이다.
evolution-step1Open →실제 K8s 계층 — Cluster > Pod > Container. production 클러스터(16c/64GB)에 web-pod(NGINX+Spring, sidecar) + db-pod(MySQL) 두 Pod. limits/replicas는 Pod-level.
k8s-pod-demoOpen →단일 Spring App x6에 4개 도메인(auth + order + inventory + reward) 통합. 도메인 간 호출이 함수 호출이라 네트워크 홉이 0이다. 3,000 RPS · 10초 실측: 29,787건 · App CPU 53% · MySQL 28% · **p50 45.9ms · p99 54.3ms** · 성공률 100%. 같은 부하·같은 mix를 4개 서비스로 쪼갠 v16-msa는 **p50 86.8ms · p99 105.0ms**로 41ms 느리다 — 그 41ms가 "MSA의 가격표"다(대신 팀 독립 배포·기술 선택·장애 격리를 산다). 비교: v16-msa.
v16-monolithOpen →Monolith Spring x3 + MySQL 1대. auth + order + payment 한 코드. 단순 / 빠른 개발 / 강한 트랜잭션. 한계: 한 도메인 부하가 전체 영향.
strangler-step1Open →