0. Redis - Cache전략이란?
웹 서비스 환경에서 시스템 성능 향상을 기대할 수 있는 중요한 기술.
캐시는 메모리(RAM)을 사용하기 때문에 데이터베이스 보다 훨씬 빠르게 데이터를 응답할 수 있다.
Redis 기본 동작
- 인 메모리 데이터베이스이지만, 디스크에 백업이 가능하다.
- 기본적으로 인메모리 데이터베이스는 휘발성이므로 서버가 꺼지면 데이터가 유실되지만, Redis는 디스크에 데이터를 백업하고 다시 읽어서 메모리에 로드하는 기능을 제공한다.
기본적으로 RAM의 용량이 16~32G정도라, 데이터를 모두 캐시에 저장해 버리면 용량부족 현상이 일어나 시스템이 다운될수 있기 때문에
- 어느 종류의 데이터를 캐시에 저장할지
- 얼만큼 데이터를 캐시에 저장할지
- 얼마동안 오리된 데이터를 캐시에서 제거하는지
에 대한 지침전략이 필요하다.
캐시를 효율적으로 이용하기 위해서는 캐시에 저장할 데이터 특성을 고려해야한다.
자주 조회되는 데이터, 결과 값이 자주 변동되지 않고 일정한 데이터, 조회하는데 연산이 필요한 데이터를 캐싱해두면 좋다.
1. Cache Hit & Cache Miss
1) Cache hit
- 캐시 스토어(redis)에 데이터가 있을 경우 바로 가져옴(빠름)
2) Cache Miss
- 캐시 스토어(redis)에 데이터가 없을 경우 어쩔 수 없이 DB에서 가져옴(느림)
2. 캐싱 전략 패턴 종류
캐싱을 사용하다보면 데이터 정합성의 문제에 부딪히게 된다.
DB에서 바로 데이터를 불러오는 것과 캐싱된 데이터를 가져와도 같은 종류의 데이터여도 저장된 값이 서로 다를 수 있는 현상이 일어난다.
따라서 적절한 캐시 읽기 전략(Read Cache Strategy)과 캐시 쓰기 전략(Write Cache Strategy)을 통해, DB간의 데이터 불일치 문제를 극복하면서도 빠른 성능을 잃지 않기위해 고심해야한다!!!!
1) 캐시 읽기 전략(Read Cache Strategy)
Look Aside 패턴
- 데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는지 확인하는 전략.
캐시에 데이터가 없으면 DB에서 조회 - 반복적인 읽기가 많은 호출에 적합
✔️장점
- 캐시와 DB가 분리되어 가용되기 떄문에 원하는 데이커만 별도로 구성하여 캐시에 저장
- 캐시와 DB가 분리되어 가용되기 때문에 캐시 장애 대비 구성이 되어있다.
(redis가 다운되더라도 DB에서 데이터를 가져올 수 있어 서비스 자체는 문제가 없다)
✔️단점
⭐캐시에 붙어있던 connection이 많았다면 redis가 다운된 순간 DB로 몰려 부하발생.
- 캐시 장애로 인한 서비스문제는 대비할 수 있으나 Cache Store와 Data Store간 정합성 유지 문제가 발생할 수 있어 초기조회 시 무조건 Data Store를 호출(Lazy Loading)해야 하므로 단건 호출 빈도가 높은 서비스에 적합하지 않다.
- 반복적으로 동일 쿼리를 수행하는 서비스에 적합.
때문에 캐시로 데이터를 미리 넣어주는 작업인 Cache Warming이라고 한다.
Read Through 패턴
- 캐시에서만 데이터를 읽어오는 전략임.
- Look Aside와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 점에서 차이가 있음.
- 직접적인 데이터베이스 접근을 최소화하고 Read에 대한 소모되는 자원을 최소화 할 수 있음.
- 캐시에 문제가 발생하였을 경우 서비스 전체 중단으로 빠질 수 있으므로 redis와 같은 구성요소를 Replication또는 Cluster로 구성하여 가용성을 높여야 한다.
✔️ 장점
- DB와 캐시간의
데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어날 수 있음
✔️ 단점
-
데이터 조회하는데 전체적으로 속도가 느림
-
redis가 다운될 경우 서비스 이용에 차질생길수 있음.
-
읽기가 많은 워크로드에 적합..
Refresh Ahead
- 캐시된 데이터는 일정 기간이 지나면 만료되기때문에 만료된 키를 요청하면 miss발생, DB에 접근해야 하므로 대기 시간이 길어짐.
- 가까운 장래에 요청될 것으로 예상되는 데이터에 대해, 데이터가 expired되기 전에 캐시 데이터를 리프레시 함.
2) 캐시 쓰기 전략(Write Cache Strategy)
Write Back(= Write Behind) 패턴
- 캐시와 DB동기화를 비동기하기 때문에 동기화 과정이 생략.
- 데이터를 저장할 때 DB에 바로 쿼리하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영.
✔️ 장점
- 캐시에 모아놨다가 DB에 쓰기 때문에 쓰기 쿼리 회수 비용과 부하를 줄일 수 있음
- 데이터 정합성 확보.
- 데이터베이스에 장애가 발생하더라도 지속적인 서비스를 제공할 수 있도록 보장하기도함.
✔️단점
-
자주 사용되지 않는 불필요한 리소스 저장.
-
캐시에 데이터를 모았다가 한 번에 DB에 저장하므로 DB쓰기 횟수 비용과 부하를 줄일 수 있지만 데이터를 옮기기 전에 캐시 장애가 발생하면 데이터 유실이 발생할 수 있다.
-
Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합..
Write Through 패턴
- 데이터베이스와 Cache에 동시에 데이터를 저장하는 전략
- 데이터를 저장할 때 먼저 캐시에 저장한 다음 바로 DB에 저장.
- Read Through와 마찬가지로 DB동기화 작업을 캐시에 위임.
✔️장점
- DB와 캐시가 항상 동기화 되어있어, 캐시의 데이터는 항상 최신 상태로 유지
- 데이터 일관성을 유지
✔️단점
-
자주 사용되지 않는 불필요한 리소스 저장.
-
매 요청마다 두 번의 Write가 발생하게 되어 빈번한 생성, 수정이 발생하는 서비스에서는 성능이슈 발생.
-
기억장치 속도가 느릴 경우, 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능감소.
-
데이터 유실이 발생하면 안 되는 상황에 적합..
⭐
Write Through패턴과Read Through패턴을 함께 사용하면, 캐시의 최신 데이터 유지와 정합성 이점을 얻을 수 있다.
ex) AWS의 DynamoDB Accelerator(DAX)
Write Around 패턴
- 모든 데이터는 DB에 저장(캐시를 갱신 x)
- Cache Miss가 발생하는 경우에만 DB와 캐시에도 데이터를 저장
✔️장점
- Write Through보다 훨씬 빠름
✔️단점
- 캐시와 DB 내의 데이터가 다를 수 있음(데이터 불일치)
👉🏻해결법 : 데이터베이스에 저장된 데이터가 수정, 삭제될 때마다, Cache 또한 삭제하거나 변경해야하고 Cache의 expire를 짧게 조정하는 식으로 대처 필요.
- 데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공
Look Aside, Read Through와 결합해서 사용된다.
3. 캐시 읽기 + 쓰기 전략 조합
1) Look Aside + Write Around 조합
- 가장 일반적으로 자주 쓰이는 조합
2) Read Through + Write Around 조합
- 항상 DB에 쓰고, 캐시에서 읽을 때 항상 DB에서 먼저 읽어오므로 데이터 정합성 이슈에 완벽한 안전 장치를 구성할 수 있음.
3) Read Through + Write Through 조합
- 데이터를 쓸 때 항상 캐시에 먼저 쓰므로, 읽어올 때 최신 캐시 데이터 보장
- 데이터를 쓸 때 항상 캐시에서 DB로 보내므로, 데이터 정합성 보장
4. 캐시 저장 방식 지침
Cache Hit Rating
자주 사용되면서 자주 변경되지 않는 데이터의 경우 캐시 서버에 적용하여 반영할 경우 높은 성능 향상을 이뤄낼 수 있다.
-
캐시는 메모리에 저장되는 형태를 선호함.
-
캐시를 저장하는 시점은 자주 사용되며 자주 변경되지 않는 데이터를 기준 으로 하는 것이 좋다.
-
언제든지 데이터가 날라갈 수 있는 휘발성을 기본으로 한다.
"데이터를 주기적으로 디스크에 저장함으로서 어느정도 해결을 볼 수 있지만, 실시간으로 모든 데이터를 디스크에 저장할 경우 성능저하를 일으킬 수 있어 어느정도 데이터 수집과 저장 주기를 가지도록 설계해야함."
-
캐시에 저장되는 데이터는 중요한 정보, 민감 정보등은 저장하지 않는 곳이 좋음.
5. 캐시 공유 방식 지침
- 캐시는 애플리케이션의 여러 인스턴스에서 공유하도록 설계됨.
- 한 애플리케이션이 캐시에 보유하는 데이터를 수정해야 하는 경우, 애플리케이션의 한 인스턴스가 만드는 업데이트가 다른 인스턴스가 만든 변경을 덮어쓰지 않도록 해야함. >> 그렇지 않으면 정합성 문제가 발생함.
데이터 충돌을 방지하기 위해선?
1. 캐시 데이터를 변경하기 직전에 데이터가 검색된 이후 변경되지 않았는지 일일히 확인 : 변경되지 않았다면 즉시 업데이트 하고 변경되었다면 업데이트 여부를 애플리케이션 레벨에서 결정하도록 수정 필요.
👉🏻 업데이트가 드물고 충돌이 발생하지 않는 상황에 적용하기 용이
2. 캐시 데이터를 업데이트 하기 전에 Lock을 잡는 방식
: 조회성 업무를 처리하는 서비스에 Lock으로 인한 대기현생이 발생.
👉🏻 데이터의 사이즈가 작아 빠르게 업데이트가 가능한 업무와 빈번한 업데이트가 발생하는 상황에 적용하기 용이.
6. 캐시 가용성 지침
캐시를 구성하는 목적은
⭐빠른 성능 확보와 데이터 전달!⭐ / 데이터의 영속성 보장❌
- 캐시 서버가 장애로 인해 다운되었을 경우나 서비스가 불가능할 경우에도 지속적인 서비스가 가능해야함.
- 캐시 서버가 장애로 부터 복구되는 동안 성능상의 지연은 발생할 수 있으나, 서비스가 불가능한 상태가 되지 않도록 고려해야한다.
- 시스템이 읽기 작업 위주인지, 쓰기 작업 위주인지
- 반환되는 데이터는 항상 고유한지
- 어떤 종류의 데이터를 저장할지
- 높은 처리량을 요구하는지
7. Redis성능에 영향을 미치는 요인
- 네트워크 대역폭 및 홉 수 - CPU보다 큰 영향 미침
- VM의 경우 더 느림
- RAM속도와 메모리 대역폭 > 크게 좌우하지 x
- ⭐CPU : 매우 중요. 단일 스레드인 Redis는 캐시가 많고 코어가 많지 않은 CPU를 선호함.
- 이더넷 네트워크를 사용하여 redis에 액세스 할 경우, 이더넷 패킷 크기 미만으로 유지될 때 효율적
- 클라이언트 연결 수 : 300000개의 연결은 100개의 연결에 비해 처리량이 절반으로 감소.
[REDIS] 📚 캐시(Cache) 설계 전략 지침 💯 총정리
[Redis] 캐시 전략, Redis 아키텍처
