77개 시뮬 시나리오와 4개 목표 빌더, 총 81개 시작점을 카테고리별로 정리했습니다. 카드를 누르면 즉시 로드됩니다.
대규모 service log aggregation. 5,000 evt/s · 10초 실측: App x3이 47,297건을 Kafka로 발행 → Logstash x2가 47,074건 transform → Elasticsearch x3가 **49,562건**(로그 47,074 + Kibana 대시보드 조회 2,488)을 색인한다. lag 224는 흐르는 양이다(전달률 3 partition × 5,000이 유입 4,730/s의 3배). CPU는 Logstash 37% > App 24% > ES 23% — 가장 비싼 건 저장소가 아니라 **파싱**이다(grok 정규식). 대시보드 조회 5%는 Kibana로 직행한다(수정 전에는 Kibana가 in-edge가 없는 죽은 노드였다). 성공률 100%.
log-pipeline시작 →현대 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-search시작 →Elasticsearch refresh interval 노브 비교. 1s=fresh search but throughput ↓ / 30s=throughput ↑ but stale 30s. 카탈로그/추천=30s OK, 로그/실시간 alert=1s 필수.
es-refresh-compare시작 →