시나리오 템플릿

현대 e-commerce 검색 — CDN(결과 캐시) · Keycloak JWT auth · Elasticsearch(키워드) + pgvector(의미) · click 이벤트 Kafka → ClickHouse. 3,000 RPS · 10초 실측: 캐시 가능한 조회 60%는 CDN이 17,788건 받아 16,070건을 edge에서 끝내고 **1,718건(0.097 ≈ 1 − hit 0.9)**만 뒤로 넘긴다 — 그래서 Keycloak은 JWT 검증을 1,717건만 한다. 나머지 40%는 CDN을 우회해 API GW로 직행하고(질의 900/s · 클릭 300/s), 검색 한 건이 ES(8,974)와 pgvector(8,971)를 **둘 다** 거친다. 가장 뜨거운 노드는 pgvector CPU 27% — 벡터 유사도가 키워드 검색보다 비싸다는 게 카드에서 갈린다. 클릭 3,066건은 Kafka를 거쳐 ClickHouse 3,047건. 성공률 100% · e2e p50 40.3ms.

50,000 req/s · 10초 실측: CDN이 488,938건을 받아 464,300건을 edge에서 끝내고 **24,638건이 miss → origin LB 24,529건(24,529 ÷ 488,938 = 0.050 = 1 − hit 0.95)**으로 나간다 — 5%가 곱셈으로 그대로 보인다. 그 5%가 origin에서는 여전히 2,450 RPS라 Origin Service를 16대나 써야 CPU 52%다(4대면 상한 ≈1,200 RPS로 2배 초과 — hit rate 1%p가 origin 용량 20%다). hit이면 p50 30.2ms, miss면 wan 왕복 80ms가 붙어 p99 115.4ms. origin 요청 하나는 metadata 조회(1) → S3 마스터 사본(2)을 순서대로 한다. 추천 2%(1,000 RPS)는 개인화라 캐시 대상이 아니어서 CDN을 우회한다(Recommendation x4 CPU 54% · pgvector 9,895건). CDN과 추천 API는 모두 CPU 약61%이며 캐시 miss 비율이 origin 부하를 결정한다. 성공률 100%. Adaptive Bitrate(HLS chunks) · Open Connect(자체 CDN).

사용자 query → Agent Orchestrator(LangGraph) → LLM Gateway(rate limit/cost) · Vector DB(RAG retrieval) · Tool Registry(function call) · Memory Fabric(대화 history 기록). 200 RPS · 10초 실측: Orchestrator 2,100건 · CPU 32%(피크 54%), LLM Gateway 1,074건 · CPU 28%, Vector DB 607건, Tool Registry 202건, Memory 213건 — 성공률 100% · p50 51.6ms · p99 156.3ms. RPS가 200뿐인데 CPU가 30%대인 것이 LLM 파이프라인의 성격이다(요청 하나가 비싸다 — throughput이 아니라 단가가 제약). ★ pgvector는 이 모델에서 **단말**이라 다음 노드로 안 넘긴다 — 그래서 retrieval을 Memory Fabric 뒤가 아니라 Orchestrator가 직접 Vector DB에 치도록 뒀다(예전 배선에서는 Vector DB 처리량이 0건이었다). cost tracking 핵심 — LLM call 당 $0.05~0.50.