Cache ? / Cache Invalidation

앞전에 얘기한 LB는 계속적으로 증가하는 서버 수가 있을 때, scale Horizontally 을 잘 할 수 있도록 도와주는 역할을 한다. 그런데, Caching은 너가 이미 갖고 있는 자원 뿐 아니라 달성할 수 없는 요구사항도 달성하게 만들어주는 역할을 할 것이다.. (달성할 수 없는 요구사항도 달성하게 만들어주는건 좀 더 설명하겠다.)

Caching은 자주 접근하는 데이터를 미리 엑세스가 빠른곳에 배치하여, 빠르게 로드하는 스킬이다. 즉, 캐싱은 Locality of reference principle 의 이점을 가진다. 이렇게 되면, 아랫단까지 내려갈 거 없이 앞단에서 데이터를 빠르게 가져와 처리할 수 있다.

• Application Server Cache
  • Request layer 노드 위에 직접 캐시서버를 배치하는 것은 response 데이터의 로컬 스토리지를 가능하게 해준다. 즉, 리퀘스트가 발생할 때마다, 만약 존재한다면, 해당 node는 로컬 캐싱된 데이터를 돌려준다.
• Content Distribution Network(CDN)
  • 주로, 많은 양의 static media 데이터 등을 사이트에 원활히 제공하기 위해 사용되는 캐시의 일종이다. 먼저, CDN 에서 static 미디어 데이터를 찾아 본 후, 없으면 서버로 요청을 보내는 식으로 진행한다.
• Cache Invalidation(캐시 무효화)
  • 캐시 항목이 교체되거나, 제거되는 프로세스를 말한다. 즉, 캐시 데이터를 일관성 있게 유지하기 위한 것이다. 가령 db에서 데이터를 캐싱해뒀는데, db가 수정된다면? 일관성이 깨지게 됨. 따라서, 이런 특성을 고려하여 캐시 무효화 기술을 사용한다. 크게 아래 3가지 Cache Invalidation 로직이 있다.
    • Write-through Cache: data가 db와 캐시에 동시에 write되는 방식임 데이터 손실 등의 리스크는 적으나, write 동작 시 high latency를 발생시키는 단점이 있음
    • Write-around cache: write-through와 유사하나, cache를 bypass하고, permanent 스토리지에 다이렉트로 write한다. 단점으로는 최근에 write한 데이터는 캐시에 없으므로 cache miss를 내고, 백엔드 스토리지에서 데이터를 읽어야만 하므로 higher latency 가 생기는 것이 있다.
    • Write-back cache: data가 캐시에만 write 된다. 스토리지에는 특정한 시간 구간이 지나거나, 특정한 조건 하에 후에 write 된다. Write intensive한 어플에서 low latency, high throughput 효과를 준다. 하지만, 크래쉬가 나거나, 데이터가 cache에만 쓰여 있으므로 갑작스런 이벤트가 일어났을 때 data loss risk 가 있다.
• Cache Eviction Policies(캐시 축출 정책)
  • FIFO
  • LIFO
  • LRU(Least Recently Used)
  • MRU(Most Recently Used)
  • LFU(Least Frequently Used)
  • RR(Random Replacement)