Scenario templates

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

CDN → primary (write+US users) / secondary (read+EU users). cross-region replication lag 80ms (us-east → eu-west). DR 가능, 글로벌 latency 감소 — 단 write는 항상 primary로 (지연 큰 cross-region 호출).

이미지/비디오 service. 10,000 req/s · 10초 실측: CDN이 99,309건을 받아 89,378건은 edge에서 응답하고 9,931건만 origin으로 나간다 — origin 몫 **0.100 = 1 − hit 0.9**가 그대로 곱셈으로 보인다. hit이면 e2e p50 30.1ms(edge 왕복 30ms), miss면 wan 왕복 60ms가 더 붙어 p95 90.4ms. 업로드 1%(100/s)는 CDN을 우회해 Transcoder로 가고(997건), 변환 job 하나가 S3 저장(1) → job_state 기록(2)을 순서대로 한다 — S3가 받는 10,892건 = CDN miss 9,931 + 변환 결과 961. 비용 감각: hit rate를 0.9 → 0.5로 내리면 origin으로 나가는 건수가 5배가 되고 egress 요금도 5배다.

현대 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.

App 3대가 Redis 외부 세션 저장소를 공유하는 구성 예시. 2,000 RPS 중 정적 자원 40%는 CDN, 세션 조회 30%는 Redis, 사용자 조회 30%는 MySQL로 흐른다. CDN miss만 앱에 전달되며 두 저장소가 실제 요청을 받는지 확인한다. 현재 엔진은 사용자 식별·로그인 상태·instance affinity를 모델링하지 않으므로 세션 유실이나 로그아웃, sticky session의 해결 효과는 시뮬레이션하지 않는다.

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.

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).

8,000 req/s · read 80% / post 10% / write 10%. 10초 실측: 타임라인 조회는 CDN이 63,994건 받아 **6,461건(0.101 = 1 − hit 0.9)**만 Timeline Service로 넘긴다. 그 6,461건이 다시 9:1로 갈려 일반 user 5,815건은 미리 채워둔 Redis timeline에서(fan-out-on-write), 셀럽 646건만 읽는 시점에 Cassandra에서 모아온다(fan-out-on-read). 글쓰기 16,000건은 CDN을 우회해 Write Service(CPU 30%)로 가고, post 7,934건은 Kafka → Fanout Worker x8 → Redis에 미리 뿌린다(lag 32). 가장 뜨거운 노드는 Write Service 30% · user/post_db 18% — 읽기 8만 건이 아니라 쓰기 1.6만 건이 비싸다는 게 fan-out의 요점이다. 성공률 100%.

모든 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.