Redis가 왜 빠른지 두 번 눌러보기

Redis를 처음 배울 때 SET, HSET, LPUSH 같은 명령부터 보면 어렵게 느껴집니다. 하지만 가장 익숙한 쓰임은 간단합니다.

자주 찾는 데이터를 잠시 기억해 두고, 다음 요청에 빠르게 돌려주는 것.

이 데모는 그 한 가지 장점만 보여줍니다.

같은 데이터를 두 번 불러보세요

상품 정보를 처음 요청하면 Redis에는 아직 값이 없습니다.

Redis에서 값을 찾습니다.
값이 없으므로 원본 DB까지 갑니다.
DB에서 받은 상품 정보를 Redis에 잠시 저장합니다.

같은 상품을 다시 요청하면 흐름이 짧아집니다.

Redis에서 저장된 값을 찾습니다.
원본 DB를 다시 읽지 않고 바로 응답합니다.

이를 캐시 적중이라고 합니다. 반복 요청이 많을수록 빠른 응답이 늘고, 원본 DB가 처리해야 하는 읽기도 줄어듭니다.

Redis 자체가 빠른 것과 캐시가 빠른 것은 다릅니다

Redis는 데이터를 주로 메모리에서 다루고, 문자열·해시·리스트 같은 자료 구조를 바로 조작할 수 있어서 빠른 읽기와 쓰기에 유리합니다.

이 데모가 보여주는 것은 그보다 한 단계 더 바깥의 효과입니다. 캐시가 적중하면 원본 DB 조회와 데이터 가공 과정을 건너뛰므로, 사용자에게 응답하기까지의 길도 짧아집니다. 즉 Redis 자체의 빠른 처리와 원본 작업을 생략해서 얻는 시간이 함께 작용합니다.

다만 메모리를 쓴다는 이유만으로 모든 요청이 언제나 빨라지는 것은 아닙니다. 네트워크 거리, 데이터 크기, 사용하는 명령, 저장 설정과 서버 부하에 따라 실제 성능은 달라집니다.

오래된 값은 계속 남겨두지 않습니다

캐시에는 보통 TTL이라는 유효 시간을 둡니다. 시간이 끝나면 값이 자동으로 만료되고, 다음 요청은 다시 DB에서 최신 값을 가져옵니다.

TTL이 짧으면 최신 값에 가깝지만 DB를 더 자주 읽습니다. TTL이 길면 캐시 적중은 늘지만 오래된 값을 잠시 보여줄 수 있습니다. 서비스 성격에 맞게 균형을 정해야 합니다.

값이 바뀌는 순간에도 규칙이 필요합니다. 상품 가격을 DB에서 수정했는데 이전 캐시가 남아 있으면 TTL이 끝날 때까지 오래된 가격을 보여줄 수 있습니다. 흔히 쓰는 선택은 다음 두 가지입니다.

DB 갱신에 성공한 뒤 해당 캐시 키를 지워 다음 읽기가 다시 채우게 합니다.
아주 짧은 지연도 허용할 수 없다면 갱신과 캐시 무효화가 어긋났을 때 복구할 재시도·이벤트 처리를 둡니다.

데모의 DB 가격만 79,000원으로 변경 실험에서는 이 차이를 직접 확인할 수 있습니다. 원본 DB의 가격을 바꿔도 Redis에는 이전 89,000원이 남습니다. 캐시에서 다시 읽으면 응답은 빠르지만 가격은 오래된 상태입니다. 캐시를 지운 다음 요청해야 DB의 새 가격을 읽고 Redis도 다시 채워집니다.

여기서 중요한 점은 빠른 값과 최신 값은 같은 말이 아니라는 것입니다. TTL은 오래된 값이 남는 시간을 제한하는 안전망이고, 캐시 무효화는 데이터가 바뀐 사실을 아는 애플리케이션이 더 일찍 캐시를 비우는 동작입니다.

만료 순간에 요청이 몰리면

인기 상품의 캐시가 끝난 바로 그 순간 요청 1,000개가 들어오면 모두가 동시에 ‘캐시 없음’을 보고 DB로 갈 수 있습니다. 이를 캐시 스탬피드라고 부릅니다. 캐시를 붙였는데 오히려 원본 DB가 순간적으로 더 바빠지는 경우입니다.

한 요청만 DB를 읽어 캐시를 채우고 나머지는 잠시 기다리게 하거나, TTL에 작은 무작위 차이를 두고, 갱신 직전의 값을 짧게 더 제공하는 방법으로 몰림을 줄일 수 있습니다.

데모에서는 실제 부하를 만들지 않고 같은 순간 들어온 요청 10개를 비교합니다. 보호가 없으면 10개 모두 DB를 읽지만, 한 요청만 캐시를 채우게 하면 DB 읽기는 1회이고 나머지 9개는 잠시 기다립니다. 표시되는 숫자는 이 규칙을 설명하기 위한 시뮬레이션이며 실제 서버 측정값은 아닙니다.