캐시란 무엇인가

캐시란 무엇인가

 

 

 

 

캐시란?

데이터를 임시로 저장하는 공간 또는 저장된 데이터, 즉 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 저장소입니다. 일반적으로 캐시는 메모리에 저장되기 때문에 데이터베이스 보다 훨씬 빠르게 데이터를 전송할 수 있어 데이터 요청 시 빠르게 서비스를 제공할 수 있습니다.

웹 캐싱은 사이트 방문자의 경험을 향상시키는 가장 효과적인 방법으로 특정 규칙에 따라 재사용 가능한  HTTP 응답을 저장하여 이후의 요청을 더 빠르게 처리하는 기술로 동일한 요청이 발생할 경우 원본 서버까지 가지 않고 더 가까운 위치에서 응답을 제공할 수 있습니다. 해당 방식을 통해 애플리케이션 캐시 및 메모리 캐시는 특정 응답 속도를 높이고 네트워크 트래픽을 최소화하며 시스템의 응답성을 향상시키는 역할을 합니다.

Cache란 한번 조회된 데이터를 미리 특정 공간에 저장해 놓고, 똑같은 요청이 발생하게 되면 서버에게 다시 요청하지 말고 저장해 놓은 데이터를 제공해서 빠르게 서비스를 제공해 주는 것이다.

 

캐시를 사용하는 이유

처음 서비스를 구성할 때 WEB-WAS-DB 정도로 작게 인프라를 구축하여 시작하지만, 이용자가 증가할수록 특정 비즈니스의 조회가 동일한 시간대에 몰리는 현상이 발생할 때 데이터베이스에 부하가 생길 수 있다.

데이터베이스는 데이터를 물리 디스크에 직접 쓰기 때문에 서버에 문제가 발생해도 데이터가 손실되지는 않지만, 매 트랜잭션마다 DB 커넥션을 사용하여 데이터베이스에 접근해야 하므로 부하가 많아지면 성능이 떨어진다.

그래서 사용자가 늘어나면 데이버베이스를 스케일 인 또는 스케일 아웃하는 방식 외에도 캐시 서버를 검토하게 된다.

캐싱하기 좋은 콘텐츠

• 로고 및 브랜드 이미지
• 정적 이미지(네비게이션 아이콘 등)
• 스타일시트(CSS)
• 일반적인 JavaScript 파일
• 다운로드 가능한 콘텐츠
• 미디어 파일

1. 캐시 저장(Write) 전략

🔹 Write-Through

• 데이터를 DB와 캐시에 동시에 저장하는 방식
• 캐시 메모리에서 데이터가 몇 번 수정되든 소스 메모리에서도 동일하게 수정되어 캐시와 소스 메모리 간의 버스를 통한 엄청난 트래픽으로 인해 성능에 영향을 미칠 수 있다.
• 장점: 데이터 일관성이 높음
• 단점: 쓰기 성능이 DB 성능과 동일하게 제한
• 사용 사례: 읽기보다 쓰기가 잦은 시스템

🔹 Write-Back (Write-Behind)

• 데이터를 캐시에 먼저 저장한 후, 나중에 배치로 DB에 반영하는 방식
• 캐시 메모리가 교체될 때 소스 메모리에 다시 쓰여집니다. 소스 메모리는 항상 한 번만 쓰여집니다
• 장점: 쓰기 성능이 빠름
• 단점: 캐시에 장애가 발생하면 데이터 유실 가능성
• 사용 사례: 로그 데이터 저장, 임시 데이터 처리

🔹 Write-Around

• 데이터를 DB에만 저장하고, 읽을 때만 캐시에 저장하는 방식
• 장점: 불필요한 캐시 업데이트 방지 → 캐시 오염을 줄임
• 단점: 최초 조회 시 캐시에 데이터가 없어 느릴 수 있음(캐시 미스)
• 사용 사례: 자주 읽히지 않는 데이터 처리

 

2. 캐시 갱신(Invalidate) 전략

🔹 TTL (Time-To-Live)

• 캐시에 저장된 데이터가 일정 시간이 지나면 자동으로 삭제
• 장점: 오래된 데이터 자동 제거 → 데이터 신뢰성 유지
• 단점: TTL이 너무 짧으면 캐시 미스 증가, 너무 길면 오래된 데이터 유지 가능
• 사용 사례: API 응답 캐싱, 세션 관리

🔹 LRU (Least Recently Used)

