캐시 시스템의 주요 성능 측정 지표
캐싱 시스템의 효율성과 성능을 향상시키기 위해서는 다양한 지표를 모니터링하는 것이 매우 중요합니다.
이를 통해 캐싱 시스템에 관한 중요한 비즈니스 결정을 내릴 수 있습니다.
캐시 적중률(hit ratio)
요청된 항목이 캐시에서 사용된 비율을 측정합니다.
캐시 적중률이 높을수록 캐시에서 더 많은 데이터가 제공되어, 외부 저장소에 액세스 할 필요성을 줄어들고 성능이 향상됩니다.
아래의 성능 지표를 모니터링한다면, 우리는 캐싱 시스템을 최적화하여 더 높은 처리량과 낮은 대기 시간을 달성할 수 있습니다.
지연 시간(latency)
데이터에 액세스하는 데 걸리는 시간을 의미합니다.
캐싱 시스템에서 낮은 대기 시간은 데이터가 더 빠르게 제공되는 것을 의미하여 전반적인 성능을 향상시킵니다.
처리량(throughput)
주어진 시간 동안 처리할 수 있는 데이터의 양을 측정합니다.
처리량이 높은 캐싱 시스템은 더 많은 요청을 처리하고 더 많은 데이터를 제공할 수 있어 전반적인 성능을 향상시킵니다.
캐시 크기(size)
캐시에 할당된 메모리 또는 저장소의 크기를 나타냅니다.
캐시 크기는 캐시 적중률과 미스율에 영향을 줄 수 있습니다. 캐시 크기가 크면 적중률이 높을 수 있지만, 캐싱 솔루션의 비용과 복잡성을 증가시킬 수도 있습니다.
캐시 미스율(miss rate)
요청된 항목이 캐시에서 찾을 수 없어 외부 저장소에서 가져와야 하는 비율을 측정합니다.
미스율이 높을수록 캐시가 아닌 외부 저장소에서 더 많은 데이터를 가져오기 때문에 성능이 저하됩니다.
읽기 중심의 애플리케이션 캐싱 시스템 설계
방법1) Cache-Aside 캐시 별도 관리
과정
1. 어플리케이션에 요청이 들어올 때마다 먼저 캐시에서 요청된 데이터를 질의
2. if 캐시에 데이터가 있으면 데이터 반환
3. else 캐시에 데이터가 없으면, 어플리케이션에서 DB에 데이터를 질의한 후 캐시 업데이트 후 데이터 반환
장점
가장 쉬운 전략으로 맨처음만 느리고 다음부터는 빠르다. (lazy loading)
단점
한번의 캐시 miss는 세번의 처리과정을 거치므로 이로 인한 지연이 발생할 수 있다.
키가 만료되었을 때 동시요청으로 DB에 동일한 데이터를 여러번 질의할 수 있다.
--> 일반적으로 다른 전략과 함께 사용된다.
방법2) Read-Through 캐시 통해서 읽기
누가 책임을 가지느냐만 다르지 cache-aside와 비슷하다
과정
1. 쿼리가 발생하면 어플리케이션은 캐시에 데이터를 질의한다.
2. if 캐시에 데이터가 없으면, 캐시는 DB에서 데이터를 질의하고 캐시 업데이트
3. 캐시는 데이터 반환
장점
캐시가 DB로 하나의 쿼리만 보내도록 보장한다.
단점
데이터 요청 로직을 캐시로 이동시킴으로서 어플리케이션 코드 단순화
방법 3) Refresh-Ahead 캐시 미리 갱신
과정
1. 캐시 만료시간이 60초이고 refresh-ahead 요소가 0.5일 때
2. 캐시된 데이터가 60초 후에 엑세스되면 coherence는 캐시 스토에에서 동기적으로 읽기 작업을 수행하여 해당 값을 갱신한다.
3. if 캐시된 데이터가 30초 이후인 35초 후에 엑세스되면, 캐시는 데이터를 반환하고 비동기적으로 데이터를 갱신한다.
단점
데이터를 갱신하는데 네트워크 지연으로 인해 시간이 소요될 수 있다.
쓰기 중심의 애플리케이션 캐싱 시스템 설계
방법1) Write-Through 캐시 통해서 쓰기
과정
1. 애플리케이션은 캐시에 직접 데이터를 쓴다.
2. 캐시는 데이터를 주 DB에 업데이트한다. 쓰기 작업이 완료되면 캐시와 DB는 동일한 값을 갖게 되며 캐시는 항상 일관성을 유지한다.
장점
Read-Through와 함께 사용되면 네트워크 호출에서 매우 효과적이다. 캐시에 데이터가 먼저 읽혀지거나 쓰여지기 때문에 캐시 무효화가 거의 발생하지 않는다.
자주 액세스되는 데이터인 경우 해당 전략이 유리하다.
방법2) Write-behind 쓰고 나서 캐시
과정
Write-Through와 매우 유사하지만 DB 쓰기가 비동기적으로 이루어진다.
1. 일단 캐시에 데이터를 쓰고
2. 비동기로 DB에 천천히 데이터를 쓴다.
장점
쓰기 성능을 향상시킬 수 있다. 대량의 쓰기 작업이 있는 워크로드에서 가장 이상적인 방법이다.
Read-Through와 함께 사용하는 혼합 워크로드에서 적합한 캐시전략이다.
배치 호출을 사용하면 DB로의 전체 쓰기 작업을 줄여 부하를 감소하고 비용을 절감할 수 있다. ex) DynamicDB와 같은 요청횟수에 따라 요금을 부과하는 DB에 이접이 있다.
단점
DB가 느려지면 캐시와의 시간차가 생기고, 캐시가 죽으면 DB에 쓰지 못한 데이터가 날아갈 수 있다.
방법3) Write-Around 캐시 나중에 쓰기
과정
1. 쓰기 요청이 오면 애플리케이션은 DB에서 레코드를 업데이트한다.
2. DB는 캐시에서 키를 비동기적으로 업데이트하거나 삭제한다.
장점
Read-Through와 결합하여 데이터가 한번 쓰여지고 자주 또는 전혀 읽히지 않는 상황에서 좋은 성능을 제공한다. ex) 실시간 로그, 채팅룸 메시지
Cache-Aside와도 결합할 수 있다.
단점
DB에 쓰고 캐시에 쓰는 사이에 예전 데이터가 노출될 수 있다. (시간차 발생)
참고
'DATA > Redis' 카테고리의 다른 글
Redis vm 생성, AWS EC2 설치 (0) | 2023.08.06 |
---|---|
Memcache 와 Redis 비교 (0) | 2023.08.04 |
Redis 사용시 주의사항 (0) | 2023.03.09 |
Redis - Serialize, Unserialize 란? 직렬화 저장의 단점 (0) | 2022.12.29 |
Redis data types 자료구조 유형 (0) | 2022.12.29 |
댓글