Redis Purge 를 사용할 경우 문제점

• 쓰기 작업을 수행할 때 캐시 무효화를 위해 기존 값을 삭제하는 방식에서는 문제가 생길 수 있다
• 더불어 읽기 조회시 캐시 전략을 Look Aside 방식으로 처리할 경우 명확한 문제 케이스가 생긴다

먼저 Look Aside 방식을 간단히 알아보자

• Cache Aside 패턴이라고도 불리며 데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는지 확인 후 만약 캐시에 데이터가 없다면 DB 에서 데이터를 조회, 이후 캐시를 업데이트하는 전략

fun getUser(id: Long): User {
    var user = cache.get(id);
    if (user == null) {
        user = db.get(id);
        setCache(user);
    }
    return user;
}

문제 상황

• Write DB 1개 / Read DB 2개
• Redis 사용 및 읽기 처리 시 캐시 전략은 Look Aside 전략
• 기존 값인 a 를 abc 로 변경한 경우
  • a → abc
• 대용량 트래픽 환경이며 피크 시간으로 가정

• Write 요청이 발생하면 Write DB 에서 작업 수행 후 Redis 의 기존 값을 삭제(Purge)
• 만약 Write DB 의 변경에 따라 Read DB 가 데이터를 동기화하는 시점에 읽기 요청이 들어올 경우
• 읽기 요청의 캐시 전략은 Look Aside (Cache Aside) 방식을 사용
  • 즉, 읽기 요청은 먼저 Redis 를 통해 데이터 조회 후 없다면 DB 조회, 이후 결과를 다시 Redis 에 적재
• 이 경우 변경된 abc 값을 읽지 못하고 이전 값인 a 를 읽게 된다
• 더불어서 Redis 에서까지 이전 값(a) 으로 적재 된다
• 이를 통해 데이터 불일치 문제가 발생하게 되며 이를 보안하기 위해서는 Write 작업 시 단순히 Redis 의 값을 삭제(Purge) 하지 않고 Update 방식으로 변경하는 것도 고려해볼만하다
• 추가적으로 예상하지 못한 상황에서 Redis 의 데이터 불일치를 방지하기 위해 Redis 를 Purge 하는 기능을 내부에서 사용하기 위해 열어두는 방법도 있다