04 캐싱전략

1. Note

• 결론은 다 동일한데, 이걸 어떻게 해석하고 어떤 타이밍에 하는가에 대한 문제
• 이론을 탄탄하게 복습하고 학습!
• 체력도 길러야해..!

2. 캐싱

1. 캐싱

• 자주 접근하는 데이터를 임시 저장소(메모리나 디스크)에 저장하여, 동일한 데이터 요청 시 더 빠르게 제공하는 기술
• 캐싱은 속도와 성능을 향상시키기 위해 자주 사용하는 데이터의 중복 작업을 줄임
• 저장소 유형
  • 인메모리 저장소: RAM에 데이터를 저장하여 빠르게 접근.
  • 디스크 기반 저장소: SSD/HDD에 캐싱 데이터를 저장(일반적으로 속도는 RAM보다 느림).

2. 캐싱의 장점

1. 속도 향상 (Performance)

• 캐시는 메모리 기반으로 동작하여 DB 쿼리나 API 호출보다 훨씬 빠른 응답 제공
• 동일 요청에 대해 반복적인 연산 없이 즉시 결과 반환
• 예시: 검색 기능 캐싱
  • 사용자가 동일한 검색어를 반복 조회하는 경우 캐시에서 즉시 응답
  • 흐름

    요청 1 → DB 조회 → 결과 캐시 저장  
    요청 2 → 캐시 조회 → 즉시 응답
    

• 효과
  • 응답 속도 대폭 개선
  • 사용자 체감 성능 향상

2. 부하 감소 (Load Reduction)

• 반복 요청을 캐시가 처리하여 DB 및 API 서버의 부하 감소
• 트래픽 증가 상황에서도 시스템 안정성 유지
• 예시: 인기 게시글 조회
  • 조회수가 높은 게시글을 캐싱하여 DB 접근 최소화
  • 비교

     [캐싱 전]
     1000명 요청 → DB 1000번 조회
      
     [캐싱 후]
     1000명 요청 → DB 1번 + 캐시 999번
    

• 효과
  • DB 커넥션 및 CPU 사용량 감소
  • 트래픽 급증 상황에서도 안정적인 서비스 제공

3. 3. 비용 절감 (Cost Efficiency)

• DB 호출 및 외부 API 요청 횟수를 줄여 인프라 비용 절감
• 시스템 확장(Scale-up/Scale-out) 필요성 감소
• 예시: 외부 API 호출 캐싱
  • 환율, 날씨 등 자주 조회되지만 자주 변하지 않는 데이터를 캐싱
  • 흐름

    요청 1 → 외부 API 호출 → 캐시 저장 (TTL: 24시간)  
    요청 2~N → 캐시 데이터 재사용
    

• 효과
  • API 호출 횟수 감소
  • 과금 비용 절감 및 Rate Limit 대응

3. 캐싱 고려할점

1. 데이터 일관성 문제 (Consistency)

• 캐시는 원본 데이터(DB 등)의 복사본이기 때문에
• 데이터 변경 시 캐시와 실제 데이터 간 불일치(Stale Data) 발생 가능
• 예시
  • 상품 가격이 변경되었지만 캐시에는 이전 가격이 남아있는 경우
  • 해결 방법
    • TTL(Time To Live) 설정으로 일정 시간 후 자동 갱신
    • 데이터 변경 시 캐시 직접 삭제 (Evict)

2. 메모리 용량 한계 (Memory Limit)

• Redis, Local Cache 등은 메모리(RAM)를 사용하므로 저장 공간이 제한됨
• 데이터가 많아질수록 메모리 부족 문제 발생 가능
• 해결 방법

  • Eviction 정책 적용

    정책	설명
    LRU	가장 오래 사용되지 않은 데이터 제거
    LFU	가장 적게 사용된 데이터 제거

3. 캐시 무효화 문제 (Cache Invalidation)

• 데이터 변경 시 캐시를 언제/어떻게 갱신할지 결정하는 것이 어려움
• 잘못 처리하면 오래된 데이터 제공
• 예시
  • 게시글 수정 후에도 이전 내용이 계속 조회되는 문제
  • 해결 방법
    • Write 시 캐시 삭제 (Cache Evict)
    • 또는 캐시 갱신 (Write Through)

3. 캐싱 전략

1. 캐싱 조회 전략

• 조회의 패턴은 거의 동일함.
• 단지 캐싱 타이밍에 따라서 데이터가 있고 없음의 차이가 커서 전략이 구분됨
• 조회패턴
  • 클라이언트가 데이터를 요청하면, 애플리케이션은 먼저 Redis 캐시에서 해당 데이터를 조회
  • 캐시에 데이터가 존재하면 Cache Hit
    • 즉시 캐시에서 데이터를 반환하여 매우 빠른 응답 속도를 제공
    • 추가적인 작업 없이 응답 완료
  • 캐시에 데이터가 없으면 Cache Miss
    • 애플리케이션은 DB와 같은 원본 데이터 소스에서 데이터를 조회
    • 조회된 데이터를 사용자에게 반환
    • 동시에 Redis 캐시에 저장하여 다음 요청에 대비

2. Cache-aside (캐시-어사이드) 패턴

1. Cache-aside

• “쓰기 전략”이라기보다 “조회 중심 캐싱 전략”, 쓰기 시 처리 규칙도 같이 포함된 패턴이기는 함.

2. 데이터의 흐름