• 오래 사용하지 않은 데이터를 우선 제거하는 방식
• 장점: 자주 사용되는 데이터 유지, 메모리 효율적 사용 가능
• 단점: 갑자기 데이터 패턴이 바뀌면 성능 저하 가능
• 사용 사례: 메모리 제한이 있는 환경(예: Redis, 브라우저 캐시)

🔹 LFU (Least Frequently Used)

• 사용 빈도가 가장 낮은 데이터를 제거하는 방식
• 장점: 사용되지 않는 데이터가 오래 남지 않음
• 단점: 최근 갑자기 사용량이 늘어난 데이터가 먼저 제거될 수 있음
• 사용 사례: 트래픽이 일정한 시스템(예: 뉴스 기사 추천)

3. 캐시 일관성 유지 전략

🔹 Lazy Loading (Cache-aside)

• 필요할 때만 DB에서 데이터를 가져와 캐시에 저장하는 방식
• 장점: 자주 쓰이는 데이터만 캐시에 저장
• 단점: 최초 조회 시 캐시 미스 발생 가능

🔹 Eager Loading (Read-Through)

• 데이터가 DB에 저장될 때 자동으로 캐시에도 저장하는 방식
• 장점: 캐시 미스가 거의 없음
• 단점: 필요하지 않은 데이터도 캐시에 저장될 가능성 있음

🔹 Write-Through + Read-Through

• 데이터를 캐시에 저장할 때 읽기/쓰기 모두 캐시를 거치도록 하는 방식
• 장점: 데이터 일관성 유지 가능
• 단점: 캐시에 대한 의존성이 높음

 

캐시 사용 시 주의사항 - 캐시스탬피드 현상

여러 프로세스가 동시에 동일하게 캐시 된 콘텐츠를 재생성하려고 할 때 발생한다. 특정 데이터가 캐시에서 만료되었을 때, 다수의 요청이 동시에 해당 데이터를 조회하려고 하면서 데이터베이스나 원본 서버에 과부하를 유발하는 현상이다.

💡 어떻게 발생할까?

1. 특정 데이터가 캐시에서 만료
2. 캐시를 참조하던 다수의 요청이 캐시 미스를 발생
3. 각 요청이 동시에 데이터베이스로 접근하여 데이터를 가져옴
4. 순간적으로 데이터베이스에 과부하가 걸리면서 성능 저하 및 장애 발생

📌 해결 방법

🔹 캐시 만료 시간을 랜덤화 

• 모든 캐시 데이터가 동시에 만료되지 않도록 만료 시간을 약간씩 다르게 설정하는 방식
• TTL을 10분 + 랜덤(0~30초)으로 설정하면, 모든 데이터가 한꺼번에 만료 방지

🔹 캐시 리프레시 전략 적용

• 캐시가 만료되기 전에 백그라운드 작업을 통해 미리 데이터를 갱신하는 방식
• 대표적인 기법: Lazy-Refresh, Background Refresh
• 캐시 만료 전에 새로운 데이터를 미리 로드

🔹  Mutex Lock (분산 락) 사용

• 첫 번째 요청자가 데이터를 갱신하는 동안, 다른 요청자들은 기다리도록 설정하는 방식
• Redis의 SETNX(Set if Not Exists) 또는 Redisson의 RLock을 활용 가능
• 여러 요청이 한꺼번에 DB로 가는 것을 방지

 

정리
최적의 캐싱 전략을 선택하는 핵심은 "시스템의 데이터 특성과 요구 사항을 정확히 이해하는 것"입니다. 
읽기 성능, 쓰기 성능, 데이터 일관성 중 어떤 것을 우선순위로 고려할지 고민하여 가장 적절한 전략을 적용해야 합니다.
캐시는 적절한 설계와 관리가 뒷받침될 때 최고의 성능을 발휘합니다!

 

 

 

참고 

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EA%B0%9C%EB%85%90-%EC%86%8C%EA%B0%9C-%EC%82%AC%EC%9A%A9%EC%B2%98-%EC%BA%90%EC%8B%9C-%EC%84%B8%EC%85%98-%ED%95%9C%EB%88%88%EC%97%90-%EC%8F%99-%EC%A0%95%EB%A6%AC?category=918728#redis-%ED%99%9C%EC%9A%A9%ED%95%98%EA%B8%B0---%EC%BA%90%EC%8B%9Ccache

[REDIS] 📚 레디스 소개 & 사용처 (캐시 / 세션) - 한눈에 쏙 정리

https://medium.com/silenttech/caching-strategies-8c9d80f507b8

Caching Strategies