캐시(Cache)란 무엇일까?

🌿 캐시(Cache)란?

 

캐시(Cache)란 자주 사용되는 데이터나 연산 결과를 임시로 저장하여 빠르게 접근할 수 있도록 하는 저장소입니다.
주로 CPU, 메모리, 디스크, 네트워크, 데이터베이스 등 다양한 영역에서 성능 최적화를 위해 사용됩니다.

 

 

🌿 캐시의 목적과 필요성

1. 성능 향상

• 동일한 데이터를 반복적으로 요청할 경우, 캐시에 저장된 데이터를 사용하면 처리 속도가 빨라짐.
• 특히 CPU, RAM, 웹 브라우저, 데이터베이스에서 성능 최적화에 필수적.

2. 부하 감소

• 데이터베이스(DB) 조회나 API 호출 비용이 클 경우, 캐싱을 활용하여 시스템 부하를 줄일 수 있음.
• 트래픽이 많은 서비스에서 서버의 부하를 줄이고 응답 속도를 개선.

3. 네트워크 비용 절감

• 캐시를 사용하면 불필요한 데이터 요청을 줄여 네트워크 트래픽을 최소화.
• CDN(Content Delivery Network)에서 원본 서버 대신 캐시된 데이터를 제공하여 대역폭 사용을 줄임.

 

🌿 캐시의 동작 방식

 

캐시는 기본적으로 Key-Value 형태의 데이터 저장소로 동작하며, 일반적인 흐름은 다음과 같습니다.

p.s) 캐시의 방법별로 다를 수 있지만 가장 기본적인 형태를 설명!

 

 일반적인 캐싱 흐름

 

1. 요청(Request) 발생
   • 사용자가 특정 데이터를 요청.
2. 캐시 확인
   • 요청한 데이터가 캐시에 존재하는지 확인 (Cache Hit 또는 Cache Miss).
3. 캐시 데이터 반환 또는 원본 데이터 요청
   • Cache Hit: 캐시에 존재하면 즉시 반환.
   • Cache Miss: 캐시에 없으면 원본 데이터(DB, API 등)에서 가져와 저장 후 반환.

 

 

출처 : 항해 플러스

 

🌿 캐시 전략(Cache Strategy) 

 

캐시 전략은 원본 데이터 저장소(예: 데이터베이스)와 캐시가 데이터를 어떻게 동기화하는지에 대한 방법론입니다. 이 글에서는 대표적인 전략 4가지에 대해 정리 했습니다!

 

Look-Aside 전략

 

📌 개념

• Cache Aside 패턴이라고도 불림.
• 데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는 지 확인 후 캐시에 데이터가 없으면 DB에서 조회
• 캐시와 DB가 분리되어 가용되는 형태이다.
• Cache store에 저장하는 주체가 Server(애플리케이션)이다.

📌 동작 방식

1. Cache Store에 검색하는 데이터가 있는 지 확인 (cache hit)
2. Cache Store에 없을 경우 DB에서 데이터 조회 (cache miss)
3. DB에서 조회해온 데이터를 Cache Store에 업데이트

 

📌 장점

• 반복적인 읽기가 많은 호출에 적합하다.
• 캐시와 DB가 분리되어 가용되기 때문에 캐시 장애 대비가 쉬움 -> 만일 redis가 다운 되더라도 DB에서 데이터를 가져올 수 있다.

📌 단점

• 캐시에 붙어있던 connection이 많았다면 , redis가 다운된 순간 DB로 몰려서 부하가 발생할 수 있다.
• Cache Store와 DB간 정합성 유지 문제가 발생할 수 있다.

 

Read-Through 전략

 

📌 개념

• 읽기 요청 시 캐시에 데이터가 없으면 캐시 시스템이 직접 원본 데이터베이스에서 조회 후 캐시에 저장
• Look Aside 와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이가 있음.
• 이후 동일한 요청이 들어오면 캐시에서 데이터를 반환하여 DB 부하를 줄임

📌 동작 방식

1. 클라이언트가 데이터 요청
2. 캐시에서 해당 데이터 조회 (Cache Hit 확인)
   1. 있다 -> 캐시에서 즉시 반환
   2. 없다(Cache Miss) -> DB에서 데이터 가져옴
3. 가져온 데이터를 캐시에 저장 (갱신)
4. 클라이언트에게 데이터 반환

📌 예제 코드 - Spring

@Cacheable(value = "users", key = "#userId")
public User getUser(Long userId) {
    return userRepository.findById(userId).orElseThrow();
}

//캐시에 userId가 없으면 DB에서 조회 후 저장

 

📌 장점

• 캐시가 자동으로 로딩되므로 일관성 유지
• DB 부하 감소 (자주 조회되는 데이터 최적화)

📌 단점

• DB와의 결합이 높음 (DB가 변경되면 캐시가 최신 상태를 유지하는지 확인이 필요함)
• 최초 요청 시 지연 발생

 

Write-Through 전략

 

📌 개념

• 데이터 변경(쓰기) 시, 캐시와 DB에 동시에 저장
• 이후 읽기 요청이 들어오면 항상 최신 데이터가 캐시에 존재

📌 동작 방식

1. 클라이언트가 데이터 업데이트 요청
2. 캐시와 DB에 동시에 저장
3. 이후 읽기 요청이 오면 항상 최신 데이터가 캐시에서 반환

📌 예제 코드 - Spring

@CachePut(value = "users", key = "#user.id")
public User updateUser(User user) {
    return userRepository.save(user);
}

//updateUser 실행 시, DB와 캐시에 동시에 반영됨

 

📌 장점

• 항상 최신 데이터 유지
• 읽기 성능 최적화 

