Cache-Aside (Lazy Loading) 패턴

이름 그대로 캐시를 옆에 두고 필요할 때만(Lazy) 사용하는 방식이다. 애플리케이션이 데이터 저장소(DB)와 캐시(Redis) 사이에서 중재자 역할을 직접 수행한다.

1. 기본 동작 흐름

데이터를 조회할 때의 프로세스는 다음과 같다.

1. Cache hit (성공): 애플리케이션이 Redis에서 데이터를 먼저 찾고, 데이터가 있으면 즉시 반환한다.
2. Cache Miss (실패): Redis에 데이터가 없으면, 애플리케이션이 직접 DB에서 데이터를 조회한다.
3. Cache Write: DB에서 가져온 데이터를 Redis에 저장한 뒤 사용자에게 응답한다.

2. Spring Boot 코드 예시

Spring Boot에서는 @Cacheable 어노테이션 하나로 이 복잡한 로직을 자동화할 수 있다.

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    // value: 캐시 이름, key: Redis에 저장될 키 값
    // unless: 결과가 null인 경우 캐싱하지 않음
    @Cacheable(value = "users", key = "#id", unless = "#result == null")
    public User getUserById(Long id) {
        // Redis에 데이터가 없으면 아래 로직(DB 조회)이 실행됨
        System.out.println("Cache Miss! DB에서 데이터를 가져옵니다: " + id);
        return userRepository.findById(id).orElse(null);
    }
}

3. 캐싱의 장점과 단점

장점	내용
장점: 가용성	Redis 서버가 잠시 다운되어도 애플리케이션은 DB를 통해 서비스를 계속 유지할 수 있습니다.
장점: 효율성	실제로 요청된 데이터만 캐시에 올라가므로 메모리를 낭비하지 않습니다.

단점	내용
첫 로딩	데이터가 처음 호출될 때는 무조건 Cache Miss가 발생하므로 첫 응답 속도는 느립니다.
정합성	DB 데이터가 바뀌어도 캐시가 자동으로 갱신되지 않아 데이터 불일치가 발생할 수 있습니다.

4. 이 전략을 쓸 때 알아야 할 2가지

1. TTL (Time To Live) 설정

Cache-Aside 방식은 데이터 정합성 문제를 해결하기 위해 반드시 만료 시간(Expiration)을 설정해야 한다.

만료 시간이 지나면 캐시에서 삭제되므로 그 다음 요청 때 최신 데이터를 DB에서 가져오게 된다.

2. Cache Warming (캐시 워밍)

서비스 오픈 직후나 대규모 이벤트 직전에 트래픽이 몰릴 것이 예상된다면, 이미 자주 찾는 데이터를 캐시에 넣어두는 작업이 필요하다.

이를 하지 않으면 초기에 대향의 Cache Miss가 발생해 DB가 뻗어버릴 수 있다.