인프런 커뮤니티 질문&답변

soap님, 안녕하세요!

강의에서는 일단 백업 필요성에 대한 관점만 설명드린 것이고, 실제 장애 시 대응 전략은 다양할 수 있습니다.

백업 데이터로 자동으로 전환하고자 하면, 그렇게 처리하셔도 됩니다.

조금 더 개선해보면, 항상 redis를 호출해보는 비용이 생길 수 있으니, redis가 완전하게 복구될 때까지 서킷브레이커 개념을 적용할 수도 있습니다.

또, 자동으로 전환하는 것은 redis의 부하를 mysql로 옮기는 것이다보니, mysql로 장애 전파에 대해서도 우려될 수도 있을 것 같습니다.

충분히 감당할 수 있는 상황인지 모니터링하며 수동으로 전환할 수도 있고, 아니면 redis가 복구될 때까지 조회수 기능은 잠시 꺼두는 것도 방법일 것 같습니다!

안녕하세요, 인프런 AI 인턴입니다. soap님.

조회수 데이터를 Redis에 저장하고, 장애 시에는 MySQL로 백업된 데이터를 사용하여 가용성을 유지하는 전략은 일반적인 캐싱 시스템에서 사용하는 방법입니다. 질문하신 바처럼 Redis가 장애가 났을 때 MySQL의 데이터를 활용하여 조회수를 제공하는 방식은 Redis와 MySQL을 조합한 전형적인 “캐시-백엔드” 패턴입니다.

Redis 장애 시 Fallback을 위한 구현 방법

1. Try-Catch 블록 사용:
   
   • 서비스 레이어에서 count 메서드를 구현할 때, Redis에서 조회를 시도하고 실패할 경우 MySQL에서 데이터를 가져오는 방식으로 작성할 수 있습니다. 이는 Redis의 가용성을 보장하면서도 데이터 일관성을 어느 정도 유지하는 방법입니다.
     

public Long count(Long articleId) {
    try {
        // Redis에서 조회
        return redisTemplate.opsForValue().get...(articleId);
    } catch (RedisException e) {
        // Redis 장애 시 MySQL에서 조회
        return articleViewCountRepository.findById(articleId)
                                         .map(viewCount -> viewCount.getViewCount())
                                         .orElse(0L);
    }
}

이러한 방식으로 Redis에 접근할 수 있는 시도 후, 장애가 발생하면 catch 블록에서 MySQL의 데이터를 사용하게 됩니다. 하지만 이 시나리오에서는 일시적인 Redis 접근 실패일 경우, 무조건 MySQL로 조회하기 때문에 성능적 오버헤드가 있을 수 있습니다. 따라서 장애 상황을 효과적으로 모니터링하고, Redis 문제 해결에 신속히 대응할 수 있는 체계를 마련하는 것도 중요합니다.

참고 자료

추가적인 전략이나 구현 예제를 참조하시려면 유사한 질문과 답변을 참고하시는 것도 좋습니다:
- 조회수 관리시 Redis와 MySQL 혼합 사용 시 고려사항.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 가능한 답변을 제공합니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드리며, 추가로 궁금한 점이 있으시면 자유롭게 질문해 주세요. 곧 지식공유자께서 직접 답변해 주실 것입니다.