[부하를 견디는 서버의 비밀, Redis] 캐싱(Caching)의 개념 1,2

이 글은 인프런 딩코딩코의 백엔드 이력서 차별화 전략 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.

6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법 강의 | 딩코딩코

---

이번 챕터에서는 캐싱의 개념과 로컬 캐싱, Redis를 활용한 분산 캐싱을 다루고, 실문에서 캐싱을 적용하면서 발생할 수 있는 문제점들을 살펴보고, 문제를 해결하는 방법들을 배워볼 수 있다.

또한 대규모 트래픽 환경에서 캐시 시스템을 안정적으로 운영하기 위한 모니터링 방법과 성능 측정 기법도 함께 학습해볼 수 있다.

 

1. 캐싱(Caching)의 개념 1

캐싱이란?

보통 자주 방문하는 웹사이트들을 브라우저의 즐겨찾기나 북마크에 저장한다.

그리고 매번 주소를 입력하거나 검색하는 대신, 북마크에서 찾아 빠르게 접속한다.

 

이처럼 자주 사용하는 정보를 쉽게 접근할 수 있는 곳에 미리 저장해두고, 필요할 때 빠르게 접근하는 행동이 바로 캐싱의 개념과 동일하다.

즉, 자주 사용하는 정보를 쉽게 접근할 수 있는 곳에 미리 저장해두고 필요할 때 빠르게 접급하는 행동이 캐싱이다.

 

캐싱은 자주 사용되는 데이터(ex. DB의 유저 정보)를 더 빠른 임시 저장소에 보관하고, 반복적인 데이터 접근 시 성능을 향상시키는 기술이다.

캐싱을 통해서 매번 원본 데이터를 가져오는 시간과 비용을 절약하고, 중복 연산 수행을 방지하여 서버의 성능을 향상 시킬 수 있다.

 

캐싱이 적용된 조회연산

1. 먼저, 캐시에서 데이터를 조회하려고 시도한다.

2. 캐시에 데이터가 존재하면 즉시 반환한다.

3. 캐시에 데이터가 없으면, 원본 데이터(DB)에서 조회하여 반환한다.

 

즉, 데이터를 요청할 때 먼저 캐시 저장소를 확인하고, 캐시에 데이터가 있으면 바로 반환하며, 없으면 원본 데이터에서 가져오는 방식으로 동작한다.

 

데이터 지역성

성능과 용량의 한계를 극복하면서도 효과적으로 캐싱을 적용하는 방법은 무엇일까?

효율적인 캐싱 전략을 수립하는 데 중요한 개념인 데이터 지역성이 있다.

---

2. 캐싱(Caching)의 개념 2

백엔드 서버에서의 캐싱을 도입하는 이유

백엔드 서버가 유저 요청을 처리하는 과정에서 대부분의 데이터는 DB에서 조회된다.

DB는 대량의 데이터를 안전하게 보관하고 관리할 수 있는 핵심 저장소이다.

❗️ 하지만 DB는 디스크 기반 저장소이기 때문에 접근 속도가 상대적으로 느리다.

특히 복잡한 쿼리나 조인 연산이 포함된 경우에는 처리 시간이 더 길어질 수 있다.

 

실제 서비스 환경에서는 동시에 수많은 사용자가 서버에 요청을 보낸다.

이로 인해 DB에 대한 접근이 집중되고, 처리해야 할 요청의 양이 폭발적으로 증가할 수 있다.

또한, 서비스 트래픽이 증가할수록 DB의 부하도 함께 증가하게 된다.

DB가 부하가 심화되면, 전체 시스템이 병목 현상을 겪으며 성능이 저하되고, 심한 경우에는 핵심 서비스 장애로 이어질 수도 있다.

 

이러한 문제를 해결하기 위해 백엔드 서버에서는 캐싱을 도입한다.

즉, 자주 요청되는 DB의 데이터를 메모리 기반의 캐시 시스템에 저장하며 매번 DB에서 조회하는 대신 빠르게 응답할 수 있도록 한다.

✅ 백엔드 서버에서의 캐싱을 도입했을 때 얻을 수 있는 구체적인 이점

1. 비용 절감
   DB에서 실행되는 복잡한 쿼리나 대량 데이터 처리는 많은 리소스를 소모하는 작업이다.
   캐싱을 활용하면 이러한 작업의 실행 횟수를 줄일 수 있어 DB 리소스를 절감할 수 있다.
   특히 클라우드 환경에서는 DB의 부하 감소가 곧 비용 절감 효과까지 이어질 수 있다.
   
   
