이벤트 오픈 직후 서비스가 느려집니다. "캐시 히트율이 20%밖에 안 돼서 DB가 부하를 다 받아요." 인스턴스를 늘렸더니 이번엔 "로그인이 자꾸 풀려요"(세션이 로컬에). "TPS가 한계라는데 어디가 병목인지 모르겠어요." PM·인프라인 당신은 캐시·성능·세션 용어를 알아야 이 문제들의 방향을 잡습니다. 이 사전은 캐시·성능·세션 용어를 빠르게 해독합니다. 깊은 내용은 Redis·성능 관련 모듈로 연결합니다.
- 1캐시 전략(cache-aside·write-through 등)과 히트/미스를 설명할 수 있다
- 2TTL·LRU·eviction으로 캐시 동작과 용량을 이해할 수 있다
- 3세션 외부화가 수평 확장에 필요한 이유를 설명할 수 있다
- 4부하/스트레스/스파이크 테스트와 TPS/QPS·병목으로 성능을 진단할 수 있다
캐시 — 전략과 동작
무엇을 어떻게 캐시하나
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Redis / Memcached | 인메모리 캐시·저장소 | 대표 → [[nosql-kv-redis]] | ★★ |
| Local / Distributed Cache | 프로세스 내 / 공유 캐시 | 분산=일관성↑ | ★★ |
| Cache Hit / Miss / Eviction | 적중 / 빗나감 / 쫓겨남 | 히트율 핵심 지표 | ★★★ |
| TTL / LRU | 수명 / 오래안쓴것부터 제거 | 용량 관리 | ★★ |
| Write-through / Write-back / Read-through / Cache-Aside | 캐시 쓰기·읽기 전략 | Cache-Aside 흔함 | ★★ |
| CDN Cache / Browser Cache / ETag / Last-Modified | 가장자리·브라우저 캐시 | 정적 가속 → [[waf-waap-cdn]] | ★★ |
핵심: 캐시는 '자주 읽고 덜 바뀌는' 데이터에 효과적입니다. 히트율이 낮으면(많이 miss) 캐시 의미가 없으니 키 설계·TTL·용량을 점검합니다. 쓰기 시 캐시-DB 일관성(무효화)이 캐시의 가장 어려운 부분입니다([[nosql-kv-redis]]).
세션 · 연결 재사용
상태와 연결을 효율적으로
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Session Store / Sticky Session | 세션 저장소 / 같은서버 고정 | 외부화 → [[twelve-factor-app]] | ★★★ |
| Token Cache / CDN Cache / Browser Cache | 토큰·CDN·브라우저 캐시 | 계층별 캐시 | ★★ |
| Compression / Gzip / Brotli | 응답 압축 | 전송량↓ | ★★ |
| Lazy / Eager Loading | 지연 / 즉시 로딩 | N+1 관련 → [[orm-basics]] | ★★ |
| Connection Reuse / Keep-Alive / Pooling | 연결 재사용 / 풀링 | 커넥션 풀 → [[connection-pooling]] | ★★ |
핵심: 세션을 로컬에 두면 인스턴스 확장 시 풀립니다 → Redis 등으로 외부화하면 무상태·수평확장이 됩니다([[twelve-factor-app]]·[[tomcat-session-cluster]]). 연결 풀링·Keep-Alive는 매 요청 연결 비용을 줄입니다([[connection-pooling]]).
성능 지표 · 테스트
얼마나 빠르고 얼마나 견디나
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Bottleneck | 병목(가장 느린 구간) | 전체 속도를 지배 | ★★★ |
| Throughput / Latency / TPS / QPS | 처리량 / 지연 / 초당 트랜잭션·쿼리 | → [[glossary-observability]] | ★★ |
| Timeout | 시간 제한 | 슬로우 동반 | ★★ |
| Load / Stress / Spike Test | 부하 / 한계 / 급증 테스트 | 출시 전 검증 → [[benchmark]] | ★★ |
| Benchmark | 성능 기준 측정 | 비교 기준 | ★★ |
핵심: 성능 개선은 '가장 바쁜 곳'이 아니라 병목(가장 느린 구간) 을 푸는 것입니다([[kanban-vs-waterfall]]의 흐름 원리와 동일). 이벤트·세일 전엔 Spike Test로 급증을 견디는지 미리 검증합니다.
성능 병목 진단 — 직접 확인
성능 저하는 캐시·세션·병목 세 축으로 좁힙니다.
1) 캐시 히트율: 낮으면(예: 20%) DB가 부하 → 캐시 키/TTL/용량 점검
2) 세션 위치: 로컬이면 scale-out 시 로그인 풀림 → 외부화([[twelve-factor-app]])
3) 병목: 트레이스로 가장 느린 구간 특정([[glossary-observability]])
- DB(슬로우쿼리/N+1)? 외부 동기호출? GC? 커넥션 풀 고갈?
캐시 히트율 22% → 캐시 키가 사용자별로 너무 잘게 나뉨, 재설계
세션: 톰캣 로컬 → 인스턴스 3개로 늘리자 로그인 풀림 → Redis 세션화
병목 트레이스: DB 조회 80% 점유, N+1 패턴 → eager loading([[orm-basics]])
TPS 한계 1200 → 커넥션 풀(10) 고갈이 천장([[connection-pooling]])
echo '히트율 + 세션위치 + 병목구간 점검'- 캐시 히트율이 낮으면(50% 미만) 캐시 효과 미미 → 키 설계(너무 잘게 나뉨)·TTL(너무 짧음)·용량(잦은 eviction) 점검. 무엇을 캐시할지 재검토
- 인스턴스 늘렸는데 로그인 풀리면 세션이 로컬에 있는 것 → Redis 등으로 외부화 전엔 scale-out이 무의미([[twelve-factor-app]])
- 병목은 "가장 바쁜 곳"이 아니라 "가장 느린 구간" — 트레이스로 특정([[glossary-observability]]). DB·외부호출·GC·커넥션풀 중 무엇인지 가른다
- TPS가 특정 값에서 천장을 치면 자원 한계(커넥션 풀·스레드 풀·CPU) 의심 → 그 한도를 늘려 다시 측정([[connection-pooling]])
상황: 세일 이벤트 오픈 직후 트래픽이 평소의 20배가 되자 서비스가 느려지다 멈춥니다. DB CPU가 100%, 커넥션 풀은 고갈, 응답은 타임아웃됩니다.
원인: 캐시 부재 + 풀 한계입니다. 자주 읽는 상품/재고 데이터를 캐시하지 않아 모든 요청이 DB로 직행하고, 커넥션 풀이 작아 동시 요청을 못 받아냅니다([[connection-pooling]]). 스파이크를 견딜 설계가 없었습니다.
진단:
□ 자주 읽는 데이터에 캐시가 있나? (히트율 측정)
□ 커넥션 풀·스레드 풀 크기가 부하 대비 적정한가?
□ Spike Test로 이 트래픽을 미리 검증했나?
해결: (1) 자주 읽고 덜 바뀌는 데이터(상품·재고)를 Cache-Aside로 캐시해 DB 부하를 덜기([[nosql-kv-redis]]). (2) 커넥션/스레드 풀을 부하 기준으로 재산정([[connection-pooling]]). (3) 비핵심 작업은 비동기로 빼 큐가 스파이크를 완충([[async-event-driven]]). (4) 이벤트 전 Spike Test로 미리 검증([[benchmark]]). 성능은 사고 후가 아니라 사전에 설계·측정하는 것입니다.
인프라/SRE로서 캐시·세션·성능은 확장성 설계의 핵심입니다 — 캐시 히트율·세션 외부화·커넥션 풀·병목을 모니터링하고([[glossary-observability]]), 이벤트 전 부하/스파이크 테스트로 한계를 미리 압니다([[benchmark]]). 깊은 실습은 Redis·성능 모듈에 있습니다. PM은 이 용어로 "느려요"를 "캐시 미적용 / 세션 로컬 / 풀 고갈 / 병목 구간"으로 구체화하고, 대형 이벤트 전 성능 검증을 일정에 넣어 '오픈 직후 마비'를 예방합니다.
다음 용어사전에서는 여러 고객사를 한 시스템에서 다루는 SaaS·멀티테넌트·권한 용어를 정리합니다.