캐시 전략은 무엇일까? - 2

https://hyeonni.tistory.com/111

캐시(Cache) 무엇일까? - 1

이전 글에서는 캐시(Cache)에 대해 설명했다.

이번 글에서는 캐시를 어떤 방식으로 활용하는지 즉 캐시 전략에 대해 다룬다.

 

캐시

캐시 전략이란?

캐시 전략이란 다음과 같은 요소를 고려하여 캐시를 운영하는 방법을 의미한다.

• 어떤 데이터를 캐시에 저장할 것인가?
• 캐시 데이터를 얼마 동안 유지할 것인가?
• 오래된 데이터를 어떻게 제거할 것인가?
• 캐시 크기를 얼마나 설정할 것인가?

 

캐시 전략이 필요한 이유

 

캐시는 빠른 데이터 접근을 위해 메모리(RAM)에 데이터를 저장하는 방식이다. 

데이터베이스(DB)는 디스크를 활용하기 때문에 대량의 데이터 저장에 용이하지만 속도가 상대적으로 느리다.

 

하지만 캐시는 메모리 용량이 한정적이므로 불필요한 데이터를 적절히 삭제하는 전략이 필요하다. 이를 통해 성능을 유지하면서도 데이터 정합성을 보장할 수 있다.

 

 

캐시 관련 용어

 

캐시 전략을 이해하기 위해 먼저 알아야 할 용어들이 있다.

• Cache Hit : 캐시에 데이터가 존재하여 빠르게 가져오는 경우
• Cache Miss : 캐시에 데이터가 없어 DB에서 조회해야 하는 경우

 

캐시 사용 시 고려해야 할 점

캐시를 사용하면 데이터 정합성(Data Consistency) 문제가 발생할 수 있다.

• 데이터 정합성이란 캐시와 데이터베이스의 데이터가 불일치하는 상황을 의미한다.
• 잘못된 캐시 데이터를 사용하면 사용자에게 오래된 정보가 제공될 수 있다.

이런 문제를 해결하기 위해 캐시 전략은 크게 캐시 읽기(Read) 전략과 캐시 쓰기(Write) 전략으로 나뉜다.

 

 

캐시 전략의 목표

• DB 부하를 줄이면서 빠른 응답 속도를 유지한다.
• 캐시와 DB 간의 데이터 불일치 문제를 최소화한다.

 

 

---

설명하기에 앞서서 아래 캐시 이미지를 대표적으로 캐시를 많이 쓰이는 Redis 로 두었다.

캐시 읽기(Read) 전략

• 캐시 읽기 전략은 데이터를 조회할 때 캐시와 데이터베이스(DB)를 어떻게 활용할지를 결정하는 방식이다.

 

1. Cache Aside (Look Aside)

• 데이터를 조회할 때 우선 캐시에서 찾는다. (Cache Hit)
• 캐시에 데이터가 없으면 DB에서 조회한 후, 캐시에 저장한다. (Cache Miss)
• 애플리케이션이 직접 캐시를 관리하는 방식으로 가장 널리 사용되는 전략이다.

✅ 장점

 

✔ 캐시에 저장할 데이터를 애플리케이션이 제어할 수 있어 유연하다.

✔ 필요한 데이터만 캐시에 저장하므로 메모리를 절약할 수 있다.

 

❌ 단점

 

✖ Cache Miss 시 DB 조회로 인해 성능이 저하될 수 있다.

✖ 캐시에 데이터가 갱신되지 않으면 정합성 문제가 발생할 수 있다.

 

 

 

2. Read Through

• 캐시에서만 데이터를 조회하며 캐시에 없는 경우 캐시가 DB에서 데이터를 가져와 저장한다.
• 애플리케이션은 항상 캐시를 통해서만 데이터를 읽는다.
• 정합성이 중요한 시스템에서 적합하다.

✅ 장점

 

✔ 데이터 정합성이 유지된다.

✔ 캐시가 자동으로 데이터 갱신을 담당하므로 개발자가 직접 관리할 필요가 없다.

 

❌ 단점

 

