Redis의 캐싱전략(2)

Write 전략

1. Write Back ( Write Behind )

Write Back은 조회보다는 DB의 지속적인 업데이트를 위해 사용하는 전략이다. Redis에 데이터를 인메모리 방식으로 저장한 뒤, 크론 작업이나 잡 큐를 통해 일정 주기로 데이터를 DB에 반영하는 방식이다.

어디에 활용이 되는가 ?

예를 들어, 좋아요 요청을 구현할 때를 생각해볼 수 있다. 한 사용자가 지속적으로 좋아요를 누르는 경우, 애플리케이션의 앞단에서 방어 로직을 구현할 수도 있지만, 만약 DB와 계속 연결이 이루어진다면 불필요한 자원 낭비가 발생하게 된다.

DB는 단일 실패 지점(Single Point of Failure)이 될 가능성이 있기 때문에, DB로의 요청을 최소화하는 것이 중요하다. Redis를 활용하면 좋아요 요청을 메모리에 저장해 두었다가 일정 주기로 Bulk Write 방식으로 DB에 반영할 수 있다.

이 전략은 Redis를 단순한 캐시 툴이 아니라 인메모리 DB로 활용하는 대표적인 방식이다. 물론, 인메모리 DB로 사용할 경우 서버에 문제가 생기면 데이터 유실 위험이 있지만, AOF(Append-Only File)와 스냅샷 같은 데이터 영속성 옵션을 적절히 활용하면 이를 해결할 수 있다.

2. Write-Through

Write-Through는 데이터를 Redis와 DB에 동시에 저장하는 방식이다. 이 방식은 항상 최신 데이터를 Redis에서 가져올 수 있다는 장점이 있으며, Redis와 DB가 동기화 상태를 유지하기 때문에 데이터의 일관성이 보장된다.

하지만 두 번의 쓰기가 이루어지기 때문에 리소스 낭비가 발생할 가능성이 있다. 이러한 단점을 보완하기 위해 Write-Through는 주로 Look-Aside 패턴과 혼합하여 사용되는 경우가 많다.

3. 알아두면 좋을 것

전략 패턴은 단독으로 사용되는 경우가 드물고, 여러 패턴이 혼합되어 활용되는 경우가 많다. 구현하려는 서비스의 목적에 맞게 다양한 읽기/쓰기 패턴을 조합하여 사용하는 것이 바람직하다.

기술 블로그나 레거시 코드에서 인사이트를 얻는 것도 좋은 방법이다

또한, 파레토 법칙에 따르면 전체 트래픽의 80%는 20%의 사용자로부터 발생한다고 한다. 즉, 이 20%의 트래픽을 적절히 캐싱 처리한다면 서비스의 안정성을 유지하는 데 큰 문제가 없을 것이다.

정리