캐시를 통한 성능개선 - 이론편

1. 캐시의 기본 개념

캐시(Cache)란?

캐시(Cache)란 일반적으로 자주 사용되는 데이터나 값을 미리 복사해 놓는 임시 저장소를 의미합니다. 컴퓨팅 분야에서는 이러한 캐시를 사용함으로써 데이터에 대한 접근 시간을 단축시키고, 전체적인 처리 성능을 향상시킬 수 있습니다.

다양한 수준에서의 캐시 사용

1. CDN(Content Delivery Network)

CDN은 지리적으로 분산된 서버에 정적 컨텐츠를 캐시하여 클라이언트가 요청했을 때 가까운 서버(Edge Server)를 사용해 컨텐츠를 더 빠르게 전송시키는데 목적을 두고있습니다.

하지만 모든 서버에서 같은 컨텐츠를 갖고 있는것은 아닙니다.(비효율적) 클라이언트가 CDN을 사용해 요청을 보내면 탐색후 캐시에서 발견되지 않으면 원본 서버에서 컨텐츠를 가져옵니다. 이때 컨텐츠가 캐싱되고 컨텐츠는 사용자가 계속 엑세스 하는 한 CDN캐시에 보관됩니다.

이러한 방법으로 더 빠른 데이터를 제공할 수 있습니다.데이터는 물리적으로 서버와 클라이언트 간의 네트워크를 통해 이동해야 하기 때문에, 서버가 사용자에게 더 가까울수록 데이터가 이동해야 하는 거리가 짧아지고 데이터 전송에 걸리는 시간을 줄여줍니다.

1. 데이터베이스 캐시

데이터베이스 캐싱은 데이터베이스에서 읽기 및 쓰기를 최적화 하기위해 사용하는 캐시를 말합니다. 예를 들어 MySQL에서는 쿼리 캐싱을 통해 SQL의 실행 결과를 메모리에 캐시하고 동일한 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환하기 때문에 빠른 성능을 보였습니다.(하지만 상황에 따라 성능 저하를 일으켜 8.0버전부터는 삭제되었습니다.)

1. 브라우저 캐싱

브라우저 캐시는 헤더 정보를 기반으로 캐싱합니다. HTTP 캐시 헤더는 브라우저가 컨텐츠의 대한 캐싱 기간을 지정할 수 있고 브라우저는 불필요한 데이터 호출을 피하기 위해 요청의 대한 응답을 캐시해 사용합니다.

1. 서버 캐싱

서버 캐싱은 Server Application의 동작에서 데이터를 캐싱해 사용하는 메커니즘입니다. 웹 프록시를 사용해 응답을 보관함으로써 해당 서버의 부하를 낮추기도 하고 브라우저와 원본 서버 사이에 중간 역할을 둬 활용하기도 합니다.

또 주로 사용되는 캐시로는 Memcached, Redsi와 데이터베이스를 활용해 레이턴시를 낮추기도 합니다.

캐시를 도입해 성능을 개선할 수 있는 상황

• 원본 데이터 저장소에서 원하는 데이터를 찾기 위해 검색하는 시간이 오래 걸리거나, 매번 계산을 통해 데이터를 가져올 때
• 캐시에서 데이터를 가져오는 것이 원본 저장소 데이터를 요청하는 것보다 빠를 때
• 캐시에 저장된 데이터는 잘 변하지 않는 데이터 일 때
• 캐시에 저장된 데이터가 자주 검색되는 데이터일 때

캐시를 적절하게 배치함으로써 애플리케이션의 성능을 향상 시키고 애플리케이션 뿐만아니라 데이터베이스의 부하를 줄일 수 있습니다.

2. 캐시 구현 전략

읽기 캐시 전략

1. Cache-Aside

캐시-어사이드 패턴은 데이터가 캐시에 있는지 먼저 확인합니다. 캐시에 데이터가 없을 경우, 데이터베이스에서 데이터를 가져와 캐시에 저장한 후 결과를 반환합니다. 데이터가 캐시에 있으면 바로 반환합니다. 이런 구조는 읽기가 빈번하게 일어나는 서비스에 유리하고 캐시 서버가 다운되더라도 데이터베이스와 직접 통신해 정상 작동할 수 있다는 장점이 있습니다

2. Read-Through Cache

Read-Through 캐싱 전략에서는 캐시가 데이터 소스처럼 작동합니다. 애플리케이션이 데이터를 요청하면, 캐시는 먼저 자신의 항목에서 데이터를 찾습니다. 데이터가 캐시에 없으면, 캐시 자체가 데이터베이스에서 데이터를 읽어와 캐시에 저장하고 애플리케이션에 반환합니다. 이후 조회에서는 캐시된 데이터를 사용합니다.

데이터를 자동으로 캐시에 로드하므로 읽기가 많을 때 효과적이지만 캐시 미스가 발생할 경우 요청 처리 시간이 늘어날 수 있습니다.

 

쓰기 캐시 전략

1. Write-Back

데이터를 캐시에 쓰고, 이후에 비동기적으로 백엔드 데이터 저장소에 해당 변경사항을 적용합니다. 이 방법은 쓰기 작업의 지연 시간을 줄이고 애플리케이션의 성능을 향상시킬 수 있지만, 데이터 일관성을 관리하는 것이 더 복잡해질 수 있습니다. 쓰기 작업이 많고, 쓰기 지연 시간이 성능에 민감하게 작용하는 애플리케이션에 적합합니다.

2. Write-Through Cache

새로운 데이터가 먼저 캐시에 저장된 후 데이터베이스에 기록됩니다. Write-Through 캐싱 전략에서는 애플리케이션이 데이터를 캐시에 쓸 때, 캐시와 백엔드 데이터 저장소 모두에 즉시 쓰기 작업이 발생합니다. 이로 인해 캐시와 데이터 저장소 간의 데이터 일관성이 항상 유지됩니다. 캐시에 데이터를 쓴 후에는 캐시된 데이터가 반환되어 사용됩니다.

캐시 무효화 정책 (Cache Eviction Policy)

1. LRU (Least Recently Used):
   • 가장 최근에 접근되지 않은 항목이 캐시에서 가장 먼저 제거됩니다.
   • 실용적이고 많이 사용되는 정책 중 하나입니다.
2. FIFO (First In, First Out):
   • 캐시에 가장 먼저 저장된 데이터를 가장 먼저 제거합니다.
   • 이 방식은 사용 빈도나 시간에 상관없이 순차적으로 데이터를 제거합니다.
3. LFU (Least Frequently Used):
   • 데이터의 사용 빈도를 기반으로 가장 적게 사용된 삭제 대상을 결정합니다.
   • 자주 사용되지 않는 데이터를 효율적으로 제거할 수 있습니다.
4. TTL (Time To Live):
   • 데이터가 캐시에 저장된 후 일정 시간이 지나면 자동으로 제거됩니다.
   • 캐시된 데이터에 유효 시간을 설정하여, 시간이 만료되면 자동으로 삭제됩니다.