캐시가 뭐에요?
캐시가 무엇인지 정리해보고자 합니다.
회사 서비스에 Redis를 도입하게 되었습니다. 데이터를 메모리에서 처리함으로써 더 빠른 연산을 도모하고 DB의 부하를 덜기 위한 것(캐싱)이었습니다.
Redis 문서가 잘 되어 있어서 서비스에 도입하는 데까진 문제가 없었습니다. 하지만 캐시가 뭐냐고 물었을 때 간단한 답밖에 하지 못한다는 것을 깨달았습니다. 그래서 정리해보고자 합니다.
캐시(Cache)란?
컴퓨터 과학에서 데이터나 값을 미리 복사해 놓은 임시 장소를 일컫습니다. 원본 데이터에 접근하는데 걸리는 시간이 캐시의 접근 시간보다 오래 걸리는 경우나 값을 다시 계산하는데 걸리는 시간을 단축시키고 싶은 경우 사용합니다.
예를 들자면, 다이소 본점에 가서 물티슈 하나 사는 것보다 집 앞에 있는 다이소에 가는 게 더 빠르게 사 올 수 있습니다.
캐시에는 어떤 정보를 담아야 할까?
캐시에 담을 정보를 생각할 때 많이 고려하는 법칙이 파레토의 법칙입니다. 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상입니다.
이것을 웹 서비스 분야에 적용하자면 전체 요청 중 80%는 같은 요청이라는 이야기입니다. 그래서 캐시에 담을 정보는 본인 서비스에서 어떤 요청이 가장 많은지 파악한 다음 적용해야 합니다.
지역성 (Locality)
캐시에 담을 정보를 파악하는 데 사용하는 개념입니다.
시간 지역성 (Temporal Locality): 한번 요청받았던 정보는 가까운 시일 내에 또 요청받을 수 있다는 개념입니다. 같은 쿼리로 여러 차례 요청을 받았다면 그 요청만 캐시에 저장해도 성능의 향상을 꾀할 수 있습니다.
공간 지역성 (Spatial Locality): 특정 데이터와 가까운 주소가 순서대로 접근되었을 경우를 말합니다. CPU 캐시나 디스크 캐시의 경우 한 메모리 주소에 접근할 때 그 주소뿐 아니라 해당 블록을 전부 캐시에 가져오게 됩니다.
캐시가 효율이 좋다면 다 저장하면 되지 않을까? 물론 저장해도 됩니다… 돈이 많다면! 하지만 우린 효율을 따져보고 최상의 결과를 내야 합니다. CACHE IS CASH.
캐싱 전략
Cache Aside (Lazy Loading)
가장 보편적으로 쓰이는 전략입니다.
Cache Aside 전략 흐름도
캐시는 DB와 직접 연결되지 않고, 애플리케이션이 주체가 됩니다. 애플리케이션이 요청을 받으면 데이터가 캐시 서버에 있는지 확인합니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환하고, 없으면(Cache Miss) DB에서 데이터를 확인하고 캐시에 저장 후 반환합니다.
장점
- 요청받은 데이터만 캐시에 저장하니까 불필요한 데이터를 담지 않음
- 캐시 미스가 일어나도 치명적이진 않음
단점
- 동시성 문제가 있어요. 캐시에 데이터가 있는 채로 DB의 데이터가 UPDATE 되면 불일치 발생
- 캐시 미스 시 지연 발생
해결책
- 동시성 문제는 캐시 데이터에 만료 기간(TTL)을 설정하면 됨
- 캐시 미스 지연은 미리 많이 요청될 것 같은 데이터를 캐시해두면 완화됨
Write Through
Write Through 전략 흐름도
애플리케이션이 직접 바라보는 것은 DB가 아니라 캐시가 됩니다. 데이터가 캐시와 DB에 모두 반영되었을 때 정상적으로 성공했다고 간주합니다.
장점. Cache Aside 전략의 동시성 문제를 해결할 수 있죠.
단점
- 불필요한 데이터까지도 캐시에 담길 수 있어서 메모리 낭비 가능
- 쓰기 작업이 많은 서비스라면 성능이 오히려 떨어질 수 있음
Read Through
Read Through 전략 흐름도
애플리케이션이 바라보는 것은 DB가 아니라 캐시입니다. 최초 데이터 로딩은 미스가 발생하며, 그때 데이터가 로딩됩니다.
Cache Aside와 뭐가 다르냐면, Cache Aside는 애플리케이션이 캐시 데이터를 채우고, Read Through는 캐시 자체가 채운다는 점이에요.
읽기 작업이 많은 경우 적합합니다.
Write Behind (Write Back)
Write Behind 전략 흐름도
쓰기 요청은 캐시까지만 처리됩니다. 그리고 별도의 스케줄 작업 등으로 캐시의 데이터가 DB에 동기화됩니다.
티켓팅, 이벤트 참여, 대규모 프로모션 등 쓰기 작업이 한 번에 많이 일어날 때 적합합니다.
단점. 캐시에 데이터를 한 번에 모아뒀다가 후에 순차적으로 처리하기 때문에, 그 사이에 장애가 발생하면 데이터가 유실될 수 있어요.
결론
글을 작성하면서 캐시 전략이 있다는 것에 놀랐어요. 그리고 프로젝트에 도입했던 게 Cache Aside 전략이라는 이름이 있다는 것에 또 한 번 놀랐습니다.