✖ Redis 같은 캐시 서버가 다운되면 데이터를 조회할 수 없어 서비스 운영이 어려울 수 있다.

✖ Cache Aside 방식보다 구현이 복잡할 수 있다.

 

---

캐시 쓰기(Write) 전략

• 캐시 쓰기 전략은 데이터를 저장할 때 캐시와 DB를 어떻게 동기화할지를 결정하는 방식이다.

 

1. Write Back

• 데이터를 캐시에 먼저 저장하고 DB에는 일정 주기마다 비동기적으로 반영한다.
• 캐시에만 데이터를 저장하는 방식이므로 쓰기 성능이 뛰어나며 DB 부하를 줄일 수 있다.
• write가 빈번하면서 read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
• 대량 데이터 저장 서비스에서 적합

✅ 장점

 

✔ 쓰기 성능이 우수하며, DB의 부하를 줄일 수 있다.

✔ 빈번한 쓰기 작업이 필요한 경우 적합하다.

 

❌ 단점

 

✖ 캐시에 장애가 발생하면 데이터가 DB에 반영되지 못해 데이터 영구 손실 가능성이 있다.

✖ DB와의 데이터 정합성을 유지하기 어렵다.

 

 

 

2. Write Through

 

• 데이터를 저장할 때 캐시와 DB에 동시에 기록하는 방식이다.
• 항상 최신 데이터를 유지할 수 있어 정합성이 보장된다.
• DB 동기화를 캐시에게 위임한다.
• 데이터 일관성을 유지 할 수 있어 안정적
• 그래서 데이터 유실이 발생하면 안되는 상황에 적합

✅ 장점

 

✔ 데이터 정합성이 유지된다.

✔ 캐시와 DB의 데이터가 항상 동기화된다.

 

❌ 단점

 

✖ 매번 DB와 캐시에 두 번 저장해야 하므로 성능이 저하될 수 있다.

✖ 쓰기 작업이 많은 서비스에서는 부적합하다.

✖ 매 요청마다 두번의 Write 가 발생 하여 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈 발생

 

 

 

3. Write Around 

• 데이터를 저장할 때 캐시에 쓰지 않고, DB에만 저장하는 방식이다.
• 읽기 요청이 많지 않은 데이터에 적합하며 캐시의 공간을 절약할 수 있다.
• 한 번만 조회되는 데이터에 적합

✅ 장점

 

✔ 캐시에 불필요한 데이터를 저장하지 않아 메모리 효율적 사용 가능

✔ 캐시에 쓰기 부하가 없으므로 쓰기 성능이 향상됨

 

❌ 단점

 

✖ DB에 저장된 새로운 데이터는 바로 캐시에서 조회할 수 없다.

✖ Cache Miss 발생률이 높아질 수 있다.

 

 

여기까지가 캐시전략의 종류이다.

 

실제 서비스에서는 단일 캐시 전략만을 사용하는 경우는 드물며, 보통 여러 전략을 혼합하여 사용한다.

 

예를 들어 Cache Aside + Write Around 조합을 사용하면 자주 조회되는 데이터는 캐시에 저장하면서도, 쓰기 부하를 줄일 수 있다.

 

캐시는 단순히 속도를 높이는 도구가 아니라, 데이터 정합성과 성능 간의 균형을 유지하는 핵심 요소이다.

따라서 우리가 구축하는 서비스에서 어떤 캐시 전략을 선택할지 그리고 데이터 정합성을 어떻게 유지할지를 신중하게 고민해야 한다.

---

💡 마무리

캐시를 도입하는 이유는 단순히 속도를 높이기 위해서가 아니라, 서비스의 특성에 맞는 최적의 방식으로 성능을 개선하기 위해서다.

 

따라서, 무작정 캐시를 적용하기보다는 우리의 서비스에서 캐시가 필요한 부분과 적절한 전략을 고민하고 설계하는 과정이 필수적이다.

 

 

 

 

 

 

다음 글에서는 작자가 실제 프로젝트에서 적용했던 캐시 전략의 예시를 설명할 예정이다.