2. 성능 향상
   메모리 기반 캐시 시스템은 디스크 기반 DB보다 훨씬 빠른 속도로 데이터를 조회할 수 있다.
   따라서 캐싱을 적용하면 API 응답 속도가 큰 폭으로 개선되며, 동일한 서버에서도 더 많은 요청을 처리할 수 있게 된다.
   
   
3. 안정성 확보
   캐싱은 단순한 성능 향상을 넘어 시스템 안정성에도 기여한다.
   트래픽이 급증하는 상황에서도 캐싱을 적절히 활용하면, DB 부하를 분산할 수 있다.
   이를 통해 핵심 서비스가 지연되거나 장애가 발생하는 상황을 방지할 수 있다.
   즉, 캐싱을 잘 활용하면 핵심 기능이 보다 안정적으로 제공되며, 서비스 중단 없이 일관된 성능을 유지할 수 있다.
   
   

결국 캐싱을 통해 비용 절감, 성능 향상, 안정성 확보 라는 3가지 핵심 이점을 얻을 수 있다.

🤩 궁극적으로, 이러한 캐싱의 모든 이점을 더 나은 유저 경험으로 이어진다.

유저는 더 빠른 응답 속도로 서비스를 이용할 수 있으며, 안정적인 환경에서 끊김 없이 원하는 데이터를 조회할 수 있게 된다.

---

어떤 데이터를 캐싱해야할까?

모든 데이터를 캐싱할 수는 없기 때문에, 어떤 데이터를 캐싱 대상으로 삼을 것인지 전략적으로 결정해야한다.

🤔 실제로 백엔드 서버에서는 어떤 데이터를 캐싱하는 것이 효과적일까?

 

우선, 판단 기준으로 가장 먼저 고려할 수 있는 것은 데이터 지역성 개념이다.

• 시간적 지역성 : 최근 접근한 데이터는 가까운 미래에 다시 접근될 가능성이 높다.
• 공간적 지역성 : 현재 접근한 데이터 주변의 데이터도 곧 접근될 가능성이 높다.

즉, 지역성이 잘 나타나는 데이터는 높은 캐시 히트율을 기대할 수 있기 때문에 캐싱 대상으로 우선 고려할 수 있다.

 

하지만 단순하게 데이터 지역성만으로 캐시 대상을 판단하기에는 한계가 있다.

현실의 서비스에서는 단순히 데이터 접근 패터만으로 판단할 수 없는, 다양한 상황과 제약 조건이 존재하기 때문이다.

 

따라서 캐싱 전략을 결정할 때는 서비스 특성과 운영 환경을 고려한, 아래와 같은 기준을 함께 반영해야한다.

• 데이터 변경 빈도 : 얼마나 데이터가 자주 변경되는지?
• 데이터 생성 비용 : 복잡한 계산을 요구하는지?
• 데이터 공유 가능성 : 다양한 유저, 시스템이 데이터를 공유하는지

위의 요소들을 종합적으로 고려해, 캐싱의 이점이 비용보다 클 때 캐시 대상으로 삼아야한다.

---

실제 백엔드 환경에서 어떤 데이터들이 캐싱에 적합한 지 알아보자.

 

1. 시간적 지역성이 높고 변경이 적은 데이터

가장 기본적인 캐싱 대상은 시간적 지역성이 높고 변경이 적은 데이터이다.

시간적 지역성이 나타내는 데이터를 캐싱 대상으로 삼는 대표적인 예시이다.

 

네이버 뉴스의 메인페이지

 

 

따라서 시간적 지역성이 높고 변경이 적은 데이터는 캐싱 시, 캐시 히트율이 높아 매우 이상적인 캐싱 대상으로 볼 수 있다.

 

2. 지역성은 낮지만 생성 비용이 높은 데이터

통계 및 집계 연산, 복잡한 조건의 sql 쿼리 결과, 외부 api 호출 결과 등은 생성 비용이 높은 데이터이다.

 

하지만 이 데이터들이 상대적으로 접근 빈도가 낮아 캐싱 대상으로 선정되지 못할 수 있다.

이 상황에서 비용이 큰 연산이 여러 번 수행된다면, 전체 시스템 성능 저하를 유발할 수도 있다.

 

관리자용 통계 대시보드 

페이지 진입 빈도는 낮지만, 매 진입 시 복잡한 집계 쿼리를 실행해야 하는 경우가 많다.

매번 계산하지 않고, 일정 주기로 캐시된 데이터를 보여주도록 하면 효율적이다.

 

