본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스물 네번째 날입니다.
스물 세번째 날에는 왜 리플리카가 필요한가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 4. 서비스 부하 분산을 위한 분리 시작 > Ch 2. 성능 개선과 데이터베이스 보호를 위한 레디스 연동 >
01. 왜 캐싱 레이어가 필요한가
입니다.
🛠️ 왜 Redis 캐시 레이어를 도입했는가? – 데이터 일관성과 성능 개선 사이에서
- 이번 포스팅에서는 서비스 부하 분산을 위한 구조 분리 과정 중, 성능 개선과 데이터베이스 보호를 위한 Redis 캐시 레이어 도입 배경과 전략에 대해 정리합니다.
🧩 왜 캐싱 레이어가 필요한가?
- 현재 시스템은 애플리케이션 서버(채팅 서버)에서 MySQL DB에 직접 접근하는 구조입니다. 이 방식은 단순하지만, 모든 읽기/쓰기 요청을 DB가 감당해야 하므로 확장성과 성능 측면에서 한계가 있습니다. 특히, 읽기 트래픽이 많은 상황에서 DB 부하가 급증하고, 이에 따른 비용 증가나 장애 위험도 커집니다.
- 이를 해결하기 위한 일반적인 방법이 바로 캐시 레이어 도입입니다. Redis 같은 인메모리 캐시는 디스크 IO를 사용하는 DB보다 훨씬 빠른 응답을 제공하며, 주로 읽기 요청을 처리함으로써 DB 부하를 크게 줄여줍니다.
🔄 캐시 도입 시 고려할 점: 일관성과 복잡성
- 캐시를 도입한다고 해서 항상 시스템이 더 빨라지고 안정적인 것은 아닙니다. 캐시는 DB와 분리된 구조이기 때문에 데이터 일관성 문제가 발생할 수 있습니다.
- 예를 들어, 사용자 A가 데이터를 업데이트하고, 사용자 B가 거의 동시에 캐시를 통해 데이터를 조회한다면 B는 구 버전의 데이터를 볼 가능성이 있습니다. 이런 불일치를 막기 위해 여러 캐싱 전략이 존재하며, 각 전략은 일관성과 성능 사이에서 트레이드오프가 발생합니다.
💸 주요 캐싱 전략
- Write-Through (쓰기 시 캐시 먼저, DB는 비동기)
캐시에 먼저 쓰고, DB에는 비동기로 쓰는 방식입니다. 빠르지만 DB 반영 실패 시 데이터 유실 위험이 있습니다. - Write-Behind (캐시만 쓰고 주기적으로 DB에 반영)
캐시에만 쓰고, 배치나 이벤트로 주기적으로 DB를 업데이트합니다. 성능은 우수하지만 캐시 장애 시 데이터 손실 가능성이 있습니다. - Cache-Aside (캐시 어사이드)
실무에서 가장 널리 사용되는 방식입니다. 데이터 업데이트 시 캐시를 삭제하고, 다음 조회 요청에서 DB에서 데이터를 가져와 캐시에 저장합니다.
이 방식은 Spring의 @Cacheable / @CacheEvict 어노테이션 패턴과 유사하며, 비교적 단순하면서 가성비가 좋고 일관성도 적절히 보장됩니다. - 단, 이 방식에서도 업데이트 직후 조회 요청이 캐시 만료 직전에 이루어질 경우 구 데이터가 조회될 수 있습니다. 하지만 채팅 서비스 같은 일반적인 웹 서비스에서는 이런 순간적인 불일치는 대부분 비즈니스적으로 허용 가능한 수준입니다.
⚠️ 비용과 구조의 복잡성
- Redis 캐시는 구조적 복잡성과 비용이 추가되지만, 장기적으로 DB 서버 수를 줄일 수 있고, 더 저렴한 비용으로 고성능을 달성할 수 있습니다. 특히 DB가 고가 자원인 경우, 캐시를 도입해 DB 부하를 줄이면 전체 인프라 비용이 감소할 수 있습니다.
- 샤딩이 적용된 구조와 비교할 때도 캐시 도입은 복잡성은 상대적으로 낮으면서도 큰 효과를 얻을 수 있는 방법입니다.
