Redis 캐싱의 문제 발생 시나리오
- 불필요한 데이터의 캐싱: 예를 들어 Redis에 50GB의 데이터가 저장되어 있는 상황에서, 페이지네이션(paging) 데이터를 캐싱하는 과정에서 불필요한 데이터를 과도하게 캐싱한 경우가 있을 수 있다. 이는 Redis 메모리를 불필요하게 차지하여 효율성을 저하시키고, 결국 Redis 장애로 이어질 수 있다.
- Redis 장애: 불필요한 데이터가 캐시에 쌓이면서 Redis 메모리가 고갈되고, 이로 인해 Redis가 정상적으로 작동하지 못하게 된다. 결과적으로 Redis에 연결하려는 요청들이 타임아웃(timeout)을 유발하게 되며, 시스템 성능에 심각한 영향을 미친다.
문제 발생 시 해결 방법
- 타임아웃 설정: Redis와의 연결 시 타임아웃 설정은 필수적이다. 예를 들어, 타임아웃을 3초나 4초로 설정하여 Redis가 응답하지 않을 경우 애플리케이션이 오랜 시간 대기하지 않도록 한다. 이로 인해 Redis가 장애 상태일 때도 시스템의 응답성이 유지된다.
- 백엔드 데이터베이스로의 폴백(fallback): Redis 장애 시 백엔드 데이터베이스로의 폴백을 고려해야 한다. 그러나 DB로의 요청이 많아지면 시스템 성능이 저하될 수 있으므로, 상황에 따라 클라이언트에게 데이터 제공을 중지하고 서버 에러가 아님을 알려주는 것도 방법이다. 이로 인해 사용자는 서버의 신뢰성을 유지하면서, 장애 상황에서도 시스템을 사용할 수 있다.
예방 및 모니터링 전략
- 데이터 경량화: Redis에 저장되는 데이터를 최소화하고 필요한 데이터만 캐싱하도록 해야 한다. 이는 Redis 메모리 사용을 최적화하고 불필요한 데이터가 쌓이는 것을 방지한다.
- 모니터링 설정: Redis 메모리 사용량을 지속적으로 모니터링하는 것이 중요하다. 예를 들어, Redis 메모리 사용량이 일정 수준(예: 80% 이상)에 도달하면 알림을 보내는 시스템을 구축한다. 이를 통해 Redis 장애를 사전에 감지하고 대응할 수 있다.
- 알람 시스템 도입: Redis 메모리 사용량이 특정 임계치를 넘을 경우 경고 알람을 발송하도록 설정한다. 이를 통해 빠르게 문제를 감지하고 조치를 취할 수 있다.
'Development > TIL' 카테고리의 다른 글
[TIL][Spring] Spring Webflux의 Spring Security (@EnableWebFluxSecurity), ReactiveSecurityContextHolder (2) | 2024.09.11 |
---|---|
[TIL] DTO, Entity에서 Wrapper 클래스를 사용하는 이유 (0) | 2024.08.29 |
[TIL] Kafka와 RabbitMq의 철학, 그리고 어떻게 철학을 달성했을까? (0) | 2024.08.17 |
[TIL] 다시 배우는 Docker (0) | 2024.08.09 |
[TIL] 클라이언트 사이드 로드밸런싱과 서버 사이드 로드밸런싱 (0) | 2024.08.07 |