Today I Learned
Chapter 1. 프로젝트에서 조회를 하면 캐싱 된 데이터를 가져오고, 데이터를 추가하면 캐시를 갱신해 주는 기능을 구현하고 사용했기 때문에 기록으로 남겨 두려고 한다.
🔥 여기서는 캐싱의 개념과 전략에 대하여 이해하고, 실습은 추가로 블로그를 작성하고 기록하도록 하자.
[ 캐싱 ]
Redis에서 많이 활용되는 주제로 캐싱은 자주 사용되는 데이터를 더 빠른 캐시에 저장하는 기법을 부르는 용어입니다.
[ 캐시 ]
Cache는 본래 CPU 내부의 작은 영역으로, 정말 빈번히 접근하게 되는 데이터를 저장해두는 임시 기억 장치입니다. 기본적으로 데이터를 디스크에 저장하고, 데이터의 빠른 활용을 위해 메모리(RAM)에 저장한다면, 자주 사용하는 휘발성 데이터가 캐시에 저장됩니다.
빈번하게 접근하게 되는 데이터베이스의 데이터를 Redis 의 인메모리 데이터베이스에 저장을 함으로서 데이터를 조회하는데 걸리는 시간과 자원을 감소시키는 기술을 캐싱이라고 합니다.
[ Local Cache vs Global Cache ]
- Local Cache
- 속도: Local Cache는 메모리에서 데이터를 직접 가져오므로 매우 빠른 응답 속도를 제공합니다.
- 범위: 캐시 데이터는 특정 애플리케이션 인스턴스에만 존재합니다. 다른 인스턴스는 이 데이터를 공유하지 않습니다.
- 일관성: 동일한 데이터가 여러 인스턴스에 캐시될 수 있으며, 하나의 인스턴스에서 캐시가 갱신되더라도 다른 인스턴스는 이를 인지하지 못할 수 있습니다. 이는 분산 시스템에서 데이터 일관성 문제를 일으킬 수 있습니다.
- Gloval Cache
- 속도: 네트워크를 통해 캐시에 접근하기 때문에, Local Cache보다 응답 속도가 느릴 수 있습니다.
- 범위: 모든 애플리케이션 인스턴스가 동일한 캐시 데이터를 공유하므로, 하나의 인스턴스에서 캐시가 갱신되면 다른 인스턴스에서도 즉시 반영됩니다.
- 일관성: 글로벌 캐시는 데이터 일관성을 유지할 수 있습니다. 캐시의 갱신은 모든 인스턴스에 반영되므로 데이터의 일관성을 유지하기 쉽습니다.
- 선택 기준
- 속도와 단일 인스턴스의 성능 최적화가 중요한 경우 Local Cache를 사용한다.
- 일관성이 중요하고다중 인스턴스에서 공유할 데이터를 캐시해야 하는 경우 Global Cache를 사용한다.
[ 캐싱 전략 ]
캐시를 구현하고 사용할때는 해당 데이터가 얼마나 자주 사용될 것인가를 고려해야 합니다.
- 캐시 적중(Cache Hit): 캐시에 접근했을 때 찾고 있는 데이터가 있는 경우를 나타냅니다.
- 캐시 누락(Cache Miss): 캐시에 접근했을 때 찾고 있는 데이터가 없는 경우를 나타냅니다.
- 삭제 정책(Eviction Policy): 캐시에 공간이 부족할때 어떻게 공간을 확보하는지에 대한 정책입니다.
캐시에 찾는 데이터가 있을지 없을지는 캐시에 접근하기 전까지는 알기 어렵습니다. 그래서 어떤 데이터를 얼마나 오래 캐시에 보관할지에 대한 전략을 잘 새워, 적중률을 높이고 누락을 최대한 줄여야 합니다.
[ Cache-Aside ]
Lazy Loading이라고도 하며, 데이터를 조회할 때 항상 캐시를 먼저 확인하는 전략입니다. 캐시에 데이터가 있으면 캐시에서 데이터를 반환하고, 없으면 DB에서 데이터를 가져온 뒤 캐시에 저장하고 반환합니다.
- 필요한 데이터만 캐시에 보관됩니다.
- 최초로 조회할 때 캐시를 확인하기 때문에 최초의 요청은 상대적으로 오래 걸립니다.
- 반드시 원본을 확인하지 않기 때문에, 데이터가 최신이라는 보장이 없습니다.
[ Write-Through ]
데이터를 작성할때 항상 캐시에 작성하고, 원본에도 작성하는 전략입니다.
- 캐시의 데이터 상태는 항상 최신 데이터임이 보장됩니다.
- 자주 사용하지 않는 데이터도 캐시에 중복해서 작성하기 때문에, 시간이 오래 걸립니다.
[ Write-Behind ]
캐시에만 데이터를 작성하고, 일정 주기로 원본을 갱신하는 방식입니다.
- 쓰기가 잦은 상황에 데이터베이스의 부하를 줄일 수 있습니다.
- 캐시의 데이터가 원본에 적용되기 전 문제가 발생하면 데이터 소실의 위험성이 존재합니다.
캐싱 전략을 공부하면서 느낌 점은 장점이 있는 만큼 각각의 전략에 따른 단점도 존재하는 것 같다. (음..그래서 전략인가? 🤔)
다음번에는 개념을 넘어 실제로 캐싱을 사용하고 실습해보며 기록을 남기도록 하자!
- Spring Boot 프로젝트에 캐싱 적용하기
😺 GitHub: https://happy-coding.tistory.com/21
'해피 코딩 > Today I Learned' 카테고리의 다른 글
[TIL 11] Chater 1. 과제와 피드백 내용 (0) | 2024.08.15 |
---|---|
[TIL 10] 대규모 스트림 처리 (0) | 2024.08.13 |
[TIL 8] @ManyToOne, @OneToMany 정복하기 (1) | 2024.08.10 |
[TIL 7] 부족한 부분 채워 나가기 (0) | 2024.08.08 |
[TIL 6] 컴퓨터는 죄가 없다, Redis정리 (1) | 2024.08.07 |