[Tech] 캐시 서버와 캐싱 전략

 

 

해당 글은 아래의 내용을 참고하여 작성하였습니다.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html

 

 

캐시 서버란?

 

요청에 대한 응답을 더 빠르게 하기 위해서 우리는 "캐시"라는 것을 종종 사용합니다.

특히 컴퓨터에서 자주 읽거나 방금 전에 읽은 데이터를 캐시에 저장하곤 하죠.

이러한 캐시를 통해 우리는 상대적으로 데이터를 찾아 가져오는 것이 느린 디스크를 거치지 않고도 데이터를 가져올 수 있게 됩니다.

 

이러한 캐시의 개념은 서버에도 도입되어있는데요, 흔히 말하는 "캐시 서버"가 바로 그 용도입니다.

흔하게 웹서비스는 클라이언트가 요청을 하면, 웹서비스가 이것을 받고, DB에서 필요한 데이터를 가져와 응답하는 구조를 갖게 됩니다.

하지만 DB에 수십억의 데이터가 쌓여있다고 가정해봅시다.

사용자가 어떤 데이터를 요청하고 웹서버가 이 알맞는 데이터를 찾기 위해 DB, 즉 디스크에서 긴 시간을 쓰게 되겠죠?

이렇듯 위와 같은 단순한 구조로는 데이터가 많아지는 상황에서 응답 속도가 점점 느려지게 됩니다. 

 

따라서 우리는 디스크인 DB가 아닌 인메모리 구조를 지닌 캐시 서버에서 데이터를 가져오는 것을 고안하게 됩니다.

DB까지 가서 데이터를 찾기 전에 먼저 캐시 서버에 들러 데이터가 있는지 확인해 보는 것이죠.

만약 캐시 서버에 데이터가 있다면 DB에 가지 않더라도 바로 사용자의 요청을 처리할 수 있으니 응답 속도가 더 빨라지게 됩니다.

 

 

 

캐싱 전략

위의 설명에서는 캐시의 예시를 빠른 응답 속도를 기준으로 설명했지만, 이러한 캐시 서버는 목적에 따라 다르게 사용할 수 있습니다.

그 중에서 자주 사용되는 캐시 전략들 몇가지에 대해서 알아보겠습니다.

 

Lazy Loading

Lazy Loading이라는 이름에서 볼 수 있듯이, 필요할 때에만 캐시에서 데이터를 가져오는 방법입니다.

클라이언트가 요청을 하게 되면, 웹 서버는 DB가 아닌 캐시에서 먼저 데이터를 찾게 됩니다.

만약 캐시에서 데이터를 찾게 되면 DB까지 가지 않고 그 데이터를 가지고 클라이언트에게 응답하게 되죠.

그러나 캐시에서 데이터를 찾지 못한 miss 상태라면 DB에서 데이터를 가져오게 됩니다.

이 때 DB로부터 데이터를 가져오는 데에서 끝나는 것이 아니라, 이후에 다시 요청할 것을 대비해서 캐시에 이 데이터를 저장하게 됩니다.

이를 통해 필요한 데이터들만 캐시에 넣어놓아 클라이언트에게 더 빠르게 응답할 수 있도록 합니다.

 

Lazy Loading의 장단점

장점으로는 필요한 데이터를 주로 캐싱한다는 점이 있습니다.

데이터는 주로 요청되던 것이 높은 확률로 재요청되고, 잘 사용하지 않은 데이터들이 보통 더 많습니다.

따라서 Lazy Loading의 경우 한번 요청된 데이터만 캐시에 넣기 때문에 캐시의 공간 확보에 용이합니다.

또한 캐시 서버의 일부에서 장애가 발생해 새로운 노드를 가동하게 되면, 다시 캐시에 데이터를 채워넣기만 하면 문제가 없습니다.

 

단점으로는 캐시가 miss되면 캐시를 왔다갔다 한 시간 + DB에서 데이터를 찾는 시간 + DB에서 캐시로 데이터를 넣는 시간 만큼 지연시간이 생기기 때문에 바로 DB를 조회하는 것에 비해 좀 더 패널티가 있습니다.

DB에서 캐시로 데이터를 복사한 후에도 문제가 생길 수 있습니다.

캐시에 데이터가 있는 상태로 요청을 보내면 DB에서 조회하지 않고 바로 캐시에서 데이터를 조회하기 때문에, 이후에 DB에서 데이터가 바뀌더라도 캐시가 알 수 없다는 단점이 있습니다.

 

 

Write Through

이러한 단점을 보완할 수 있는 것이 바로 Write Through 전략입니다.

Write Through는 DB에 데이터를 쓰거나 업데이트 할때 Cache에 이를 함께 반영합니다.

즉, 캐시에 먼저 쓴 뒤에 DB에 쓰게 되는 것이죠.

이렇게 되면 캐시의 데이터는 최신 상태로 유지되겠지만, 몇가지 문제점이 생깁니다.

만약 캐시 서버에 장애가 생겨 새 노드로 교체되면, 이후에 DB에 쓰거나 업데이트 하는 작업이 이뤄지기 전까지는 캐시에 해당 데이터가 누락됩니다.

그리고 읽히지 않을 가능성이 높은 데이터들도 모두 캐시 서버에 있게 되므로 공간 낭비가 심해지겠죠.

 

따라서 Writhe Through를 사용할 때에는 보통 TTL(Time To Live)을 추가하게 됩니다.

TTL을 설정하게 되면 캐시에 있는 데이터가 영구적으로 있는 것이 아니라, 일정 시간만큼만 있게 됩니다.

TTL이 지나고 나면 이후에 캐시에 있는 데이터가 삭제되어 조회시에 miss되고, DB에 있는 데이터로 조회하기 때문에 잘못된 값을 캐시가 기록하고 있는 걸 방지해줍니다.

때문에 TTL은 Write Through 외에 Lazy Loading에서도 사용됩니다.