스타트업이 처음 런칭했을 때는 유저가 적어 데이터베이스(RDB) 하나만으로도 충분히 서비스가 잘 돌아갑니다. 하지만 마케팅이 대박 나서 '초당 1만 건'의 요청이 쏟아지기 시작하면 상황은 달라집니다. 여러분이 앞선 12단계에서 HikariCP 커넥션 풀을 아무리 완벽하게 튜닝해 놓았더라도, 물리적인 디스크(Disk)를 긁어서 데이터를 읽어오는 관계형 데이터베이스(MySQL, Oracle)는 태생적으로 속도의 한계가 있습니다. 특히 '쇼핑몰 메인 페이지의 배너 이미지 목록'이나 '오늘의 인기 검색어'처럼 수많은 유저가 똑같이 조회하지만, 데이터는 하루에 한두 번만 변하는 정보를 매번 느린 디스크 DB까지 내려가서 읽어오는 것은 엄청난 리소스 낭비입니다. 이를 해결하기 위해 백엔드 진영이 도입한 궁극의 마법, "디스크가 아니라 초고속 메모리(RAM)에 데이터를 띄워두고 바로바로 던져주자!"는 철학이 바로 캐싱(Caching) 아키텍처이며, 그 중심에 서 있는 1인자가 바로 Redis(레디스)입니다.
이번 [Spring Boot 실무 완벽 가이드] 시리즈에서는 "대용량 트래픽 서버를 살려내는 만병통치약!" Spring Boot 캐싱 전략과 Redis 연동 실무에 대하여 다뤄보겠습니다.
⚡ 1. 메모리와 디스크의 압도적인 속도 차이
컴퓨터 공학의 진리 중 하나는 "메모리(RAM)는 디스크(SSD/HDD)보다 수만 배 빠르다"는 것입니다. 일반적인 MySQL 데이터베이스는 데이터를 영구적으로 보존하기 위해 하드디스크에 기록합니다. 반면 Redis(Remote Dictionary Server)는 Key-Value 구조의 데이터를 영구 보존이 아닌 '초고속 입출력'을 목적으로 메모리 위에 띄워놓는 In-Memory 데이터 스토어입니다. 속도가 워낙 빠르기 때문에 트래픽이 몰리는 병목 지점에 캐시 층(Layer)으로 끼워 넣으면 응답 속도가 문자 그대로 10배 이상 비약적으로 상승합니다.
🗂️ 2. Spring Boot의 우아한 캐시 추상화 (@Cacheable)
과거에는 캐시를 쓰려면 비즈니스 로직 사이에 if (redis.get("key") == null) { DB조회... } 같은 지저분한 코드를 덕지덕지 발라야 했습니다. 하지만 스프링 부트는 AOP(관점 지향 프로그래밍)를 활용하여, 비즈니스 로직을 전혀 건드리지 않고 어노테이션 단 하나로 캐싱을 적용하는 경이로운 추상화를 제공합니다.
[설정 1: 의존성 주입 및 활성화]
// build.gradle에 Redis 의존성 추가
implementation 'org.springframework.boot:spring-boot-starter-data-redis'@EnableCaching // 🌟 Application 클래스나 설정 클래스에 이 한 줄을 달면 마법이 시작됩니다.
@SpringBootApplication
public class DemoApplication { ... }[설정 2: 서비스 코드에 어노테이션 적용]
@Service
@RequiredArgsConstructor
public class NoticeService {
private final NoticeRepository noticeRepository;
// 🌟 이 메서드가 호출될 때, 스프링이 가로채서 Redis에 'noticeList'라는 키(Key)가 있는지 뒤집니다.
// 캐시에 데이터가 있으면(Cache Hit) DB 조회를 건너뛰고 바로 반환합니다!
// 캐시에 데이터가 없으면(Cache Miss) DB에서 꺼내와서 반환함과 동시에 Redis에 예쁘게 저장해 줍니다!
@Cacheable(cacheNames = "noticeList")
public List<NoticeResponse> getTopNotices() {
// 이 코드는 캐시가 비어있을 때만 실행됩니다.
return noticeRepository.findTop10ByOrderByCreatedAtDesc();
}
// 관리자가 공지사항을 수정하면 어떻게 할까요? 기존 캐시를 날려버려야 합니다(Cache Eviction).
@CacheEvict(cacheNames = "noticeList", allEntries = true)
public void updateNotice(Long id, NoticeRequest request) {
noticeRepository.save(newNotice); // DB 수정 후 'noticeList' 캐시를 깔끔하게 날려버립니다.
}
}💀 3. 캐싱 도입 시 주의할 실무 장애 포인트 (캐시 스탬피드)
캐시를 붙였다고 무조건 안심하면 안 됩니다. 실무에서 가장 자주 터지는 대형 장애가 바로 Cache Stampede(캐시 스탬피드, 캐시 붕괴) 현상입니다.
새벽 3시에 Redis에 저장해 둔 '메인 배너 캐시'의 수명(TTL)이 다해서 펑 하고 만료(Expired)되었다고 칩시다. 하필 그 순간 10,000명의 유저가 동시에 메인 페이지를 새로고침했습니다. 10,000개의 쓰레드가 Redis를 찔렀는데 데이터가 없으니까(Cache Miss), 10,000명이 동시에 똑같은 쿼리를 들고 DB로 달려가버립니다. 평소 캐시가 막아주던 부하가 한순간에 DB로 쏟아지며 서버가 완전히 뻗어버리는 대참사입니다.
해결책: 스프링 캐시 추상화의 @Cacheable(sync = true) 옵션을 주면 됩니다. 10,000명이 몰려와도 단 1개의 쓰레드만 락(Lock)을 쥐고 DB에 다녀오게 만들고, 나머지 9,999명은 얌전히 기다렸다가 갱신된 캐시를 받아 가도록 통제하여 DB 폭파를 완벽히 막아낼 수 있습니다.
🎯 4. 마무리 및 다음 단계
지금까지 느린 디스크(DB)의 병목을 초고속 메모리 스토어로 대체하여 응답 속도를 비약적으로 상승시키고, 어노테이션 기반의 우아한 AOP 캐싱 적용법과 끔찍한 캐시 붕괴(Stampede)를 막는 sync=true 실무 노하우까지 다루어 보았습니다. 이제 여러분의 서버는 어떠한 트래픽 폭풍이 몰아쳐도 끄떡없을 것입니다.
서버 성능 튜닝의 양대 산맥(커넥션 풀, 캐싱)을 모두 정복했습니다. 이제 기능도 완벽하고 성능도 훌륭합니다. 그런데, 누군가 아무나 회원 정보를 삭제하는 API를 마구 호출한다면 어떻게 될까요? 지금까지 우리는 문을 활짝 열어놓고 장사를 하고 있었습니다. 이제 애플리케이션의 '보안(Security)'이라는 거대하고 무거운 철문을 달아줄 시간입니다. 이어지는 14단계 포스팅에서는 "전 세계에서 가장 강력하지만 악명 높게 복잡한 보안 프레임워크!" Spring Security의 아키텍처와 핵심 원리, 그리고 폼 로그인(Form Login) 기반의 인증 체계에 대해 아주 뼈 때리게 파헤쳐 보겠습니다!
