개요
'주니어 백엔드 개발자가 반드시 알아야 할 실무 지식'을 읽고 내용을 정리한 게시글입니다.
내용 설명이 더 필요하다고 생각한 부분은 추가하였습니다.
서버 캐시
응답 시간을 줄이고 처리량을 높이기 위해 DB 서버를 수직 또는 수평 확장할 수 있다.
하지만 DB 서버를 확장하려면 비용이 많이 든다.
DB 서버를 확장하지 않고 응답 시간과 처리량을 개선하기 위해 캐시 사용을 고려할 수 있다.
캐시에 데이터를 저장하면 동일한 데이터를 요청할 때 DB가 아닌 캐시에서 데이터를 읽어와 응답할 수 있다.
일반적으로 캐시에서 데이터를 읽는 속도가 DB보다 빠르기 때문에 자주 조회되는 데이터를 캐시에 보관하여 응답시간을 줄일 수 있다.
캐시에서 데이터를 읽는 속도가 빠른 이유는, 캐시 사용 시 메모리에 데이터를 저장하고, 메모리는 CPU와 직접 연결하고 있어 데이터를 읽는 속도가 빠르기 때문이다.
적중률과 삭제 규칙
캐시가 얼마나 효율적으로 사용되는지는 적중률로 판단한다.
적중률 = 캐시에 존재한 건수/ 캐시에서 조회를 시도한 건수
예를 들어, 캐시에서 데이터를 100번 조회했는데 그중 85번은 해당 데이터가 캐시에 존재했다면 적중률은 85%가 된다.
적중률이 높을수록 DB와의 연동이 줄어들어 응답시간 감소, 처리량 증가, DB 부하 감소로 이어진다.
적중률을 높이기 위해서는 캐시에 최대한 많은 데이터를 저장하면 된다.
총 5,000개의 상품이 존재할 때, 캐시에 100개의 상품 정보를 저장하는 것보다 4,500개를 저장하면 적중률이 높아진다.
하지만 모든 데이터를 저장할 수는 없다. 캐시는 메모리 자원을 사용하고, 메모리 용량에는 한계가 있다.
캐시가 가득 찬 경우, 새로운 데이터를 캐시에 저장하려면 기존에 있던 데이터 중 하나를 제거해야 한다.
삭제할 대상을 선택할 때 주로 사용하는 알고리즘은 다음과 같다.
- LRU(Least Recently Used) : 가장 오래전에 사용된 데이터를 제거
- LFU (Least Frequently Used) : 가장 적게 사용된 데이터를 제거
- FIFO (First In First Out): 먼저 추가된 데이터를 먼저 제거
오래된 데이터는 캐시에 있어도 사용되지 않을 가능성이 크다.
따라서 캐시가 가득 차 있지 않더라도 오래된 데이터는 미리 삭제하는 것이 좋다.
이렇게 하면 불필요한 메모리 사용을 줄일 수 있다. 이를 위해 캐시 사용 시 유효 시간을 설정하는 방식을 함께 사용하기도 한다.
로컬 캐시와 리모트 캐시
로컬 캐시는 서버 프로세스와 동일한 메모리를 캐시 저장소로 사용한다.
리모트 캐시는 별도 프로세스를 캐시 저장소로 사용한다.
로컬 캐시는 인-메모리 캐시라고도 불린다. 하지만 리모트 캐시로 많이 사용되는 레디스를 인-메모리 데이터 저장소라고 부르기도 한다.
로컬 캐시 구현 기술로는 Caffeine, go-cache, node-cache 등이 있다.
로컬 캐시와 리모트 캐시의 장단점을 비교해 본다. 둘은 상반된 장단점을 갖고 있다.
로컬 캐시의 장점
- 속도
- 서버 프로세스와 캐시가 동일한 메모리 공간을 사용하므로 캐시 데이터에 빠르게 접근할 수 있다.
- 구조
- 별도의 외부 연동이 필요하지 않아 구조를 단순하게 유지할 수 있다.
로컬 캐시의 단점
- 크기
- 캐시에 저장할 수 있는 데이터 크기에 제한이 있다.
- 휘발성
- 서버 프로세스를 재시작하면 메모리에 존재하던 캐시 데이터가 모두 삭제되어 일시적으로 적중률이 떨어질 수도 있다.
리모트 캐시 장점
- 크기
- 캐시 크기를 유연하게 확장할 수 있다.
- 레디스의 경우 여러 대의 레디스 서버를 이용해 수평 확장할 수 있다.
- 휘발성
- 서버 프로세스가 재시작되더라도 레디스에 저장된 캐시 데이터는 그대로 유지된다.
리모트 캐시 단점
- 속도
- 서버 프로세스는 캐시 프로세스와 데이터를 주고받기 위해 네트워크 통신을 하기 때문에 속도가 비교적 느릴 수 있다.
- 구조
- 별도의 서버 장비와 프로세스가 필요하다.
두 방식은 각각 장단점이 뚜렷하여 상황이나 용도에 맞게 선택해야 한다.
데이터 규모, 변경 빈도, 응답 시간, 처리량을 판단 기준으로 삼아 결정해야 한다.
데이터 규모가 크거나, 배포 빈도가 높아 서버 재시작이 빈번한 경우에는 리모트 캐시를 사용하는 것이 적절해 보인다.
캐시 사전 적재
트래픽이 순간적으로 급증하는 패턴을 보이면 캐시에 데이터를 미리 저장하는 것을 고려할 수 있다.
예를 들어, 한 앱 서비스에서 특정 시간에 전체 회원을 대상으로 푸시 알람을 발송한다고 가정해 보자.
푸시 알람을 받은 사용자가 한 번에 서비스에 접속하면 캐시 적중률은 0%에 근접한다.
캐시 적중률이 느려지면, DB에 전달되는 부하가 증가되고 전체 응답 시간이 느려진다.
이러한 상황을 방지하기 위해, 푸시 알림을 보내기 전 사용자의 요금 정보를 캐시에 미리 저장해 둘 수 있다.
캐시 무효화
캐시를 사용할 때 신경 써야 할 점은 유효하지 않은 데이터를 적절한 시점에 삭제하는 것이다.
캐시에 보관된 데이터의 원본이 바뀌면, 그에 맞춰 캐시에 보관된 데이터도 함께 변경하거나 삭제해야 한다.
데이터가 갱신되지 않으면 사용자는 오래된 정보를 확인하게 되는 문제가 발생할 수 있다.
캐시에 저장된 데이터의 특성에 따라 캐시 무효화 시점을 다르게 설정해야 한다.
민감한 데이터는 변경 즉시 캐시를 무효화 해야 한다.
예를 들어 게시글 내용을 수정했는데, 캐시에 저장된 수정 전 내용을 확인하면 혼란이 발생할 수 있다.
변경에 민감한 데이터는 리모트 캐시에 보관해야 한다. 로컬 캐시는 자신의 데이터만 변경하지, 다른 서버의 로컬 캐시는 변경하지 않는다.
분산 환경에서 A라는 서버에 연결한 사용자는 변경된 가격 정보를 보지만, B 서버에 연결한 사용자는 B 서버의 로컬 캐시에 보관된 변경 전 가격 정보를 보게 되는 문제가 발생할 수 있다.
변경에 민감하지 않고 데이터의 크기가 작다면 캐시에 유효 시간을 설정하여 주기적으로 갱신하도록 할 수 있다.
참고
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 최범균 저
'Teck Stack > Redis' 카테고리의 다른 글
| Refresh Token을 Redis에 저장한 이유 (0) | 2025.11.04 |
|---|---|
| [Redis] 캐싱이란? (Look Aside + Write Around) (1) | 2025.07.14 |