캐시와 설계 시스템 전략
Cache
캐시는 자주 사용되는 데이터나 연산 결과를 임시로 저장하는 고속의 저장 공간을 의미한다. CPU 캐시, 웹 브라우저 캐시, 메모리 캐시 등이 있다. 캐시가 사용되는 대표적인 예시로 DP 알고리즘이 있다. 이전의 값을 저장할 때 캐시의 역할을 사용하고 있다.
* 캐싱 : 나중의 요청에 대한 결과를 미리 저장했다가 빠르게 사용하는 것. (행위)
또한 JPA 의 Entity Manager 또한 내부적으로 캐시를 통해 직접 데이터베이스에 접근하지 않고 1차 캐시에서 데이터를 가져와 성능적인 이점을 가져오고 있다.
그렇다면 이 결과는 어디에 미리 저장하는 것일까? 메모리 계층 구조 사진을 보면 이해할 수 있다.
조금 더 쉬운 예시로 맥북을 생각해보자.
M2Pro CPU - 12MB Cache Memory
16GB DRAM
512 SSD
이 중 12MB Cache Memory는 SRAM 이라 하여 CPU 캐시 영역으로 해당된다.
빠르고 비싸고 용량이 작으므로, 데이터베이스로 사용하기에는 작음
16GB DRAM 은 휘발성.
적당히 빠르고, 적당히 비싸고, 적당히 크다.
512 SSD 은 비휘발성
비교적 느림, 저렴하고, 엄청 큼.
캐시 사용 이유
파레토의 법칙 :
- 80퍼센트의 매출은 20퍼센트의 고객으로부터 나온다.
- 80퍼센트의 성적은 20퍼센트의 공부에서 나온다.
즉 80%의 결과가 20% 의 원인으로 부터 나온다는 이론.
이를 캐시에도 적용할 수 있다. 캐시에 자주 사용되는 약 20%의 데이터를 미리 캐싱해둔다면 효과적인 성능 향상을 야기할 수 있다는 것이다.
캐시의 지역성
캐시가 효율적으로 동작하려면, 캐시에 저장할 데이터가 지역성을 가져야 한다. 지역성이란 데이터 접근이 시간적 혹은 공간적으로 가깝게 일어나는 것을 말한다.
- 시간 지역성 : 특정 데이터에 한번 접근해서 가져온 경우, 그 데이터가 가까운 미래에 또 한번 접근할 가능성이 높은 것. 캐시는 반복으로 사용되는 데이터가 많을수록 높은 효율을 보일 수 있다.
- 공간 지역성 : 참조된 주소와 인접한 주소의 내용이 다시 참조되는 특성. 필요한 데이터들이 모여있다면 한번만 메모리에 접근해도 필요한 데이터들을 많이 가져올 수 있을 것이고, 흩어져 있다면 catch miss 가 날 확률이 높아질 것이므로 효율성이 떨어지게 된다.
지역성의 원리
캐시메모리는 병목현상을 줄이기 위한 범용메모리이고 이런 역할을 수행하기 위해서는 CPU가 원하는 데이터를 어느정도 예측할 수 있어야 한다. 왜냐하면 캐시의 성능을 좌우하는 것은 작은 용량의 캐시 메모리에 CPU가 사용할 의미있는 정보가 얼마나 들어있는가 이기 때문이다.
이때 Hit rate를 극대화 시키기 위해 지역성의 원리를 사용한다.
* 데이터 정합성
캐시를 이용하게 되면 반드시 닥쳐오는 문제점이 있는데 바로 데이터 정합성 문제이다.
데이터 정합성이란, 어느 한 데이터가 캐시(Cache Store)와 데이터베이스(Data Store) 이 두 곳에서 같은 데이터임에도 불구하고 데이터 정보값이 서로 다른 현상을 말한다.
출처: https://inpa.tistory.com/entry/REDIS-📚-캐시Cache-설계-전략-지침-총정리 [Inpa Dev 👨💻:티스토리]
캐시 전략 패턴
데이터 정합성 문제를 보완하기 위하여 다양한 캐시 전략 패턴을 도입할 수 있다. 실제 캐시를 도입할 때 상황에 맞추어 적용될 수 있는 전략패턴이다.
읽기 전략
Look Aside 패턴 :
캐시에 데이터가 없을 때 DB (Cache 의 입장에서 Aside) 를 찾아본다.
클라이언트가 서버에 요청을 보냈을 때, 서버는 원하는 요청을 캐시에서 찾아올 수 있다. 캐시에 데이터가 있다면 말이다. 하지만 데이터가 없다면 aside를 본다. 즉, Database를 본다. 그리고 이것을 캐시에 올려놓고 사용한다.
- 장점 : 캐시에 문제가 생기는 경우 전적으로 DB 에 위임하여 데이터를 가져올 수 있다.
- 단점 : DB 와 캐시를 직접 잇는 연결(즉 동기화 ) 가 되지 않기 때문에 정합성 유지가 어렵다. 또한 첫 번째 조회를 할 때는 항상 DB에서 데이터를 가져와서 캐시에 두고 사용하기 때문에 DB에 부하가 발생하게 된다.
Read Through 패턴
: 읽다 ~를 통하여 => 항상 캐시를 통해서 읽는 전략
어플리케이션이 있을 때 캐시스토어로부터 데이터를 읽어오며, 없다면 DB 로부터 캐시가 읽어서 어플리케이션에게 전달한다.
- 장점 : DB와 캐시가 연결되어있으므로 정합성이 보장
- 단점 : 캐시가 죽어버리면 어플리케이션도 문제가 발생
쓰기 전략
- SNS, 온라인 쇼핑 어플리케이션, 로그 및 이벤트 추적 시스템, 게임 서버 등
Write Through (캐시 통해서 쓰기)
캐시를 주 데이터 저장소로 취급한다. 즉, 데이터는 먼저 캐시에 업데이트 되고, 그 다음에 DB 에 업데이트 된다. 쓰기 작업이 완료되면 캐시와 DB는 동일한 값을 갖게 되며, 캐시는 항상 일관성을 유지한다.
- 장점 : 캐시 통해서 읽기(Read-Through) 와 함께 사용되면 네트워크 호출에서 매우 효과적이며, 캐시에 데이터가 먼저 읽혀지거나 쓰여지기 때문에 캐시 무효화(invalidation) 이 거의 발생하지 않는다. DB 로의 모든 쓰기 작업이 캐시를 통해 이루어지므로 DB와 캐시는 거의 일관성을 유지한다.
- 단점 : 자주 엑세스되는 데이터일 경우에 유리하다.
Write Back ( Write Behind : 쓰고 나서 캐시)
캐시 통해서 쓰기(Write-Through)와 매우 유사하지만, 데이터베이스 쓰기가 비동기적으로 이루어진다는 차이가 있다. 가장 최근에 업데이트된 데이터가 항상 캐시에서 사용 가능하도록 보장되므로, Read-Through 와 Write-behind 를 함께 사용하는 혼합 워크로드에서 적합한 캐시 전략.
- 장점 : 쓰기 성능을 향상 (대량의 쓰기 작업이 있는 워크로드에서 가장 이상적). DynamoDB와 같이 요청 횟수에 따라 요금을 부여하는 DB 의 경우 네트워크 비용이 감소.
- 단점 : 드물게 요청되는 데이터도 캐시에 저장될 수 있다. (이는 TTL을 통해 최소화할 수 있음)
Write Around (캐시 나중에 쓰기)
- 실시간 로그 또는 채팅룸 메시지의 경우 적합
DB에 먼저 DML 명령을 업데이트한 뒤, DB가 캐시에 대한 비동기 호출을 통해 키를 업데이트. 쓰기 요청이 오면 어플리케이션은 DB 레코드를 업데이트한다. 그 다음 DB는 캐시에서 비동기적으로 키를 업데이트 하거나 삭제.
캐시 통해서 읽기(Read-Through) 와 결합하여 한번 쓰여지고 자주 또는 전혀 읽혀지지 않는 경우에 좋은 성능 제공.
ref :
https://www.youtube.com/watch?v=Gimv7hroM8A
https://dbstndi6316.tistory.com/222
https://soobing.github.io/cs/6-caching-strategies/