[SW Eng] 용어사전 — Cache / 성능 / 세션

핵심: 캐시는 '자주 읽고 덜 바뀌는' 데이터에 효과적입니다. 히트율이 낮으면(많이 miss) 캐시 의미가 없으니 키 설계·TTL·용량을 점검합니다. 쓰기 시 캐시-DB 일관성(무효화)이 캐시의 가장 어려운 부분입니다(캐시(Cache) 전략, 세션 스토어, Pub/Sub 실무 패턴).

캐시가 "빠르다"는 건 알지만, 정작 요청 하나가 들어왔을 때 캐시 안에서 어떤 판단이 순서대로 일어나는지를 그려보지 않으면 히트율·stale·스탬피드 같은 문제가 왜 생기는지 감이 안 옵니다. 캐시의 핵심은 단 하나 — 원본(느린 DB·API)보다 가까운 곳에 답을 복사해 두고, 다음엔 그 사본으로 답하는 것입니다. 아래 흐름은 조회(hit/miss)부터 쓰기·무효화·축출까지, 캐시가 응답을 빠르게 하면서 동시에 어떤 위험을 떠안는지를 한눈에 보여줍니다.

[앱]  getProduct(42) 요청
   │
   ① 캐시 조회   GET product:42
   │
   ├─ HIT (값 있고 안 만료)  ─────────→ 즉시 반환 (수십 마이크로초, DB 안 감)
   │
   └─ MISS (없거나 TTL 만료)
         │
         ② 원본 조회   SELECT * FROM product WHERE id=42   (수 ms~수십 ms)
         │
         ③ 캐시에 저장  SET product:42 ... EX 300          (TTL 300초 부여)
         │
         ▼ 반환 → 이후 같은 키 요청은 ①에서 HIT

  [쓰기]  updateProduct(42)
     ├─ write-through : DB와 캐시를 즉시 함께 갱신 (동기, 일관성↑)
     ├─ write-back    : 캐시만 먼저, DB는 나중에 (빠르나 유실 위험)
     └─ 무효화        : DEL product:42 → 다음 조회 때 새로 채움 (가장 흔함)

  [용량 초과]  maxmemory 도달 → LRU·LFU로 오래·덜 쓴 키부터 축출(eviction)

각 단계가 하는 일과, 여기서 어긋나면 나타나는 증상:

즉 캐시는 "빠른 저장소"가 아니라 "원본의 사본을 가까이 두는 규칙" 이고, 그 대가로 원본과 어긋날(stale) 위험·동시 miss 폭주(stampede) 위험을 떠안습니다. 그래서 문제를 좁힐 때는 먼저 어느 계층 캐시인지(브라우저 → CDN → 앱 인메모리 → 분산 캐시(Redis) → DB 버퍼)를 정하고, 그 계층의 히트율(효과 있나)·stale(정확한가)·stampede·지연(위험한가) 세 축으로 봅니다. 히트율이 높은데도 느린 순간이 있다면 원인은 캐시 바깥이 아니라 캐시 내부 동작에 있습니다(아래 심화 참고).

핵심: 세션을 로컬에 두면 인스턴스 확장 시 풀립니다 → Redis 등으로 외부화하면 무상태·수평확장이 됩니다(12-Factor App·Tomcat 세션 클러스터링과 Redis 세션 외부화). 연결 풀링·Keep-Alive는 매 요청 연결 비용을 줄입니다(DB 연결 지연을 없애는 HikariCP 설정과 대기 성능 튜닝).

핵심: 성능 개선은 '가장 바쁜 곳'이 아니라 병목(가장 느린 구간) 을 푸는 것입니다(칸반 vs 스크럼 vs 워터폴의 흐름 원리와 동일). 이벤트·세일 전엔 Spike Test로 급증을 견디는지 미리 검증합니다.

히트율과 병목으로 문제를 좁히는 법을 익혔다면, 다음은 히트율이 높은데도 느려지는 경우입니다. 이때 원인은 대개 캐시 바깥이 아니라 캐시 내부 동작에 있습니다.

• Redis는 명령을 한 줄로 처리합니다: Redis는 명령 실행이 단일 스레드라, 오래 걸리는 명령 하나가 뒤의 모든 명령을 줄 세웁니다. 수십만 키를 한 번에 훑는 KEYS, 거대한 컬렉션을 통째로 읽는 명령이 대표적입니다 — 그 몇백 ms 동안은 히트율 99%의 캐시도 전체 요청에 대해 멈춥니다. 운영 Redis에서 KEYS를 금지하고 조금씩 나눠 훑는 SCAN으로 대체하는 이유입니다.
• 빅키(big key): 값 하나가 수 MB면 읽을 때마다 직렬화·네트워크 전송 비용이 크게 붙고, 지울 때(DEL)도 동기 삭제라 그 순간 전체가 막힙니다. 큰 값은 나눠 저장하고, 큰 키 삭제는 백그라운드로 처리하는 UNLINK를 씁니다.
• 핫키(hot key): 특정 키 하나(오늘의 메인 상품 등)에 트래픽이 집중되면 클러스터로 노드를 늘려도 소용없습니다 — 한 키는 한 노드에만 살기 때문입니다. 이때는 노드 추가가 아니라, 앱 인스턴스 안의 수명 짧은 로컬 캐시로 그 키의 원격 조회 자체를 줄이거나 키를 여러 사본으로 복제해 분산합니다.
• 평균이 아니라 p99를 봅니다: 위 현상들은 대부분 순간 스파이크라 평균 지연에는 거의 드러나지 않습니다. 요청 100건 중 99건이 1ms, 1건이 500ms면 평균은 6ms지만, 화면 하나가 캐시를 수십 번 조회하는 구조에선 거의 모든 화면이 그 느린 1건을 한 번은 밟습니다(꼬리 지연 증폭). 캐시 성능은 평균이 아니라 p99(느린 쪽 1%)로 봐야 이런 문제가 보입니다.

히트율은 캐시가 일을 하는지를, p99는 캐시가 발목을 잡는 순간을 알려줍니다 — 둘을 함께 봐야 온전한 그림입니다.