캐시(Cache)란?
캐시란, 데이터를 빠르게 읽고 처리하기 위해 (속도가 빠른 메모리를 활용하여) 미리 데이터를 저장해두는 임시 저장소이다.
계산된 값을 임시로 저장해두고, 동일한 계산이나 요청이 발생하였을 때 다시 계산하지 않고 저장된 값을 바로 사용하는 것이다. 이것을 캐싱이라고 하며 이 때 사용하는 임시 저장소를 ‘캐시’라 하는 것이다.
캐시의 활용
캐시는 컴퓨터 공학 전반의 매우 다양한 곳에서 쓰이는데, BE 개발자에게 익숙한 두 가지를 뽑아보면 DP와 JPA를 예로 들 수 있다.
Dynamic Programming의 앞글자를 따서 DP라고 하는데 이 DP에서는 이전의 값을 저장할 때 캐시의 역할을 사용한다.
JPA의 영속성 컨텍스트도 내부적으로 직접 데이터베이스에 접근하지 않고, 1차 캐시에 먼저 접근하여 캐시에서 데이터를 가져와서 성능적인 이점을 가져간다.
CDN에서도 캐시가 사용된다. 이미지나 동영상 같은 큰 파일들은 CDN이라는 곳에 캐싱이 되는데, 만약에 용량이 큰 파일을 요청했을 때 사용자와 서버의 물리적인 거리가 멀다면 해당 파일은 네트워크를 따라 이동하게 되면서 파일 전송에 많은 시간을 소요하게 된다. 이때 원본 서버의 파일들을 미리 PoP 서버에서 응답하도록 하면 네트워크 지연 시간을 줄일 수 있다.
우리가 Redis를 이용해서 백엔드 서비스 구현 시에 사용하게 될 캐싱은 ‘어플리케이션 캐싱’이라고 하는데, 어플리케이션에서 데이터나 계산 결과를 캐싱해서 반복적인 작업을 최적화하는 것을 의미한다.
왜 캐시를 써야 할까?
파레토의 법칙이라는 게 있다. 전체 결과의 80%가 전체 원인의 20%에서 비롯된다는 개념이다. 특정 소수의 요소가 대부분의 결과를 초래한다는 것을 의미하는데, 이해를 돕자면 캐시에 자주 사용되는 약 20%의 데이터를 미리 캐싱해 둔다면 효과적인 성능 향상을 이끌어 낼 수 있다는 것이다.
캐시 히트와 캐시 미스
캐시 히트(Cache Hit)
•
캐시 히트는 캐시 서버에 특정 키를 가진 캐시를 요청했을 때, 정상적으로 응답이 오는 경우, 즉 캐시에 원하는 데이터가 존재하는 경우를 말한다. 이 경우 해당 데이터를 바로 반환할 수 있다.
캐시 미스(Cache Miss)
•
캐시 미스는 키가 잘못되었거나 해당 데이터가 이미 만료되어 데이터를 응답하지 못하는 경우, 즉 캐시에 원하는 데이터가 없는 경우를 말한다. 이 경우 DB로 직접 찾아가서 데이터를 찾아와 반환해야 한다.
캐시 전략 패턴
캐시 전략 패턴이란 ‘실제 캐시를 도입할 때 상황에 맞추어 적용될 수 있는 전략 패턴’이다. 읽기 전략과 쓰기 전략이 있는데, 읽기 전략은 Look Aside 패턴과 Read Through로 있으며, 쓰기 전략은 Write Around 패턴, Write Back 패턴, Write Through 패턴이 있다.
== 읽기 전략 ==
Look Aside 패턴
Look Aside 패턴은 캐시의 데이터가 없을 때 DB를 조회해서 데이터를 읽어오는 전략이다.
1.
데이터가 있다면, 즉 캐시 히트라면 애플리케이션(클라이언트 + 서버)은 원하는 데이터를 캐시에서 가져올 수 있다.
2.
데이터가 없다면, 즉 캐시 미스라면 DB에서 데이터를 가져온다.
3.
캐시에 올려놓고 사용한다.
이 패턴의 장점은 캐시에 문제가 생기는 경우 DB로 요청을 위임해서 데이터를 가져올 수 있다는 점이다. 반대로 DB와 캐시 사이의 연결점이 없기 때문에(동기화가 되지 않았기에) 데이터 정합성 유지가 어렵다. 또한 첫 번째 조회를 할 때 항상 DB로부터 데이터를 가져와서 캐시에 올려놓고 사용할 수밖에 없기 때문에 DB에 부하가 오기 쉽다는 것이 단점이다.
Read Through 패턴
Read Through 패턴은 항상 캐시가 직접 DB에서 데이터를 가져오는 전략이다. 즉, 항상 캐시를 통해서 읽는 전략이다.
1.
캐시 히트인 경우 애플리케이션이 캐시 스토어로부터 데이터를 읽어온다.
2.
캐시 미스라면 DB로부터 캐시가 데이터를 직접 가져온 후 그 데이터를 애플리케이션을 읽게 된다.
Look Aside 패턴과 상반된 느낌이다. 이 전략의 장점은 캐시와 DB 간에 이런 연결점이 있기 때문에 항상 데이터의 정합성이 보장된다고 할 수 있다. 하지만 캐시가 죽어버리면 애플리케이션에서도 문제가 발생한다는 것이 단점이다.
== 쓰기 전략 ==
Write Around 패턴
Write Around 전략은 캐시를 우회해서 직접 쓰는 전략을 의미한다.
1.
애플리케이션이 직접 DB에 바로 쓴다.
2.
캐시 미스가 발생한다면 데이터를 캐시 저장소에 쓴다.
이 전략의 장점은 캐시를 거쳐서 쓰지 않고 DB에 바로 써서 성능이 좋다. 또한 불필요한 데이터를 캐시에 올리지 않고 바로 쓰기 때문에 리소스를 아낄 수 있다는 점이다. 반면 캐시와 DB 사이의 연결점이 없기 때문에 데이터 정합성 유지가 어렵다는 점이 단점이다.
Write Back 패턴
Write Back 전략은 캐시에 데이터를 미리 한꺼번에 써 놓고 나중에 DB 쓰기 작업을 진행하는 전략이다.
1.
먼저 캐시에 많은 양의 데이터를 쓴다.
2.
그 후 DB에 쓰기 작업을 진행하는데, 이 때 스케쥴링 방식을 사용한다. 따라서 일정 시간이 지난 후에 한꺼번에 많은 양의 데이터를 한 번의 쓰기 요청으로 해결할 수 있다.
많은 양의 데이터를 쓰게 되면 insert문이 여러 개가 나가기에 성능의 문제가 생길 수 있는데, 하나의 insert문으로 묶어서 데이터를 처리하기 때문에 성능적인 이점이 있다.
결론적으로 장점은 쓰기 횟수에 대한 비용을 줄일 수 있다는 것인데 만약 캐시 저장소에만 데이터를 써 놓은 상태에서 캐시가 죽어버리게 된다면 데이터가 DB까지 직접 insert되지 않을 것이다. 이러한 데이터 유실 문제가 생길 수 있다는 것이 단점이다.
Write Through 패턴
Write Through 전략은 항상 캐시를 통해서 쓰기를 진행하는 패턴을 의미한다.
1.
캐시를 통해서 먼저 쓰고,
2.
바로 데이터베이스에 쓰기 작업을 진행한다.
이 패턴은 항상 캐시를 거쳐 DB로 가기 때문에 데이터의 정합성은 보장되지만 필수적으로 무조건 두 번의 쓰기가 항상 진행되기 때문에 성능을 고려하여 사용해야 한다는 것이 단점이다.
캐시 사용 시 주의사항!!
위 내용들을 종합해 봤을때, 캐시 사용 시 어떤 점을 주의하며 사용해야 할까?
•
자주 사용되면서 변경이 되지 않는 데이터
•
유실되어도 크게 문제가 없는 데이터
•
데이터베이스와 함께 사용할 때 데이터 정합성 문제를 고려