[Tech] Cache invalidation이란 무엇일까?

오늘 인스타그램의 Scailing 아키텍쳐에 관한 영상을 보았다. 

 

내용이 정말 좋다고 생각했는데 자주 등장하는 용어 중 낯선 용어가 있어 이에 대해 정리해보고자 한다. 

 

Cache invalidation 즉 캐쉬 무효화이다. 

 

찾아보니 꽤나 도움되는 내용이 많은 개념이다. 

---

왜 캐시가 등장했을까? 

기술 발전으로 프로세스 속도는 증가했지만 메모리 속도가 이를 따라가지 못했다. 

프로세서가 아무리 빨라도 메모리 처리 속도가 느리면 결과적으로 전체 시스템 속도가 느려진다. 

이를 개선하기 위해 캐시가 나왔다. 캐시는 CPU 칩 안에 들어가는 작고 빠르고 비싼 메모리다. 

프로세서가 매번 메인 메모리에 접근해서 데이터를 받아오면 시간이 오래 걸려서 자주 사용하는 데이터를 담아두고 해당 데이터가 필요할때 프로세스가 메인 메모리 대신 캐시에 접근해서 처리 속도를 높인다. 

 

캐시란 무엇일까?

캐시는 기본적으로 속도를 빠르게 하기 위해 쓰인다. 

메모리 속도는 기본적으로 HDD/SSD보다 빠르다. 하지만 캐시는 기본적으로 데이터 복사본을 사용하는 개념이기 때문에 consistency 문제가 발생할 수 있다. 

캐시 메모리는 메인 메모리와 CPU 간 데이터 속도 향상을 위한 중간 버퍼 역할을 하는 CPU 내 또는 외에 존재하는 메모리다. 

실제 메모리와 CPU 사이에서 빠르게 전달하기 위해서 미리 데이터를 저장해두는 개념으로 전체 시스템 성능 개션을 위해 존재한다. 

자주 사용하는 데이터나 값을 미리 복사해놓는 개념이다. 

캐시 메모리는 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다. 

 

원본 데이터를 가져오는 시간이 오래 걸리는 경우 혹은 반복적으로 동일한 결과를 돌려주는 경우 캐시를 사용하면 좋다. 

캐시는 지속적으로 DBMS 혹은 서버에 요청하는 것이 아니라 메모리에 데이터를 저장했다가 불러 쓰는 개념이다. 

원하는 데이터가 캐시에 존재하는 것을 Cache hit, 반대를 Cache Miss라고 하며 이때는 DBMS, 서버에 요청해서 가져와야 한다. 

캐시가 효율적으로 동작하려면 캐시에 저장할 데이터가 지역성을 가져야한다. 

시간적 지역성과 공간적 지역성이 존재한다. 

 

캐시의 평균 접근 시간은 어떻게 구할까? 

Miss rate = Cache misses / Cache access 

Average access time = Hit latency + Miss rate * Miss latency

 

캐시는 반응 속도가 빠른 SRAM으로 주소가 키로 주어지면 해당 공간에 즉시 접근할 수 있다. 

주소가 키로 주어졌을 때 그 공간에 즉시 접근할 수 있다는 것은 캐시가 하드웨어로 구현한 해시 테이블과 같다는 뜻이다. 

그래서 캐시가 빠른 이유는 자주 사용하는 데이터를 담아서 이기도 하지만 해시 테이블의 시간 복잡도가 O(1)정도로 빨라서  이기도 하다. 

 

캐시는 블록으로 구성되어있다. 각각의 블록은 데이터를 담고 있고 주소값을 키로써 접근할 수 있다. 

---

캐시 소개는 이 정도로 하고 consistency에 이어 본론을 얘기해보자. 이때 등장하는 개념이 Cache invalidation이다. 즉 캐시 무효화라 한다. 

 

아래의 3가지 방법이 존재한다. 

 

1. Write-through cache (동시기록 캐시)

