[부하를 견디는 서버의 비밀, Redis] 캐싱(Caching)의 개념 3

이 글은 인프런 딩코딩코의 백엔드 이력서 차별화 전략 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.

---

어떻게 데이터를 캐싱해야할까? - 데이터 캐싱 패턴

이전에 어떤 데이터를 캐싱할 것인지, 그리고 캐시된 데이터를 언제 만료시킬 것인지에 대해 살펴보았다.

 

🤔 그렇다면 실제로 백엔드 서버는 데이터를 어떤 방식으로 캐시에 저장하고, 불러올까?

즉, 어떠한 패턴으로 캐시 데이터를 다뤄야할까??

 

백엔드 서버에서는 데이터의 읽기와 쓰기 동작에 따라 여러 가지 캐싱 패턴을 사용한다.

📌 캐싱 전략은 크게 데이터 읽기와 쓰기 동작에 따라 구분할 수 있다.

• 읽기 전략 : 데이터 조회 시 캐시를 어떻게 활용할 것인가?
• 쓰기 전략 : 데이터를 저장하거나 수정할 때 캐시를 어떻게 활용할 것인가?

📖 읽기 전략 1. Cache Aside

서버 ↔︎ Cache ↔︎ DB

 

읽기 전략 중, 가장 널리 사용되는 전략은 Cache Aside 패턴이다.

데이터가 필요한 시점에만 데이터를 캐시에 적재한다는 점에서 Lazy Loading 이라고 한다.

1. 먼저 캐시에서 데이터를 조회
2. 캐시에 데이터가 있다면, 즉시 반환
3. 캐시에 데이터가 없다면, DB에서 데이터를 조회한 후, 캐시에 해당 데이터를 저장하고 반환

• 캐시에 값이 존재하는 경우

 

• 캐시에 값이 존재하지 않는 경우

📖 읽기 전략 2. Read Through

캐시에 데이터가 없을 때, 캐시 시스템이 자동으로 DB에서 데이터를 조회하고 캐시에 적재하는 방식이다.

즉, 캐시 미스 발생시 애플리케이션이 직접 DB에 접근하지 않고, 캐시 시스템이 대신 데이터를 가져온다.

1. 먼저 캐시에서 데이터를 조회
2. 캐시에 데이터가 있다면, 즉시 반환
3. 캐시에 데이터가 없다면, 캐시 시스템이 DB에서 데이터를 조회하고, 해당 데이터를 캐시에 저장한 후 반환

Read Through 패턴에서는 캐시 미스가 발생해도 애플리케이션 코드에서 별도 DB를 조회하거나 캐시를 갱신할 필요가 없다.

캐시 시스템이 자동으로 처리해주기 때문에 코드가 단순해지는 장점이 있다.

 

• 캐시에 값이 존재하는 경우

• 캐시에 값이 존재하지 않는 경우

 

❗️비교

 

그런데, 이렇게 보면 Read Through가 I/O도 덜 발생하고 좋을 것 같은데, 왜 Cache Aside를 현업에서는 더 많이 쓸까?

그 이유는 흐름을 어플리케이션에서 직접 제어할 수 있게 하기 위함이다.

Cache Aside 는 캐시 조회부터 DB 조회, 캐시 저장까지 전부 애플리케이션이 컨트롤한다.

그래서 복잡한 조건부 캐싱 로직, 예를 들어 아래 같은 조건들을 세부 설정할 수 있다.

• "이건 절대 캐시하면 안 됨"
• "이건 5분, 이건 10초만 캐싱"
• "조회 로그도 남겨야 함"

Read Through 는 캐시 미스 시 자동으로 DB에 가기 때문에 세부 제어가 어렵다는 이유가 있다.

---

✏️ 쓰기 전략 1. Write Around Aside

쓰기 전략 중, 가장 기본적인 패턴은 Write-Around 패턴이다.

Write-Around는 쓰기 요청이 들어오면 DB에만 데이터를 저장하고, 캐시는 건드리지 않는 방식이다.

1. 데이터 쓰기 요청
2. DB에만 데이터를 변경

✏️ 쓰기 전략 2. Write Through

Write Through는 캐시와 DB 모두에 데이터를 동시에 저장하는 방식이다.

1. 데이터 쓰기 요청
2. 캐시에 먼저 변경 내용을 반영
3. 이후 DB에 변경 내용을 반영

✏️ 쓰기 전략 3. Write Back

Write Back은 쓰기 요청을 캐시에만 반영하고, DB에는 비동기적으로 저장하는 방식이다.

1. 데이터 쓰기 요청
2. 캐시에 먼저 변경 내용을 반영
3. 이후 DB에 변경 내용을 비동기적으로 반영

---

어떻게 데이터 캐싱 패턴을 조합해야할까?

가장 좋은 전략 하나를 선택하면 된다고 생각하기 쉽지만, 실제로는 하나의 전략만으로 실서비스의 요구사항을 모두 충족하기 불가능하다.