[Redis] Caching 전략 및 가이드

Database는 애플리케이션의 핵심이지만 잦은 데이터 조회는 성능 저하 & 부하를 일으킬 수 있습니다.

Cache는 자주 사용하는 데이터를 메모리에 저장하여 Database 조회 비용과 응답 시간을 줄임으로써 위에 있는 문제를 해결하는데 중요한 역할을 합니다.

• 목적 : Cache는 Memory Access이고 Database는 I/O 작업이기 때문에 훨씬 빠르게 조회 가능 및 부하 감소
• 한계 : Cache와 Database 간 불일치 가능성 존재

Redis Caching 전략

데이터를 어떻게 저장하고 Database와 어떻게 동기화할지에 따라 크게 3가지로 나눠질 수 있습니다.

✔️ Cache Aside (Lazy Loading)

가장 보편적으로 사용되고 구현하기 쉬운 전략 중 하나입니다.

이름처럼 애플리케이션이 캐시를 "옆에 두고" 필요할 때만 사용하는 방식입니다.

1. 데이터를 요청하면 우선적으로 캐시에서 데이터를 조회합니다.
2. Cache Miss 발생 시 데이터베이스에서 해당 데이터를 조회합니다.
3. 데이터베이스에서 가져온 데이터를 캐시에 저장한 후 반환
4. 동일한 데이터 요청이 들어오면 캐시에서 바로 데이터를 반환

필요한 데이터만 캐시에 저장되므로 메모리 효율성이 좋지만 초기 Cache Miss 발생 시 Database에 부하가 집중될 수 있으며 서비스 초기나 신규 데이터 요청 시 자주 발생하게 됩니다.

또한 데이터 변경 시 무효화 로직이 필요하고 오래된 데이터의 경우 삭제하거나 갱신하여 데이터 불일치 문제를 어느 정도 해결해야 합니다.

GitHub - dukbong/Cache-Aside-Pattern: Cache-Aside Pattern

✔️ Write Through

캐시와 데이터베이스 간의 일관성을 강력하게 유지하는 데 중점을 둔 전략입니다.

데이터 쓰기 작업 시 캐시와 데이터베이스에 동시에 반영합니다.

1. 데이터 쓰기 요청이 발생하면 Cache에 해당 내용을 갱신
2. 거의 동시에 Database에도 동일한 내용을 쓰기 작업을 수행
3. 캐시와 데이터베이스 모두에 쓰기 작업이 성공해야만 응답이 반환

Cache와 Database 간 일관성을 유지하기 좋지만 구현이 복잡하고 쓰기 성능이 다른 전략들에 비해 느린 편에 속합니다.

• Cache와 Database 모두 작업을 해야 하기 때문입니다.

✔️ Write Back (Behind)

가장 빠른 쓰기 성능을 제공하지만 데이터 유실 및 일관성 문제에 대한 고려가 필요한 전략입니다.

1. 데이터 쓰기 요청이 발생하면 우선적으로 Cache에 내용을 갱신하고 즉시 응답을 반환
2. 비동기적(실제로는 kafka, rabbitmq 등 사용)으로 Database 쓰기 작업이 수행되며 일정 주기 또는 특정 조건이 만족될 때 Database에 Batch Update 하는 방식이 흔히 사용

3가지 전략 중 가장 빠른 갱신 및 쓰기 작업이 가능하며 Database에 쓰기 부하를 줄일 수 있지만 Redis 장애 발생 시 Database에 저장되지 않은 데이터까지 영구적으로 손실될 수 있으며 비동기적으로 Database에 쓰기 작업을 하다 보니 데이터 일관성 문제가 발생할 수 있습니다.

🔚 전략 선택 방법

각 Redis Caching 전략들은 장단점이 확실하기 때문에 요구사항에 맞춰 선택해야 합니다.

• Cache Aside : 읽기 작업은 많이 중요하지만 일관성은 큰 상관이 없는 서비스
• Write Through : 쓰기 작업이 많이 발생하지 않으면서 일관성이  많이 중요한 서비스
• Write Back : 초고속 쓰기 작업이 필수적이면서 데이터 유실에 대한 별도 메커니즘 있는 서비스