📌 단점

• 쓰기 성능 저하 가능성 (캐시와 DB를 동시에 업데이트 하므로)
• 불필요한 캐시 저장 가능 (자주 조회되지 않는 데이터까지 캐시에 저장)

 

Write-Around 전략

 

📌 개념

• 쓰기 시 DB에만 저장하고, 캐시는 업데이트하지 않음
• 이후 데이터 조회 시(Cache Miss) DB에서 가져와 캐시에 저장

📌 동작 방식

1. 클라이언트가 데이터 업데이트 요청
2. DB에 데이터 저장 , 캐시는 업데이트 하지 않음
3. 클라이언트가 데이터를 요청할 때 캐시 미스 발생
4. DB에서 데이터를 가져온 후 캐시에 저장
5. 이후 동일한 요청은 캐시에서 처리

📌 Tip

Write Around 패턴은 주로 Look aside, Read through와 결합해서 사용된다.
데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공한다.

 

📌 장점

• 항상 최신 데이터 유지
• 읽기 성능 최적화 

📌 단점

• 쓰기 성능 저하 가능성 (캐시와 DB를 동시에 업데이트 하므로)
• 불필요한 캐시 저장 가능 (자주 조회되지 않는 데이터까지 캐시에 저장)

 

Write-Back(Write-Behind) 전략

 

📌 개념

• 쓰기 요청 시, 캐시에 먼저 저장 후 비동기적으로 DB 업데이트
• DB 부하를 줄이기 위해 일정 시간 동안 변경 사항을 모아서 배치 업데이트

📌 동작 방식

1. 클라이언트가 데이터 업데이트 요청
2. 캐시에 먼저 저장 (즉시 반영)
3. 백그라운드 프로세스가 비동기적으로 DB 업데이트
4. 이후 읽기 요청은 캐시에서 즉시 제공

📌 예제

@CachePut(value = "users", key = "#user.id")
public User cacheUser(User user) {
    return user; // DB에는 나중에 비동기 저장
}

 

📌 장점

• 쓰기 성능 최적화 (DB 부하 최소화)
• 빠른 응답 속도 (즉시 캐시에 반영)

📌 단점

• 데이터 유실 가능성 (캐시 장애 발생 시 데이터 손실)
• 일관성 문제 (DB 반영 전에 캐시가 변경될 수 있음)

 

비교 표 정리  

 

 

✅ 캐시전략 선택 기준

사용 사례	추천 캐시 전략
자주 조회되는 데이터, 읽기 성능 중요	Read-Through , Look-Aside
항상 최신 데이터 유지 필요	Write-Through
쓰기 부담 줄이고, 자주 조회되지 않는 데이터	Write-Around
쓰기 성능 최적화, 비동기 DB 반영 가능	Write-Back

 

 

🌿 캐시 사용 시 고려할 부분

 

1. 데이터 일관성 문제

• 캐시는 최신 데이터가 아닐 수 있으므로, 적절한 갱신 전략이 필요.

2. 캐시 스탬피드(Cache Stampede) 방지

• 다수의 클라이언트가 동시에 캐시 미스(Cache Miss) 발생 시, 서버 부하 증가.
  p.s) 하단의 추가 설명

3. 캐시 오버헤드

• 캐시 데이터가 너무 많으면 메모리 사용량 증가 → 효율적인 관리 필요.

4. 캐시 중복(Cache Redundancy)

• 여러 계층에서 캐시를 사용할 경우, 중복 저장으로 인해 불필요한 메모리 낭비 발생.

📌 Cache Stampede 현상

 

대규모 트래픽 환경에서 TTL 값이 너무 작게 설정하면 cache stampede 현상이 발생할 가능성이 있습니다.

만약 Look-aside 패턴에서 redis에 데이터가 없다는 응답을 받은 서버가 직접 DB로 데이터 요청한 뒤,

 

다시 redis에 저장하는 과정을 거친다. 그런데 위 상황에서 key가 만료(Key Expires)되는 순간 많은 서버에서

이 key를 같이 보고 있었다면 모든 어플리케이션 서버에서 DB로 가서 찾게 되는 duplicate read 가 발생한다.

 

또 읽어온 값을 각 redis에 쓰는 duplicate write도 발생되어, 처리량도 다 같이 느려질 뿐 아니라 불필요한 작업이

많이 늘어나 요청양 과다로 장애까지 이어질 수 있는 상황을 Cache Stampede 현상이라고 부릅니다. 

 

 

🌿 대표적인 캐시 사용 기술

 

📌 인메모리 캐시

• Redis: 고성능 Key-Value 저장소로, TTL, LRU 등 다양한 정책 지원.
• Memcached: 분산 캐시 시스템으로, 빠른 속도를 제공하지만 지속성이 없음.

📌  애플리케이션 캐시

• Spring Cache: Spring Boot에서 캐싱을 쉽게 적용할 수 있도록 지원.
• Ehcache: Java 기반 캐싱 라이브러리.

📌  네트워크 캐시

• Cloudflare, Akamai (CDN): 웹 콘텐츠를 캐싱하여 성능 향상.
• NGINX 캐싱: 웹 서버에서 정적 파일을 캐싱하여 응답 속도 개선.

 

🌿 결론

 

 

캐시는 성능 최적화에 필수적인 기술로, CPU, 메모리, 네트워크, 데이터베이스 등 다양한 환경에서 활용되며

 

적절한 TTL 설정, 캐시 교체 정책, 동기화 전략을 사용하면 효율적인 캐싱이 가능합니다. 

 

주로 Redis, DNS , CDN, 브라우저 캐싱 등을 활용하여 서비스 속도와 안정성을 향상할 수 있습니다.