Cache(캐시)
자주 사용하는 데이터의 값을 미리 복사해 놓는 임시 저장소를 캐시라고 한다.
캐시는 저장공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.
다음과 같은 경우에 캐시를 사용하게 되면 효과를 볼 수 있다.
- 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우 (서버의 균일한 API 데이터)
- 반복적으로 동일한 결과를 반환하는 경우 (이미지, 썸네일 등)
보통 Redis를 캐시로 많이 사용한다.
싱글스레드로 원자성을 보장하고 NoSQL로 데이터의 입출력이 빠르기 때문이다.
Redis에 대한 자세한 포스팅 : https://skroy0513.tistory.com/58
캐싱전략
캐시를 사용할 때는 '읽기 전략', '쓰기 전략'이 존재한다.
읽기 전략에는 'Look Aside', 'Read Through' 등이 있고, 쓰기 전략에는 'Write Back', 'Write Through', 'Write Around' 등이 있다.
Cache hit : 캐시에 데이터가 있을 경우 바로 가져옴 (빠름)
Cache miss : 캐시에 데이터가 없을 경우 DB에서 가져옴 (느림)
읽기 전략
Look Aside
데이터를 우선 찾을 때 캐시에서 먼저 찾고 찾고자 하는 데이터가 없다면 DB에서 데이터를 가져오는 전략이다.
Cache miss가 발생한다면 DB에서 데이터를 가져온 뒤 캐시에 해당 데이터를 넣어주는 작업까지 진행을 하게 된다.
반복적인 읽기 작업이 많은 호출에 적합
Look Aside의 장점으로는 반복적인 읽기가 많은 호출에 적합하다.
캐시와 DB가 분리되어 있기 때문에 필요한 데이터만 캐시에 담을 수 있어서 리소스의 낭비를 방지한다.
또한 분리되어 있어 캐시가 장애를 일으켜도 서비스에는 문제가 없다.
단점으로는 connection이 많이 있던 캐시가 다운될 경우 한순간에 connection들이 DB로 몰린다면 DB에 큰 부하가 발생할 수도 있다.
Read Through
캐시에서만 데이터를 읽어오는 전략이다.
Cache miss가 발생한다면 DB에서 데이터를 검색하고 캐시를 자체 업데이트를 한 뒤에 데이터를 보내주는 작업을 한다.
역시 읽기가 많이 호출되는 작업에 적합하다.
Read Through의 장점으로는 데이터 동기화가 항상 이루어져 있기 때문에 데이터 정합성 문제에서 벗어날 수 있다.
또한 DB 접근을 최소화하고 Read에 대한 소모되는 자원을 최소화할 수 있다.
단점으로는 데이터를 조회하는 속도가 Look Aside에 비해 느리며, 캐시가 다운된다면 서비스에 차질이 생길 수가 있다.
쓰기 전략
Write Back
먼저 캐시에 저장했다가 특정 시점마다 DB에 update 하는 전략이다. (스케줄링)
Write가 빈번하게 일어나면서 Read를 하는데 많은 양의 리소스가 소모되는 작업에 적합하다.
Write Back의 장점으로는 쓰기 쿼리 회수 비용과 부하를 줄일 수 있고, 데이터의 정합성을 확보할 수 있다.
또한 DB에 장애가 발생하더라도 서비스를 온전히 제공할 수 있도록 보장해 준다.
단점으로는 자주 사용되지 않는 불필요한 리소스를 저장하기도 하며, 캐시에서 오류가 발생하면 데이터를 영구히 소실한다는 점이다.
Write Through
데이터를 저장할 때 캐시에 저장한 다음 DB에 저장하는 전략이다.
데이터의 유실이 발생하면 안 되는 작업에 적합하다.
Write Through의 장점으로는 데이터의 일관성을 유지할 수 있어서 안정적이며,
DB와 동기화가 되어있어 항상 최신의 데이터를 가지고 있다는 점이다.
단점으로는 데이터를 저장할 때 2단계의 과정을 거치기 때문에 상대적으로 느리며, 불필요한 데이터가 캐시에 저장될 가능성이 있어서 리소스의 낭비가 존재하기도 한다.
Write Around
모든 데이터는 DB에 저장하고 읽은 데이터만 캐시에 저장하는 전략이다.
Cache miss가 발생하는 경우에만 캐시에 저장한다.
Wirte Around의 장점으로는 낭비되는 리소스를 줄일 수 있다. 또한 데이터의 재사용성이 없는 상황에는 좋은 성능을 낼 수 있다.
단점으로는 DB와 데이터 불일치가 발생할 수 있다. 그래서 DB에서 데이터가 변경될 때마다 캐시의 데이터를 일일이 수정/삭제/등록을 해야 하는 경우가 생길 수도 있다.
읽기 + 쓰기 조합
Look Aside + Write Around
가장 일반적으로 자주 쓰이는 조합
Read Through + Write Around
항상 DB에 작성하고 캐시에서 읽을 때 항상 DB에서 먼저 읽어오므로 데이터 정합성 이슈에 대한 완벽한 안전장치를 구성할 수 있음
Read Through + Write Through
데이터를 쓸 때 항상 캐시에 먼저 쓰므로, 읽어올 때 최신 데이터 보장
또한 캐시에서 DB로 데이터를 보내므로 데이터 정합성 보장
참고
'멋진 개발자 > DB' 카테고리의 다른 글
| 개발자 성장 기록 59 - ACID (0) | 2024.05.08 |
|---|---|
| 개발자 성장 기록 58 - 복합키 (0) | 2024.05.06 |
| 개발자 성장 기록 56 - JOIN (0) | 2024.04.25 |
| 개발자 성장 기록 50 - 인덱스(Index) (0) | 2024.04.17 |
| 개발자 성장 기록 49 - Oracle과 MySQL (0) | 2024.04.16 |
