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