About Cache & TTL (Time To Live)

먼저 TTL (Time To Live) 의 개념을 정리해보자.

한국말로 "살아 있을 시간" 으로 해석할 수 있다. 무엇이 살아 있을 시간일까? 주로 TTL 은 Cache 개념과 묶여서 설명할 수 있다. 따라서 Cache 이야기를 먼저해보자.

Client Server topology 에서 예를 들자면, Client 가 특정 자원을 Server 에 요청을 할 것이다. Server 는 해당 Client 의 요청에 대해서 응답하기 위해서 Server Side Resource (CPU, Memory etc.) 를 사용할 것이다. 하지만 Client 의 요청이 많아질수록 이는 Server 의 부담이 된다. 만약에 동일한 응답을 Client에게 반환할 경우에 이전의 응답한 결과를 다시 사용할 수 있다면 자원 활용도를 높일 수 있다. 하지만 이전의 응답한 결과에 변경이 발생한다면 Server 는 올바르지 않은 응답을 하게 된다. 

이와 같은 현상을 해결하기 위해서는 변경되지 않을 자원만 Cache 를 적용 하거나, 변경되는 자원을 Cache 와 Sync 를 할 수 있는 전략들이 필요하다.

Cache 전략은 여러가지가 있고 제공하고자 하는 데이터에 따라 그리고 아키텍쳐에 따라 여러가지 적용 기법이 있겠지만 몇 가지만 들어보겠다. 처한 상황에 따라서 어느 한 가지만 사용할 수도 있고, 여러 전략들을 동시에 취합해서 사용해야 하기도 한다.

Lazy Loading / Cache-Aside

이름에서 추측할 수 있듯이, 필요할 때 데이터를 Cache 에 로드하는 전략이다. 

Cache Hit

예를 들어, Client 가 Server 에 요청을 한다. 제일 먼저 Cache 저장소에 Cache 데이터가 있는지 확인한다. Cache 저장소에 Cache 데이터가 있고, 해당 Cache 데이터가 stale 이 아닌 최신 상태라면 바로 Client 에 해당 데이터로 응답한다.

Cache Miss

Cache 데이터가 Cache 저장소에 없거나 stale 이라면, 원래의 데이터 저장소에 데이터를 요청하여 해당 데이터로 Client 에게 응답한다. 그 과정에서 해당 데이터를 Cache 저장소에 쓴다. 동일한 다음 요청에는 Cache 저장소에서 해당 데이터를 빠르게 반환할 수 있다.

장점

  • 한 번이라도 요청된 데이터만 Cache 저장소에 저장한다.
  • Cache 저장소의 장애가 Server 전체 시스템에 치명적인 영향을 주지 않는다. 다시 말해 단일장애지점이 되지 않는다. 

단점

  • Cache Miss 가 많을 수록 조회 3 network round trip 으로 latency 가 증가하게 된다. 
  • Cache Miss 에만 Cache 저장소에 저장하기 때문에 stale data 가 존재하게 된다. 기존 데이터가 변경 되었을 때 Cache 저장소에 저장된 데이터가 변경되지 않는 이슈를 해결할 TTL 와 같은 추가적인 정책이 필요하다.

Read-Through

Cache-Aside Strategy 와 유사하게 필요할 때 Cache data 를 로드한다. 하지만 차이점이 있다. 조회 작업은 Cache Provider 를 통해서만 일어난다. 이러한 차이점을 제외하고는 장단점은 Cash-Aside 와 동일하다.




Write-Through

쓰기 작업이 Cache Provider 를 통해서 일어난다. 따라서 application 은 본래의 저장소를 알지 못한다. 일반적인 상황에서 모든 데이터가 본래의 저장소와 Cache 저장소가 동기화 되므로 stale data 가 없다.

장점

  • Cache 데이터가 stale 되지 않는다. 본래의 저장소의 읽기 및 쓰기 작업이 있을 때마다 같이 최신으로 업데이트 되기때문이다.

단점

  • 장애 또는 scale out 을 통해서 새로운 Cache 노드가 추가된다면 본래의 저장소에 쓰기 작업이 일어날 때까지 Cache Miss 가 계속 일어난다. 따라서 Read-Through 전략을 병행한다면 해당 문제를 최소화할 수 있다.
  • Pareto principle 은 소프트웨어 개발에서도 적용된다. 대부분의 데이터는 조회되지 않는다. 일부의 데이터만 많은 요청이 있다. 따라서 Cache 저장소에 모든 데이터가 관리되는 것은 낭비이다. Cache 데이터에 TTL 을 설정하여 낭비되는 공간을 최소화할 방법을 고려하는것이 좋다.



추가적으로, Refresh-Ahead, Write-Behind, Write-Around 와 같은 전략들이 있다.

이제는 TTL 이야기를 해보자. Write Through Cache Strategy 를 사용할 때 유독 TTL 의 중요성이 부각된다. 왜냐면 쓰기작업이 있을 경우 모든 데이터는 Cache 저장소와 본래의 저장소에 모두 저장되기 때문이다. 조회작업이 적거나 없는 데이터의 경우 Cache 저장소의 공간이 낭비된다. Cache-Aside Cache Strategy 도 마찬가지이다. TTL 을 설정하여 Stale data 의 이슈를 어느정도 완화할 수 있다.

 처음에 "살아 있을 시간" 이라고 잠깐 언급했다. Cache 이야기를 해보니, Cache 데이터가 Cache 저장소에 "살아 있을 시간" 으로 이해하면 될 것같다.

결국 Cache System 을 구축하는 과정에서 Stale data 관리와 Cache 저장소의 공간관리를 위해서 TTL 은 중요한 역할을 한다고 볼 수 있다.


구체적인 사례를 확인해보자. 

DNS

평상시에 우리는 크롬, 사파리 같은 브라우저를 통해서 웹 서비스를 이용한다. 주소창에 naver.com, google.com 을 입력한다. 이때 client Device 는 DNS resolution 작업을 통해서 해당 도메인이 가리키는 IP Address 를 알아내야 된다. DNS recursive resolution 기법을 사용하게 된다. DNS root 서버는 IP Address 를 설정된 TTL 값의 기간동안 Caching 한다. 예를 들어 AWS Route 53 의 경우 TTL 60 ~ 172,800 초 즉 1분에서 2일 까지 설정할 수 있다.

CDN

또한 CDN(Content Delivery | Distribution Network) 기술에도 TTL 을 설정할 수 있다. CDN 이란 지리적으로 분산된 Proxy Server 들이 이루고 있는 Network 이다. 본래의 Origin Server 의 Contents 를 Proxy Server 가 Caching 하여 latency 를 줄인다. 우리가 인터넷 기사를 볼 때, 넷플릭스로 영상을 볼 때 혹은 무엇인가 다운로드 받을 때 등등 실생활에 매우 접목되어 있다. TTL 을 어떻게 설정할 것인가는 제공하고자 하는 자원에 따라 다를 수 있다.


참조 

https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside

https://docs.oracle.com/cd/E15357_01/coh.360/e15723/cache_rtwtwbra.htm#COHDG197

https://www.baeldung.com/cs/cache-write-policy

https://medium.datadriveninvestor.com/all-things-caching-use-cases-benefits-strategies-choosing-a-caching-technology-exploring-fa6c1f2e93aa

댓글

이 블로그의 인기 게시물

About JVM Warm up

About idempotent

About Kafka Basic

About ZGC

sneak peek jitpack

Spring Boot Actuator readiness, liveness probes on k8s

About Websocket minimize data size and data transfer cost on cloud

About G1 GC

대학생 코딩 과제 대행 java, python, oracle 네 번째