캐싱

캐싱 ?

자주 사용되는 데이터를 더 빠른 임시 저장소에 보관하고, 반복적인 데이터 접근 시 성능을 향상시키는 기술입니다.

캐싱의 장점

1. 비용 절감
   DB에서 실행되는 복잡한 쿼리나 대량 데이터 처리는 많은 리소스를 소모하는 작업입니다.

   캐싱을 활용하면 이러한 작업의 실행 횟수를 줄일 수 있어 DB 리소스를 절감할 수 있습니다.

   특히 클라우드 환경에서는 DB의 부하 감소가 곧 비용 절감 효과까지 이어질 수 있습니다.

2. 성능 향상

   메모리 기반 캐시 시스템은 디스크 기반 DB보다 훨씬 빠른 속도로 데이터를 조회할 수 있습니다.

   따라서 캐싱을 적용하면 API 응답 속도가 큰 폭으로 개선되며, 동일한 서버에서도 더 많은 요청을 처리할 수 있게 됩니다.

3. 안정성 확보

   캐싱은 단순한 성능 향상을 넘어 시스템 안정성에도 기여합니다.

   트래픽이 급증하는 상황에서도 캐싱을 적절히 활용하면, DB 부하를 분산할 수 있습니다.

   이를 통해 핵심 서비스가 지연되거나 장애가 발생하는 상황을 방지할 수 있습니다.

   즉, 캐싱을 잘 활용하면 핵심 기능이 보다 안정적으로 제공되며, 서비스 중단 없이 일관된 성능을 유지할 수 있습니다.

캐싱의 기준

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

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

어떤 데이터들이 캐싱에 적합한지 알아보자

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

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

   시간적 지역성이 나타나는 데이터를 캐싱 대상으로 삼는 대표적인 예시라고 볼 수 있습니다.

   비유를 들자면 네이버 뉴스의 메인 페이지라고 보면 좋을 것 같습니다

   • 많은 사용자가 짧은 시간 안에 반복적으로 접근하므로 시간적 지역성이 높습니다.
   • 뉴스 헤드라인은 보통 10분 ~ 30분 간격으로 갱신되므로 자주 변경되지는 않습니다.
   • 따라서 일정 주기마다 캐시를 갱신하면서도 높은 캐시 효율을 기대할 수 있습니다.

   하지만 이 때, 해당 데이터의 변경 빈도 역시 함께 고려해야 합니다.

   왜냐하면 자주 접근되더라도 변경이 너무 잦다면, 캐시 히트율이 떨어지고 오히려 리소스를 낭비하게 될 수 있기 때문입니다. ex) 주식 시세

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

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

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

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

   비유를 들자면 관리자용 통계 대시보드라고 할 수 있습니다.

   • 페이지 진입 빈도는 낮지만, 매 진입 시 복잡한 집계 쿼리를 실행해야 하는 경우가 많습니다.
   • 매번 계산하지 않고, 일정 주기로 캐시된 데이터를 보여주도록 하면 효율적입니다.

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

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

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

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

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

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

   비유를 들자면 상품 상세 정보 + 관련 태그 / 옵션 라고 할 수 있습니다.

   사용자가 상품 상세 페이지를 열람할 때, 단순히 상품명과 가격만 보는 것이 아니라 다음과 같은 정보들도 함께 확인하는 경우가 많습니다.

   이처럼 상품 정보와 관련된 부가 정보는 함께 조회되는 빈도가 높기 때문에, 상품 ID를 키로 하여 관련 데이터를 하나의 캐시 객체로 묶어 저장하면 다음과 같은 이점이 있습니다

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

   하지만 만약 해당 상품이 옵션이 없는 단일 상품이거나, 태그를 활용한 마케팅 요소가 거의 없다면 모든 상품에 대해 옵션이나 태그를 일괄 캐싱하는 것은 낭비가 될 수 있습니다.

   따라서 실제 사용자 행동 패턴에 따라 공간적 지역성이 있는지 분석하고, 함께 조회되는 데이터의 비율이 충분히 높을 때에만 묶어서 캐싱하는 것이 좋습니다.

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

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

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

   비유를 들자면 공휴일 정보라고 생각할 수 있습니다.

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

   예를 들어

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

   이처럼 다양한 기능과 서비스에서 동일한 데이터가 반복적으로 활용되기 때문에, 공휴일 목록을 하나의 캐시로 관리하면, 모든 요청에 대해 동일한 데이터를 재사용할 수 있어 효율적입니다.

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

1. 이 데이터는 얼마나 자주 접근되나요? (시간적 지역성)
   a. 그리고 얼마나 자주 변경되나요? (변경 빈도)
2. 이 데이터를 생성하거나 조회하는 비용이 얼마나 높나요? (계산 비용)
3. 이 데이터와 함께 접근되는 연관 데이터가 있나요? (공간적 지역성)
4. 이 데이터는 얼마나 많은 사용자나 요청에서 공유되나요? (공유 가능성)