Scenario templates

read 95% : write 5%. cache hit 극대화 + index 분리. · cache stampede / hot key / ES 인덱싱 지연 / read-after-write stale

bandwidth heavy. CDN edge cache 90%+. origin 보호. · origin shielding / 첫 viewer cold cache / 메타데이터 vs 미디어 분리

cached-read(70%) → Redis. hit 95%면 Redis가 즉답하고 miss 5%만 MySQL로 내려간다 — 2,000 RPS · 10초 실측: Redis 13,915건, MySQL은 6,685건(db-write 4,000 + db-read-light 2,000 + Redis miss ≈690)만 받는다. Redis cacheHitRate를 0.5로 내리면 miss가 10배가 되어 MySQL 부하가 그대로 따라 올라간다 — 캐시는 "DB 부하 = (1 − hit rate) × read"라는 곱셈식이다.

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 차이를 컨텍스트 스위치 하나의 효과로 단정하면 안 됩니다.

step1과 완전히 같은 부하(7,000 RPS, burst ×3 / 주기 4초)에 Redis + Primary + Replica×2만 붙였다. cached-read 30%는 Redis가, db-read 30%는 replica 2대가 가져가고 primary에는 write 10% + 이벤트 30%만 남는다 → 성공률 65.6% → 100%. 다만 이벤트가 아직 동기 write라 burst 꼭대기에 primary CPU가 90%까지 오르고 p99 꼬리가 62.9ms까지 튄다 — 그 남은 30%를 step3가 가져간다.

Command Service(write) → PostgreSQL + Kafka publish. Query Service x3(read) ← Redis cache + 읽기 모델 DB(denormalized view). 2,000 RPS · read 70 : write 20 : event 10 · 10초 실측: Command 6,002건 · Query 13,926건으로 읽기가 2.3배이고, Query 쪽만 3대로 늘려 CPU 34%를 유지한다(Command는 1대로 32%). 쓰기 경로는 PostgreSQL 3,976건 + Kafka 2,026건(lag 11)이고, Kafka가 읽기 모델 DB로 동기화해 4,020건 — 즉 읽기 모델은 쓰기 모델보다 **한 박자 늦다**(eventual consistency의 실체). 조회 11,922건은 Redis가 먼저 받아 미스만 읽기 모델로 내려간다. 성공률 100% · p50 44.5ms. API Gateway는 3대 — 1대면 CPU 100% + queue-full 1,422건으로 CQRS 교훈과 무관한 포화가 보였다.

단일 진입점(Kong/AWS APIGW) — auth · rate limit(2,500 rps + burst 500) · routing. 3,000 RPS · 10초 실측: 게이트웨이가 25,446건만 통과시키고 **4,631건을 rate-limited(429)로 잘라** 성공률 84.6%다(= 2,500 ÷ 3,000 ≈ 83%). 통과분은 **전부** Auth를 거친 뒤(sequence 1) path에 따라 갈린다: Auth 25,434건(CPU 34%) · User 10,247 · Product 12,667 · Order 2,520. ★ 수정 전에는 auth 엣지가 cached-read만 받게 돼 있어 요청의 20%(5,120건)만 인증을 거쳤다 — 다이어그램은 "모든 요청 JWT 검증"인데 실제로는 아니었다. product_cache도 그때 0건이었다(지금 5,029건, hit 95%). 게이트웨이 자체는 CPU 3%로 한가하다 — 관문의 비용은 CPU가 아니라 "여기서 자르는 정책"이다.

App 10대 scale-out + DB 1대에 10,000 RPS. 10초 실측: App CPU 32%인데 MySQL CPU 88%(피크 93%) — 앱은 놀고 DB만 빨갛다. 산수도 그대로다: App 상한 = 34코어 ÷ 요청당 1.08ms ≈ 31,500 RPS, MySQL 상한 = 6.8코어 ÷ 0.60ms ≈ 11,300 RPS. 연결도 정확히 한계선이다 — App 10대 × Hikari 10 = 100 = max_connections. 여기서 App을 한 대만 더 붙이면 110 > 100이라 초과분이 연결 거절된다(scale-out-pool-exhaustion). 해결: read replica + cache + write sharding.

Black Friday — instance scale-out 직후 cache hit rate 30%(보통 95%). 5,000 RPS · 10초 실측: Redis가 49,465건 중 **34,696건을 miss**(hit 29.9%)로 흘려 MySQL이 34,691건 · CPU **25%**를 받는다. 같은 부하에 hit만 0.95로 되돌리면 DB 몫이 **2,454건**으로 떨어진다 — **14배 차이**다(0.70 ÷ 0.05, 반사실 `@warm`에서 실측). 성공률은 100%지만 그건 이 토폴로지의 DB가 아직 여유가 있어서고, 상한(≈11,000 RPS)의 3배를 넘기는 순간 무너진다 — cold cache가 무서운 건 배수가 크기 때문이다. 해결: cache warmup / pre-fill / 점진 rollout.

short URL → 원본 URL. read 95% / write 5%. 10,000 RPS · 10초 실측으로 캐시 3단이 그대로 곱셈으로 보인다: CDN 94,771건 중 85,279건이 edge hit이고 **9,492건(0.100 = 1 − 0.9)**만 뒤로, 그중 Redis가 9,031건을 또 먹어 **460건(0.048 = 1 − 0.95)**만 replica까지 간다. 즉 조회 9.5만 건 중 DB가 보는 건 460건 = 0.5%다. 생성 5%(4,963건)는 CDN을 우회해 primary로 직행한다. Go 서비스 CPU 24% · 성공률 100% · p50 40.1ms. hash 충돌은 base62 + retry.

cached-read=idempotency check (25%). 같은 key 재호출 시 stored response 즉시 반환 — DB write X. 75%는 새 결제 → DB write. network retry / 더블 클릭 / PG webhook 재전송 흔함. Redis 없으면 같은 결제 2회 = 환불 사고.

TTL 만료 순간 모든 요청이 cache miss → DB 폭증. Redis는 평소 hit 0.95지만 **keyTtlSec 2초**마다 200ms 동안 hit이 0으로 떨어진다(같은 TTL로 채운 키가 동시에 만료되는 순간). 3,000 RPS · burst ×3 / 주기 2초 · 10초 실측: miss 8,352 ÷ 조회 27,120 = **31%** — 만료 창은 시간의 10%(200ms ÷ 2s)뿐인데 그 창이 burst 꼭대기와 겹쳐서 미스가 3배로 부푼다. 결과가 DB의 몰림 배수다: MySQL은 tick당 처리량 최댓값이 평균의 **8.5배**(964 / 113)인데 그 앞의 API는 **3.2배**(도착 burst 그대로)다 — 그 차이 2.7배가 순수 stampede 몫이다. 성공률은 100%지만 DB CPU가 순간 39%까지 튄다. 해결: PER(Probabilistic Early Recompute) / single-flight lock / refresh-ahead / TTL에 지터.