접근 빈도는 낮지만 생성 비용이 큰 데이터는 캐시의 효율성을 높이는 데 기여할 수 있다.

특히 백오피스, 분석 시스템, 리포트 서비스 등에서 이러한 형태의 캐싱이 자주 활용된다.

시간적 지역성이 부족하더라도, "계산 비용이 크고, 최신 데이터가 아니어도 되는 경우"에는 캐싱을 고려해볼 가치가 있다.

 

✅ 따라서 생성 비용이 높은 데이터는 접근 빈도가 낮아도 캐싱의 이득이 더 크다면, 캐싱을 고려해봐야한다.

(주의 : 접근 빈도가 낮을 뿐이지 단 한 번이라면 캐싱할 필요가 없다!)

 

3. 공간적 지역성이 나타나는 연관 데이터

하나의 데이터를 조회할 때 함께 자주 사용되는 데이터가 있다면, 이들을 묶어서 캐싱하면 효율적이라는 개념이다.

즉, 서로 연관되어 자주 같이 사용되는 데이터는 한 번에 조회하고 캐싱하는 방식으로 성능을 최적화 할 수 있다.

 

ex) 상품 상세 정보 + 관련 태그 / 옵션

사용자가 상품 상세 페이지를 열람할 때,

단순히 상품명과 가격만 보는 것이 아니라 다음과 같은 정보들도 함께 확인하는 경우가 많다.

 

이처럼 상품 정보와 관련된 부가정보는 함께 조회되는 빈도가 높기 때문에,

상품 ID를 키로 하여 관련 데이터를 하나의 캐시 객체로 묶어 저장하면 다음과 같은 이점이 있다.

• 매번 옵션이나 태그 정보를 개별적으로 DB에서 조회하지 않아도 됨
• 화면 진입 시 필요한 모든 데이터를 빠르게 응답 가능
• 전체적인 페이지 로딩 속도 향상

하지만 만약 해당 상품이 옵션이 없는 단일 상품이거나, 태그를 활용한 마케팅 요소가 거의 없다면

모든 상품에 대해 옵션이나 태그를 일괄 캐싱하는 것은 낭비가 될 수 있다.

따라서 실제 사용자 행동 패턴에 따라 공간적 지역성이 있는지 분석하고,

함께 조회되는 데이터의 비율이 충분히 높을 때에만 묶어서 캐싱하는 것이 좋다.

 

✅ 따라서 항상 그런 것은 아니지만, 유저의 요청 패턴이 일정하다면 이런 연관 데이터도 캐싱의 대상으로 고려해 볼 수 있다.

 

4. 공유 가능성이 높은 데이터

특정 사용자에 국한되지 않고, 다수의 사용자나 시스템이 함께 사용하는 데이터를 의미한다.

이러한 데이터는 한 번 캐싱해두면, 모든 사용자 요청에서 재사용 가능하기 때문에 캐시의 효율성이 매우 높은 대상이다.

 

ex) 공휴일 정보

공휴일 정보는 모든 사용자와 시스템이 동일하게 활용할 수 있는 대표적인 공유 데이터이다.

 

예를 들어

• 예약 시스템은 공휴일을 피해서 예약 가능 날짜를 보여준다.
• 배송 시스템은 배송 불가 일정을 계산할 때 사용된다.
• 근무 관리 시스템은 연차 계산 등에 활용된다.

이처럼 다양한 기능과 서비스에서 동일한 데이터가 반복적으로 활용되기 때문에,

공휴일 목록을 하나의 캐시로 관리하면 모든 요청에 대해 동일한 데이터를 재사용할 수 있어 효율적이다.

 

✅ 따라서 공유 가능성이 높은 데이터는 작은 비용으로 큰 효과를 낼 수 있기 때문에 캐싱의 대상으로 고려해볼 수 있다.

---

📝 정리하면, 어떤 데이터를 캐싱 대상으로 선택할 지 결정할 때는 다음 사항들을 바탕으로 각 데이터의 특성을 종합적으로 판단하고, 캐싱의 이점이 유지 비용보다 클 경우에만 캐싱을 적용하는 것이 중요하다.

1. 이 데이터는 얼마나 자주 접근되나요? (시간적 지역성)

    a. 그리고 얼마나 자주 변경되나요? (변경 빈도)

2. 이 데이터를 생성하거나 조회하는 비용이 얼마나 높나요? (계산 비용)

3. 이 데이터와 함께 접근되는 연관 데이터가 있나요? (공간적 지역성)

4. 이 데이터는 얼마나 많은 사용자나 요청에서 공유되나요? (공유 가능성)