🍊 ElastiCashe
RDS와 동일한 방식으로 관계형 데이터베이스를 관리하는 툴로 캐시 기술을 관리 합니다.
캐시란 높은 성능과 낮은 지연시간을 자긴 인 메모리 데이터베이스 입니다.
일래스틱 캐시를 사용하면 부하를 줄이는데에 도움이 됩니다.
- 쉽게 말해 일반적인 쿼리가 캐시 되어 매번 사용하는 것을 의미합니다.
일래스틱 캐시, RDS, 애플리케이션이 있다고 가정을 하겠습니다.
애플리케이션은 일래스틱 캐시를 쿼리합니다.
- 트래픽을 주고받을떄를 말하빈다.
이미 쿼리가 생성되어 잇다면 캐시히트(이미 생성되어있는지 확인하는 작업)이고 바로 응답을 얻어서 동선을 줄입니다.
만약 쿼리가 없다면 캐시 미스(쿼리가 없는 상황)가 발생을 하여 RDS에서 데이터를 가져와서 읽습니다.
만약 이러한 캐시미스가 발생을 하면 가져온 데이터를 캐시에 다시 기록하여 이후에 같은 작업에서는 캐시 히트가 발생하게 유도 합니다.- 이러한 예시에서 알 수 있듯이 데이터를 캐시에 저장을 하기 떄문에 일래스틱 캐시를 사용할떄마다 가장 최근의 데이터만 사용하는지를 확인해야 합니다.
다른 아키텍처는 이와 같이도 활용 가능합니다.
사용자 세션을 저장합니다.
사용자 세션을 저장하여 애플리케이션은 무상태로 유지하고, 사용자가 애플리케이션의 계정에 로그인하면 해당 세션 데이터를 캐시에 기록하는 것 입니다.
이후 사용자가 애플리케이션의 다른 인스턴스로 리디렉션 되면 애플리케이션은 일래스틱 캐시에서 세션 데이터를 가져 오기 댸문에
사용자가 로그인했는지를 판단합니다.🔨 레디스(Redis) VS 멤캐시트
레디스
레디스는 자동 장애 조치로 다중 AZ를 수행하는 기술입니다.
RDS와 유사하게 읽기 전용 복제본을 만들어 읽기 행위에 대해서 높은 가용성을 제공합니다.
또한 지속성으로 인해 데이터 내구성도 있으며 백업과 기능 복원 기능도 지원합니다.
- RDS와 거의 유사하다고 생각하면 됩니다.
멤캐시트
데이터 분할에 다중 노드를 사용하는 것을 말하며 이를 샤딩이라고 합니다.
가용성이 높지 않고, 복제 및 지속적인 데이터베이스도 아니며, 백업과 복원 기능도 없습니다.
대신 다중 스레드로 동작을 하기 떄문에 여러개의 인스턴스가 잇습니다.
중요하게 기억해야 할 점은 이와 같습니다.
레디스는 읽기 전용 복제본등이 있고 RDS와 유사하다.
하지만 멤캐시트는 단순한 분산캐시로 샤딩으로 동작을 하게 된다.
그러기 떄문에 레디스는 데이터베이스로 활용 가능하지만, 멤캐시트는 단순 캐시 역할만 수행 가능합니다.
🍊 ElastiCashe 전략
데이터를 캐싱하는 것은 안전합니다. 물론 최신의 데이터가 아닐 수 있지만 결국에는 일관성을 유지할 것이며 이로인해 부하가 많이 줄어들게 될 것입니다.
하지만 모든 경우에서 캐싱이 좋은것은 아닙니다. 그러기 떄문에 캐싱해도 효과적인가에 대해서 고민을 해야 합니다.
이러한 관점에서 보았을떄 캐싱이 유효할떄는 데이터가 빠르게 바뀌지 않을떄 유효합니다.
만약 데이터가 빠르게 바뀐다면 캐싱은 효과적이지 못한 방법입니다.
예를들어 키값이 있고 결과를 키값과 연동하여 저장을 하고자 할떄에는 캐싱이 유리합니다.
- 단순히 키값을 따오면 되기 떄문입니다.🔨 레이지 로딩
캐시 어사이드, 레이지 포퓰레이션이라고도 합니다.
애플리케이션, 캐시, RDS가 있습니다.
일반적으로 애플리케이션이 요청을 하면 캐시에서 데이터가 캐시에 있다면 캐시히트가 발생을 하고 아닐경우에는 캐시미스가 발생을 할 것입니다.
만약 캐시에 없다면 데이터를 찾으러 RDS에 가게 될 것입니다.
이후 해당 데이터를 가져온뒤에 캐시에 기록을 합니다.
하지만 이러한 경우에서 총 3번의 네트워크 호출이 일어납니다.
- 애플리케이션에서 RDS로, 데이터베이스를 읽으면서, 캐시를 쓰면서
즉 캐시미스가 발생을 하면 지연현상이 발생할 수 있다는 뜻입니다.
또한 캐시에 오래된 데이터가 있을경우에도 비슷하게 동작을 합니다.예시 코드
const getUser = (userId) =>{
let result = cache.get(userId);
if(result === null){
result = db.query("select * from users where id =?", userId);
cache.set(userId, result);
return result
}
return result
}
getUser(17)🔨 라이트 스루
라이트 스루 전략은 데이터베이스가 업데이트될 때 캐시를 추가하거나, 업데이트하는 것을 의미합니다.
만약 애플리케이션이 RDS를 수정할떄 (insert, delete 등등) 일래스틱 캐시를 통해서 RDS를 수정합니다.
이러한 구조는 항상 최신의 데이터를 가져오고, 캐시 히트가 발생할 확률이 높다는 장점이 있지만
반대로는 계속해서 캐시도 수정하기 떄문에 많은 부하가 발생할 수 있습니다.
- 즉 읽기에서는 유리할 수 있지만 쓰기 행위에 대해서는 불리합니다.
- 그러기 떄문에 사용자 관점에서는 더 유리할 수 있습니다.
단점으로는 RDS에 기록되기 전에는 캐시에서는 데이터 누락이 발생할 수 있습니다.
RDS에 데이터를 먼저 저장한 뒤에 캐시에 저장을 하는 행위이기 떄문에 캐시에 저장이 되기 전에는 캐시에서 데이터를 읽어올떄 최신의 데이터가 아닐 수도 있고, RDS에 많은 데이터를 저장할 떄 캐시에는 그 모든 데이터를 저장하지 못할 수 있습니다.
- 캐시 용량이 부족한 경우를 캐시 이탈이라고 합니다.
예시 코드
const getUser = (userId, values) =>{
const result = db.query("update users ... where id = ?", userId, values);
cache.set(userId, values);
return result
}
getUser(17, {"name": "pet"})🔨 캐시제거 와 타임 투 리브(TTL)
캐시에는 제한된 크기가 있습니다.
그러기 떄문에 라이트 스루에서도 캐시 이탈이 발생을 할 수 있습니다.
이러한 상황을 해결하기 위해서 Cache Eviction 이라는 방법을 사용합니다.
가장 최근에 사용하지 않은 항목을 제거함으로써 동작을 하며 이를 LRU라고 하며, 캐시 데이터 항목을 TTL할수도 있습니다.
- TTL은 쉽게 말해 5분뒤 삭제 라는 느낌입니다.
🔨 캐시를 사용 해야 하는 경우
일반적으로 조회를 하는데에 많이 사용합니다.
대개 많은 경우에서 사용하는 것이 좋지만
다음과 같은 경우에서는 캐시를 사용하는것은 추천하지 않습니다.
- 가격 데이터
- 특히 은행 계좌 값에는 사용하지 않는 것이 추천 됩니다.
