캐싱

Sb_chi·2025년 5월 31일
post-thumbnail

🔍 Intro

웹사이트나 애플리케이션을 빠르게 작동시키려면 데이터를 빠르게 불러오는 게 중요하다. 

이때 캐싱이라는 기술이 큰 역할을 한다.

캐싱은 자주 사용하는 데이터를 임시로 저장해두어, 필요할 때 빠르게 꺼내 쓰도록 도와준다.

이번 글에서는 캐싱이 무엇인지, 왜 필요한지에 대해 정리했다.

캐싱

데이터의 복제본 혹은 연산 결과를 임시로 저장해서, 자주 사용되는 복잡한 연산, 자주 찾는 데이터의 결과를 효율적으로 전달하는 것을 목적으로 두는 기술

장점

  1. 요청에 따라 빠르게 데이터 전달

  2. 복잡한 연산 리소스 / 부하를 줄임

단점

  1. 일관성 유지 어려움

  2. 아키텍처의 복잡도 증가 (일관성 유지 위함)

  3. 비용 증가


캐싱을 사용하지 않는 방식

조회 서버에서 데이버베이스에 대한 작업을 한 후 클라이언트에 정보를 넘기는 시스템

📊 매 조회마다 데이터 수집, 데이터 가공, 데이터 통계, 데이터 리턴이라는 순서를 가지고 조회를 해야함


캐시 서버 이용

조회서버에서 한번 조회한 데이터베이스의 기록을 가공 후 저장해놓은 다음, 클라이언트에서 요청이 일어날때 캐시서버에 저장후 다른 곳에서 요청이 일어나면 캐시서버의 내용을 바로 가져다 씀

💡 장점 : 연산의 부하, 요청의 부하, 네트워크 트래픽 해결


캐싱 주요 개념

원본

- 캐싱할 데이터 혹은 연산 결과를 제공하는 주체

Cache Hit

- 요청에 따라 캐시에 저장된 데이터로 응답할 수 있는 상황

- 캐싱에서 지향할 상황이며 원본에 요청 없이 응답 가능

Cache Miss

- 요청에 따른 데이터를 캐시에서 찾을 수 없는 상황

- 별도로 원본에 요청 혹은 다른 방식으로 응답 필요 

캐시 만료

- 캐시를 삭제하는 행위

- TTL : 캐시가 얼마만큼 살아있는지를 나타내는 시간 단위 ( TTL 10초 : 10초 동안 캐시가 살아잇음)

캐싱 방식

개념

캐시에 원본 데이터를 채우는 다양한 정책


1. Lazy Loading

작동 방식

첫요청이 있으면 조회 서버에서 통계를 만들고, 캐시 서버에 가공 후 저장한다.
그 이후 캐시서버에서 가져와서 사용한다.

💾 단점 : 첫번째 요청에서 엄청난 시간이 걸림


2. Eager Loading

작동 방식

 조회 요청이 없어도 미리 데이터를 조회하고,
 
 캐시서버에 저장 후 클라이언트 조회 요청에 캐시 서버 조회     

💾 단점 : 요청이 다양한 기간, 분야 등등 다방면에서 오면 효율적일 수 있으나,

특정 기간에 있는 특정 데이터를 가져오는 작업을 할 때에는 효율적이지 않을 수 있다.


3. Write Through

작동 방식

클라이언트에서 이미지 업데이트나 자료 업데이트할 때,

캐시서버와 저장 서버 동시에 자료를 저장할 때 사용

💾 단점: 데이터의 일관성이 항상 보장되지만 쓰기 과정이 복잡해지고 느려질 수 있음


조회를 하기 위한 아키텍처(Write Back)

작동방식

데이터를 캐시에 먼저 쓰고 후에 원본에 업데이트

💾 단점: 쓰기가 빠르고 간단하지만 원본에 업데이트 전에 유실될 가능성이 있다.


💡 결론

  1. Lazy Loading : 요청이 있을 때만 캐시에 원본데이터를 채움

    • 불필요한 요청이 줄어들지만 최초 데이터 로딩 필요
  1. Eager Loading : 미리 캐시에 데이터를 채워두고 요청을 기다리는 정책

    • 데이터가 항상 준비되어 있지만, 모든 데이터를 채우려면 불필요한 캐시 용량이 낭비되고 처음에 모든 데이터를 채울 때, 매우 큰 리소스가 필요
  1. Write Through : 데이터가 변경되거나 저장되는 시점에 원본과 캐시에 동시에 저장

    • 데이터의 일관성이 항상 보장되지만 쓰기 과정이 복잡해지고 느려질 수 있음
  2. Write Back : 데이터를 캐시에 먼저 쓰고 후에 원본에 업데이트

    • 쓰기가 빠르고 간단하지만 원본에 업데이트 전에 유실될 가능성이 있음

캐시 만료 방식

  1. TTL : 일정 시간이 지나면 만료
  • 항상 일정 시간 후 데이터가 만료되고 갱신할 수 있으나 모든 데이터를 항상 갱신 필요
  1. Least Recently Used : 가장 사용시점이 먼 캐싱 데이터부터 만료
  • 사용이 발생한 데이터들을 계속 보관할 수 있으나 상황에 따라 비효율적일 수 있다.
  1. Least Frequently Used : 가장 덜 사용된 데이터부터 만료
  • 자주 사용된 데이터를 남겨둘 수 있으나 현재 시점에 자주 사용되지 않는 데이터도 같이 남겨둘 수 있다.
  1. First in First Out : 먼저 들어온 데이터부터 만료
  • 간단하지만 패턴을 고려하지 않아 비효율적이다.

캐싱 사용 사례

💻 CDN, ElastiCache,웹 브라우저,RAM,DNS 등 연산이나 기록에 대한 저장을 몇일 동안 캐시에 저장해놓는다. (거의 대부분의 경우 TTL의 방식을 사용)

2개의 댓글

comment-user-thumbnail
2025년 5월 31일

잘 보고 갑니다~

답글 달기
comment-user-thumbnail
2025년 6월 17일

잘 보고 갑니다~

답글 달기