캐시를 적용하면 좋은 시나리오

캐시(Cache) 란?

캐시는 자주 사용되는 데이터를 임시로 저장하여, 속도를 향상하고 시스템 부하를 줄이는 역할을 합니다. 데이터베이스나 다른 외부 저장소에서 데이터를 직접 조회할 때 발생하는 시간 지연을 줄이기 위해 자주 액세스하는 데이터를 메모리나 다른 빠른 저장소에 보관합니다.

 

캐시 사용 이유

1. 자주 요청되는 데이터를 캐시에 저장하여, 반복된 데이터 접근 시 외부 데이터 소스를 조회하는 대신 빠르게 응답할 수 있다.
2. 캐시를 사용하면 데이터베이스나 다른 서버와의 통신을 최소화할 수 있어 시스템 자원 사용을 효율적으로 관리할 수 있다.

캐시를 유용하게 사용하려면

• 동일한 데이터에 대해 반복적으로 액세스 하는 상황이 많을 때 사용하는 것이 좋다.
• 변경이 적은 데이터일수록 캐시를 사용할 때 더 효율적이다.

---

로컬 캐시 글로벌 캐시

로컬 캐시

• 장점: 외부 저장소를 사용하지 않아 속도가 빠르다.
• 단점: 서버마다 각기 다른 캐시를 저장하기 때문에 변경 사항이 생길 경우 동기화가 즉시 이루어지지 않는다.

글로벌 캐시

• 장점: 외부 저장소를 이용하기 때문에 즉각적으로 동기화가 반영된다.
• 단점: 로컬 캐시와 비교했을 때 네트워크, 디스크 비용이 발생하므로 속도가 느릴 수 있어 장애 대비가 필요하다.

---

캐시를 Redis로 선택한 이유

1. 단순한 key-value구조와 다양한 자료 구조 지원으로 사용이 간편하다.

•  List, Set, Hash, Sorted Set 등 다양한 자료 구조를 지원하여 다양한 데이터 처리.

2. 스프링에서 redis 라이브러리 지원

• Redis와의 통합을 지원하는 여러 라이브러리를 제공하여 개발과 관리가 용이.

3. 데이터 만료 및 자동 삭제

• TTL(Time-To-Live) 설정이 가능하여 지정된 시간이 지나면 자동으로 데이터를 삭제하도록 관리.
• 불필요한 데이터가 메모리에서 오래 차지하지 않도록 관리.

4. Pub/Sub 기능

• Pub/Sub(Publish/Subscribe) 메시징 패턴을 지원하여 데이터 변경 사항을 실시간으로 전파.
• 여러 애플리케이션 인스턴스 간 캐시 일관성을 유지하는데 유용.

---

캐싱 전략(Caching Strategies)

캐싱 전략은 시스템 성능에 큰 영향을 미치며, 데이터 유형과 액세스 패턴을 고려하여 선택해야 합니다. 주로 읽기 전략과 쓰기 전략으로 나눠집니다.

읽기 전략 (Read Strategies)

1. Look-aside(Lazy Loading)

애플리케이션이 데이터를 읽을 때 캐시를 먼저 확인하고, 없으면 DB에서 데이터를 가져와 Redis에 저장하는 방식으로 캐시 미스를 통해 DB 부하를 줄일 수 있습니다. 하지만 캐시가 비어 있을 때 DB로 요청이 몰리면 성능 저하가 발생합니다. 이를 방지하기 위해서는 캐시 워밍이 필요합니다.

• 캐시 미스: 캐시에 원하는 데이터를 찾지 못하고 DB나 다른 데이터 소스를 조회하는 상황.
• 캐시 워밍: 데이터를 미리 캐시에 저장하여 DB 부하를 방지하고 성능을 최적화하는 방법.

2. Read Through

캐시에서 데이터를 직접 조회하며, 데이터 동기화는 캐시 제공자나 라이브러리에 맡기는 방식으로 캐시가 항상 최신 데이터를 반영하고 데이터 정합성 문제가 없습니다. 하지만 캐시만 의존하면 Redis가 다운될 경우 서비스에 문제가 발생할 수 있습니다. 그래서 데이터 동기화 관리가 중요합니다.

쓰기 전략(Write Strategies)

1. Write-around

DB에 데이터를 저장하고 캐시 미스가 발생할 경우 DB에서 데이터를 읽어와 캐시에 저장하는 방식입니다. 캐시가 일부 요청에서만 데이터를 저장하므로, 자주 읽히지 않은 데이터에 적합니다. 자주 사용되지 않은 데이터의 캐시 오버헤드를 줄일 수 있고, 캐시에 저장되지 않은 데이터에 대해 불필요한 캐시 업데이트가 일어나지 않아 효율적입니다. 그러나 데이터가 수정되더라도 캐시에 즉시 반영되지 않기 때문에 캐시에 최신 정보를 보장하지 못합니다.

 

2. Write-through

DB에 데이터를 저장할 때 캐시에도 동시에 저장하여 항상 최신 정보를 캐시에 유지하는 방식입니다. 캐시와 DB 간의 데이터 일관성을 보장되고 데이터가 항상 최신 상태로 유지합니다. 그러나 DB와 캐시 두 군데에 데이터를 저장해야 하므로 성능이 저하될 수 있습니다. 재사용되지 않은 데이터가 캐시에 쌓일 위험이 있어서 만료 시간을 설정하여 불필요한 캐시 점유를 방지하는 것이 중요합니다.

---

조회가 오래 걸리는 쿼리에 대한 캐싱 시나리오

콘서트 예약 가능한 날짜 조회

Look Aside + Write through 조합으로 해당 시나리오에 적용된다면 적합할 거 같습니다. 데이터 조회 시 사용자가 콘서트 예약 가능한 날짜를 조회하면 캐시에서 먼저 확인하고 만약 캐시가 비어 있거나 해당 날짜 정보가 없으면 DB에서 조회하고 그 결과를 캐시에 저장합니다.

 

데이터 업데이트 시 콘서트 예약 가능한 날짜가 변경되면 DB에 저장하고, 캐시에 데이터를 삭제하거나 변경된 날짜 정보를 반영하여 캐시를 갱신합니다. 캐시와 DB 간의 데이터 일관성을 유지할 수 있습니다.

 

자주 조회되는 데이터에 대해 캐시를 활용함으로써 DB 부하를 줄이고 빠른 응답을 제공하고 데이터 변경이 있을 때 캐시와 DB 모두 최신 데이터를 반영하도록 처리하여 데이터가 일관성 있게 사용하는 전략이 좋을 거 같다. 추가적으로 캐시를 먼저 확인하고 캐시 미스에만 DB를 조회하여 네트워크 트래픽을 줄이고 데이터를 조회의 효율성을 높일 거 같습니다.

 

끝.