write-through는 동시 쓰기다. 어떤 값을 write 해야하면 캐쉬 뿐 아니라 HDD/SSD에도 값을 쓰는 방법이다. 

메모리 뿐 아니라 HDD/SSD에도 값을 저장하므로 데이터 손실이 없으나 매번 HDD/SSD에도 값을 써야 하기 때문에 write 속도가 상대적으로 느리다. 

 

2. Write-back cache 

어떤 값을 갱신해야 하면 캐시에 먼저 쓴다. HDD/SSD에는 캐시 수정 내용이 반영되지 않고 특정 시간/조건마다 반영된다. 즉 write에도 빠른 속도를 기대할 수 있다. 그러나 HDD/SSD에 바로 값을 갱신하지 않기 때문에 서버에 문제가 생기면 데이터가 손실될 수 있다. (메모리에 들고 있다가 서버가 죽으면 consistency가 순간적으로 깨질 수 있다는 뜻인 것 같다.)

 

3. Write-around cache (No-write allocate or write-no-allocate)

어떤 데이터를 갱신할 때 캐시는 건너뛰고 바로 HDD/SSD에 값을 저장한다. 

캐시는 read 요청이 왔을 때 그 값이 캐시에 없으면 HDD/SSD로부터 값을 가져온다. write가 많이 발생하지만 그 값을 다시 읽는 경우가 별로 없을 때 쓰면 좋다. 

(글쎄 이 방법은 consistency가 보장될 수 있는 방법인가? 추가적으로 내용을 좀 더 찾아보자.)

 

캐시 관련 용어 중 stale data라는 용어가 있는데 stale은 신선하지 않은, 탁한 이라는 뜻이다. 즉 더 이상 유효하지 않은 과거의 데이터를 들고 있다는 뜻이다. 주요 storage에는 data의 변화가 일어났는데 해당 변화에 대해서 cache는 모르고 있는 상황에서의 데이터를 의미한다. 

---

개인적인 생각을 말하자면 거대한 아키텍쳐에서 redis 혹은 memcached를 캐시의 용도로 사용하고 성능을 개선하기 위해 특정 아키텍쳐 영역을 cache 용도로 사용하는 것을 보자면 결국 단일 컴퓨터의 구성 요소들을 거대한 아키텍쳐로 추정하는 확대 추상화를 하는 것이 아닐까 싶다.

 

컴퓨터 내부의 CPU 옆의 아주 작은 캐시는 결국 거대 아키텍쳐의 Redis같은 캐시로 확대 추상화되며, 마찬가지로 컴퓨터 내의 Disk 같은 HDD/SSD 스토리지는 거대 아키텍쳐의 RDB혹은 S3로 확대 추상화되는 것이다. 그런 면에서 서비스는 그저 작은 프로세스일 뿐이다.

 

역설적으로 거대한 아키텍쳐를 잘 설계하기 위해서는 오히려 가장 디테일한 컴퓨터의 작동 원리와 구성 요소의 장단점을 확실하게 알고 있어야하겠다는 생각이 들곤 한다. 

---

Cache invalidation은 CDN과도 연계된 내용이 많은데 해당 내용은 다음 포스팅에서 다루겠다. 

 

아래 영상은 앞서 언급한 인스타그램의 Scailing 인프라와 관련된 유튜브 영상이다. 

5년 전 영상이지만 꽤 재미난 영상이다. 

 

https://www.youtube.com/watch?v=hnpzNAPiC0E 

---

아래 링크에서 많은 도움을 받았습니다. 

 

감사합니다. 

 

캐시 무효화 

https://darkstart.tistory.com/152

https://wnsgml972.github.io/database/2020/12/13/Caching/

https://velog.io/@ha0kim/2021-02-22

https://toss.tech/article/smart-web-service-cache

캐시 동작의 아주 구체적인 원리 (굉장히 좋은 글입니다. 감사합니다.)

https://parksb.github.io/article/29.html