77 simulation scenarios and 4 goal builders give you 81 starting points. Pick a card to load it immediately.
광고 click stream 8,000 RPS(이벤트 90% + BI ad-hoc 8% + 대시보드 point query 2%). App → Kafka → Ingest가 batch insert → ClickHouse 4 shard, BI API는 같은 ClickHouse에 ad-hoc query. 10초 실측: 초당 640건뿐인 BI 쿼리가 BI API CPU를 73%까지 밀어올리는 동안, 이벤트 7,200/s를 다 받아낸 ClickHouse는 9%다. 컬럼나 OLAP에서 먼저 마르는 건 저장소가 아니라 쿼리를 들고 기다리는 API 쪽이다 — ad-hoc 동시성(동시 쿼리 상한 · 타임아웃 · 큐)이 진짜 운영 노브.
olap-analyticsOpen →현대 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.
ecommerce-searchOpen →cookie/user_id hash로 50/50 split. 2,000 RPS · 10초 실측: Variant A 9,969 : B 9,953 = **0.500 : 0.500**이고 CPU도 29% : 28%로 같다. B에는 새 알고리즘을 흉내낸 지연을 심었는데 그게 p50 56.4ms에 섞여 나온다 — A/B의 관측 대상이 "성공률"이 아니라 "분포"라는 뜻이다. 실험 이벤트는 응답 경로가 아니라 **mirror 사본**이라 Kafka가 19,924건(A+B 처리량과 1:1) → ClickHouse 19,817건을 받는다(수정 전에는 워크로드 필터에 밀려 Kafka·ClickHouse가 0건이었다). 사본이라 metric 수집이 밀려도 사용자 지연에는 안 잡힌다. statistical significance 확인 후 rollout.
v15b-ab-testOpen →모든 instance에 v2 코드 배포 (deploy). 활성화는 flag로 (release). user_id % 100 < flagPercent → v2 path. 즉시 rollback = flag off. 3,000 RPS · 10초 실측: flag 평가 조회는 CDN/Redis 2단 캐시가 먹어 SDK 서버(go)는 **1,444건(CDN 14,912건의 0.097 = 1 − hit 0.9)**만 보고 CPU 3%다 — "매 요청 flag 평가"가 무섭지 않은 이유. 앱은 16,412건을 처리하며 CPU 43%. flag 평가 로그는 응답 경로가 아니라 **mirror 엣지**로 Kafka에 복제되므로(16,415건 = 앱 처리량과 1:1) 사용자 지연에 영향이 없고, ClickHouse가 16,336건을 소비해 lag은 79건에서 머문다. 성공률 100% · p50 45.0ms. LaunchDarkly / Unleash / GrowthBook.
v15b-feature-flagOpen →