• 데이터 변경 요청이 발생하면 애플리케이션은 먼저 DB를 업데이트
• DB 업데이트가 완료된 후, 해당 데이터에 대한 캐시를 삭제(Evict)
• 이후 동일 데이터 요청이 들어오면 Cache Miss가 발생하고, 최신 데이터가 다시 캐시에 저장됨

3. 장단점

• 장점
  • 구조가 단순하고 구현이 쉬워 빠르게 도입 가능
  • 필요한 데이터만 캐싱하는 Lazy Loading 방식으로 메모리 효율이 좋음
  • 반복 요청을 캐시가 처리하여 DB 부하를 크게 줄이고 성능 향상
  • 캐시 또는 DB 장애 상황에서도 유연하게 fallback 처리 가능
  • Redis, 로컬 캐시 등으로 확장 및 변경이 쉬움
• 단점
  • DB와 캐시가 분리되어 있어 데이터 일관성 문제가 발생할 수 있음
  • Cache Miss 시 결국 DB를 조회해야 하므로 첫 요청이 느릴 수 있음
  • 캐시 만료 시 다수 요청이 동시에 DB로 몰리는 Stampede 위험 존재
  • 데이터 변경 시 캐시 무효화(Evict) 로직을 직접 관리해야 함

3. Write-through (라이트-스루) 패턴

1. Write-through

• 조회는 일반적인 Cache-First 패턴을 따르고
• 쓰기 시 캐시와 DB를 동시에 업데이트해서 항상 캐시에 최신 데이터를 유지하는 방식

1. 데이터 흐름

• 데이터 변경 요청이 발생하면 애플리케이션은 먼저 캐시에 데이터를 저장
• 캐시에 저장된 데이터는 동시에 DB에도 함께 반영됨 (동기 처리)
• 캐시와 DB가 항상 동일한 상태를 유지하도록 보장

3. 장단점

• 장점
  • 데이터 변경 시 캐시와 DB가 동시에 업데이트되어 일관성이 높음
  • 읽기 시 항상 캐시에서 최신 데이터 조회 가능 (Cache Hit율 높음)
  • 캐시 무효화(Evict) 로직이 거의 필요 없어 관리가 단순함
  • 데이터 조회 시 DB 접근이 거의 없어 안정적인 성능 유지 가능
• 단점
  • 쓰기 작업 시 DB와 캐시를 동시에 처리해야 하므로 성능 저하 가능
  • 사용되지 않는 데이터까지 캐시에 저장되어 메모리 낭비 발생 가능
  • 캐시 장애 발생 시 쓰기 작업 자체가 실패할 수 있음

4. Write-back (라이트-백) 패턴

1. Write-back

• 캐시에 먼저 반영하고, DB에는 나중에 비동기적으로 반영하는 방식

2. 데이터 쓰기 흐름

• 데이터 변경 요청이 발생하면 애플리케이션은 DB를 거치지 않고 먼저 캐시에 데이터를 저장
• 캐시에 반영된 데이터는 사용자에게 즉시 응답으로 반환됨
• 동시에 변경 내역은 큐나 버퍼에 저장되고, 이후 일정 시점에 DB에 비동기적으로 반영됨
• 여러 번의 변경이 모여 한 번에 DB에 반영될 수 있음 (Batch 처리)

3. 장단점

• 장점
  • 쓰기 작업을 캐시에만 먼저 반영하므로 매우 빠른 응답 속도 제공
  • DB 쓰기 횟수를 줄여 전체적인 시스템 부하 감소
  • 여러 번의 쓰기를 모아서 처리(batch) 가능해 효율적인 DB 사용 가능
  • 트래픽이 많은 쓰기 작업에서 높은 성능을 발휘
• 단점
  • 캐시와 DB 간 데이터 불일치 가능성 (일관성 낮음)
  • 캐시 장애 시 아직 DB에 반영되지 않은 데이터 유실 위험 존재
  • 구현이 복잡하고, 동기화 및 장애 복구 로직 필요
  • 데이터 반영이 지연되므로 실시간성이 중요한 서비스에는 부적합

5. Write-around (라이트-어라운드) 패턴

1. Write-around (라이트-어라운드)

• 쓰기 시 캐시를 거치지 않고 바로 DB(RDB)에 저장하는 방식
• 갱신 주기 전까지는 데이터가 계속 처음과 같음.

2. 데이터 쓰기 흐름

• 데이터 변경 요청이 발생하면 애플리케이션은 캐시를 거치지 않고 바로 DB에 데이터를 저장
• 캐시는 이 과정에서 아무 작업도 수행하지 않음
• 이후 해당 데이터에 대한 조회 요청이 들어올 때 Cache Miss가 발생하고, 그때 캐시에 데이터가 저장됨

3. 장단점

• 장점
  • 쓰기 시 캐시를 거치지 않고 바로 DB에 저장하여 쓰기 성능이 안정적
  • 불필요한 데이터가 캐시에 쌓이지 않아 메모리 효율이 좋음
  • Write-heavy 환경에서 캐시 오염을 줄일 수 있음
  • 캐시에는 실제로 조회된 데이터만 남아 효율적인 활용 가능
• 단점
  • 데이터 저장 직후에는 캐시에 없어서 첫 조회 시 Cache Miss 발생
  • 반복 조회되는 데이터라도 초기에는 DB를 거쳐야 하므로 성능 저하 가능
  • 캐시 적중률(hit rate)이 낮아질 수 있음
  • 읽기 성능 개선 효과가 Cache-Aside보다 떨어질 수 있음