캐싱 전략

 

캐시

 

캐시는 데이터나 값을 미리 복사해놓는 임시 장소를 가리킨다. 캐시의 접근 시간에 비해 원래 DB의 데이터에 접근하는 시간이 오래 걸리는 경우 사용할 수 있다. 캐시에 데이터를 저장해두면 더 빠르게 서비스 해줄 수 있다.

 

파레토의 법칙은 전체 결과의 80%가 상위 20%로부터 기원한다는 법칙이다. 파레토의 법칙은 캐싱을 설명할 때 종종 함께한다. 전체 요청의 80%를 차지하는 20%의 데이터를 예측할 수 있다면 더 효과적인 서비스를 제공할 수 있다는 것이다.

결론은 그 20% 가량의 주요한 데이터를 따로 저장해두고 사용자들에게 제공하자는 것이다. 캐싱 전략은 다양하게 있기 때문에 아래와 같은 요소를 고려하여 적절한 캐싱 전략을 선택해야 한다.

• 쓰기는 자주 발생하고 읽기는 덜 발생하는가? (ex. 시간 기반 로그)
• 데이터를 한 번 쓰고 여러 번 읽는가? (ex. 사용자 프로필)
• 반환되는 데이터가 항상 고유한가? (ex. 검색어)

 

 

 

 

 

1. Cache aside

캐시를 옆에 두고 데이터를 확인하여 있으면 가져오고, 없으면 DB에서 가져오는 방식

1. 클라이언트 요청
2. 서버는 데이터가 존재하는지 캐시를 먼저 확인
   • 캐시에 데이터가 있으면(hit) 그대로 가져온다.
   • 캐시에 데이터가 없으면(miss) DB에서 가져온 후, 그 값을 캐시에 저장한다.

 

장점

• 읽기가 많은 경우 적합하다.
• 실제로 요청하는 데이터만 캐시에 저장되어 있어 리소스를 효율적으로 사용할 수 있다.
• 캐시가 죽어도 어플리케이션에 치명적인 영향을 주지 않는다.

 

단점

• 캐시에 해당 데이터가 없을 때, 캐시를 업데이트 해야하기 때문에 더 느릴 수 있다.
• 캐시에 해당 데이터가 없을 때만 업데이트가 발생하기 때문에, DB에서 데이터가 변경될 시 해당 값을 캐시가 모를 수 있다. 즉, 캐시가 DB의 최신 데이터를 가지고 있지 않을 수 있다.

 

특징

• 가장 범용적으로 쓰이는 방식 중 하나. 레디스를 캐시로 쓸 때 많이 사용한다.
• DB가 업데이트 되었을 때 캐시는 이전 데이터를 가지고 있을 수 있으므로 TTL을 사용하여 캐시 값을 만료시킨다. 만료 전엔 이전 데이터를 반환한다.

 

 

 

 

 

2. Read Through

 

어플리케이션 - 캐시 - DB가 일렬로 배치되어 있고, 항상 캐시에서 데이터를 가져오는 방식

1. 클라이언트 요청
2. 서버는 데이터가 존재하는지 캐시를 먼저 확인
   • 캐시에 데이터가 있으면(hit) 그대로 가져온다.
   • 캐시에 데이터가 없으면(miss) DB로부터 캐시를 업데이트하고, 캐시에서 값을 가져온다.

 

장점

• 읽기가 많은 경우 적합하다.
• 데이터가 만료되는 Cache aside와 달리, 오래된 값이라고 할지라도 항상 캐시에 값이 있기 때문에 많은 병렬 사용자 요청에서 DB 부하가 적다.

 

단점

• 첫 요청은 항상 cache miss가 발생한다.
• 이를 방어하기 위해 미리 캐시를 채워두기도 한다 (Cache Warming)

 

특징

• Look aside와 달리 Read Through의 어플리케이션은 항상 캐시를 바라보고 있다.
• 애플리케이션은 캐시를 기본 데이터 저장소로 취급한다.

 

 

 

 

 

3. Write Through

 

어플리케이션 - 캐시 - DB가 일렬로 배치되어 있고, 항상 캐시를 통해 DB에 데이터를 기록하는 방식

1. 클라이언트 요청
2. 캐시 데이터 업데이트
3. DB 서버는 캐시를 통해 데이터 업데이트

 

장점

• 캐시는 항상 최신 정보를 가지고 있으며 DB 서버와 동기화 되어 있다.

 

단점

• 항상 2단계(캐시→DB)를 거치기 때문에 쓰기 지연 시간이 증가한다.
• 사용하지 않는 데이터도 모두 캐시에 저장된다. 때문에 불필요한 값을 만료시키기 위해 TTL을 사용한다.

 

특징

• Write Through와 Read Through를 함께 사용하면 Read Through의 모든 이점을 얻을 수 있으며 데이터 일관성 보장도 얻을 수 있다.
• 애플리케이션은 캐시를 기본 데이터 저장소로 취급한다.

 

 

 

 

 

4. Write Around

 

데이터를 DB에 직접 기록하는 방식

1. 클라이언트 요청
2. DB 서버에 데이터 업데이트

 

장점

• 자주 사용하지 않는 데이터는 캐시에 저장하지 않기 때문에 불필요한 리소스 낭비가 없다.

 

단점

• 캐시에 기록된 데이터를 DB에서 수정할 경우, 캐시와 DB의 값이 다를 수 있다. 즉, 캐시가 DB의 최신 데이터를 가지고 있지 않을 수 있다.

 

특징

• Look aside와 Read Through 모두와 결합할 수 있다.

 

 

 

5. Write Back

 

특정 시간동안 모든 데이터를 캐시에 써두었다가 DB에 한 번에 기록하는 방식

1. 클라이언트 요청
2. 서버는 모든 데이터를 특정 시간동안 캐시에 저장한다.
3. 특정 시간 이후 캐시의 데이터를 DB에 저장하고, 저장된 데이터는 캐시에서 삭제한다.

 

장점

• 쓰기가 많은 경우 적합하다.
• DB에 쓰는 횟수가 줄어들기 때문에 부하 및 비용을 절감할 수 있다.
• DB에 insert 할 때 1개씩 500번 하는 것 보다, 500개를 1번 하는 것이 훨씬 빠르다.

 

단점

• 장애가 발생하여 다운되면 데이터가 영구히 소실될 수 있다.

 

특징

• Write Back과 Read Through을 함께 사용하면 항상 최신 데이터를 캐시에서 사용할 수 있다.
• 대부분의 RDB 스토리지 엔진 내부에는 Write Back 캐시 기능을 갖고 있다.

 

 

 

 

 

참고 자료

• [Database] 캐싱과 캐싱 전략에 대해 알아보자
• Caching 전략 소개 및 사용 예제
• Caching Strategies and How to Choose the Right One