Redis 캐싱과 전략

캐시

 

캐시는 데이터나 값을 저장하는 임시 저장소로, 데이터를 더 빠르고 효율적으로 엑세스 할 수 있게 해준다.

•  원본 데이터 접근보다 빠르다.
•  같은 데이터를 반복적으로 접근하는 상황에서 사용하기에 알맞다.
•  인증 세션 값과 같은 잘 변하지 않는 데이터일수록 더 효율적이다.

---

컴퓨터 메모리 계층 구조

 

레이어별로 캐시를 보면 용량은 위로 갈수록 커지고 속도는 밑으로 내려갈수록 빨라진다.

보통 우리가 사용하는 Redis는 Memory 층에 존재한다고 보면 된다.

•  Disk가 제일 느리고 L3 < L2 < L1 순으로 속도가 빠르다.
•  Disk 접근 속도가 SSD 를 쓰고 있지만 Memory에 비하면 속도가 굉장히 차이난다. 그렇기 때문에 Memory에 올려놓고 쓰는 게 Disk 에서 읽어오는 것보다 훨씬 빠르다. 그 대신 용량은 Disk 가 훨씬 크다.

 

---

추상적인 웹 서비스 구조(클라이언트 - 웹 서버 - DB)

 

클라이언트가 웹 서버에 접속하고 요청을 보내면 웹 서버가 DB에 데이터를 읽거나 쓰기 작업을 요청한다.

DB도 사실 내부용 캐시가 있지만 캐시 용량이 Memory 사이즈보다 커지면 당연히 Disk를 사용해야 한다. 

쿼리 결과를 내부적 캐시에 담고 있는데 여러가지 요청을 처리하다 보면 기존에 있던 캐시를 날리고 디스크에서 새로 읽어야 하는 순간이 온다.

그래서 디스크에 접근할 때마다 속도가 굉장히 느려질 수 있다.

---

캐시 구조 및 전략

 

캐싱 전략은 웹 서비스 환경에서 시스템 성능 향상을 기대할 수 있는 중요한 기술이다.

일반적으로 캐시는 메모리(RAM)를 사용하기 때문에 데이터베이스보다 훨씬 빠르게 데이터를 응답할 수 있어 이용자에게 빠르게 서비스를 제공할 수 있다.

 

하지만 기본적으로 RAM의 용량은 커봐야 16~32GB 정도라, 데이터를 모두 캐시에 저장해버리면 용량 부족 현상이 일어나 시스템이 다운될 수 있다.

 

Redis로 캐시를 사용할 때 어떻게 배치할 것인지, 어느 종류의 데이터를 캐시에 저장할지, 얼만큼 데이터를 캐시에 저장할지, 얼마나 오래된 데이터를 캐시에서 제거하는지에 대한 캐싱 전략이 필요하다. 이에 따라 성능에 영향을 끼치기 때문에 상황(데이터 유형, 데이터 액세스 패턴)에 맞게 적절한 전략을 사용해줘야 한다.

•  시스템이 많이 작성하는데 덜 자주 읽는가? ex) 시간 기반 로그
•  데이터를 한번 쓰고 여러 번 읽는가? ex) 사용자 프로필
•  반환되는 데이터는 항상 고유한가? ex) 검색어

캐시를 효율적으로 이용하기 위해서는 캐시에 저장할 데이터 특성도 고려해야 한다.

예를 들어 자주 조회되는 데이터, 결과값이 자주 변동되지 않고 일정한 데이터, 조회하는데 연산이 필요한 데이터를 캐싱해두면 좋다.

 

모바일 게임용 Top-10 리더보드 시스템의 캐싱 전략과 사용자 프로필을 집계하고 반환하는 서비스의 캐싱 전략은 많이 다르다.

올바른 캐싱 전략을 선택하는 것이 성능 향상의 핵심이다. 크게 5가지 캐시 전략을 알아본다.

1.  Look-Aside(Cache-Aside) 읽기 전략
2.  Read-Through 읽기 전략
3.  Write-Around 쓰기 전략
4.  Write-Through 쓰기 전략
5.  Write-Back 쓰기 전략

---

선수 지식

 

 

Cache hit 란?

 

캐시 스토어(redis)에 데이터가 있을 경우 바로 가져옴(빠름)

 

Cache Miss 란?

 

캐시 스토어(redis)에 데이터가 없을 경우 어쩔 수 없이 DB에서 가져옴(느림)

---

캐시의 문제점

 

캐시를 이용하게 되면 반드시 닥쳐오는 문제점이 있는데 바로 데이터 정합성 문제이다.

 

데이터 정합성이란, 어느 한 데이터가 캐시(Cache Store)와 데이터베이스(Data Store) 이 두 곳에서 같은 데이터임에도 불구하고 데이터 정보 값이 서로 다른 현상을 말한다.

쉽게 말하면, 캐시에는 어떤 게시글의 좋아요 갯수가 10개로 저장되어 있는데 데이터베이스에는 7개로 저장되어 있을 경우 정보 불일치가 발생한다.

이전에는 그냥 DB에서 데이터 조회와 작성을 처리하였기 때문에 데이터 정합성 문제가 나타나지 않았지만, 캐시라는 또 다른 데이터 저장소를 이용하기 때문에, 결국 같은 종류의 데이터라도 두 저장소에서 저장된 값이 서로 다를 수 있는 현상이 일어날 수 밖에 없는 것이다.

따라서 적절한 캐시 읽기 전략과 캐시 쓰기 전략을 통해 캐시와 DB간의 데이터 불일치 문제를 극복하면서도 빠른 성능을 잃지 않기 위해 연구할 필요가 있다.

---

1. Look-Aside 읽기 전략 (Lazy Loading)

 

Look-Aside는 앱에서 데이터를 읽는 전략이 많을 때 사용하는 전략이다. 이 구조는 Redis를 캐시로 쓸 때 가장 일반적으로 사용하는 방법이다.

캐시는 찾는 데이터가 없을 때 DB에 직접 조회해서 입력되기 때문에 Lazy Loading이라고 한다.

 

•  Cache Aside 패턴이라고도 불린다.
•  데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는지 우선적으로 확인하는 전략
•  반복적인 읽기와 많은 호출에 적합
•  캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장
•  캐시와 DB가 분리되어 가용되기 때문에 캐시 장애 대비 구성이 되어 있음, 만일 redis가 다운 되더라도 DB에서 데이터를 가져올 수 있어 서비스 자체에는 문제 없음
•  대신 캐시에 붙어있던 connection 이 많다면, redis 가 다운된 순간 순간적으로 DB로 몰려서 부하 발생

 

이 방식은 가장 범용적이며 읽기 요청이 많은 경우에 적합하다. 이 구조는 Redis가 다운되더라도 바로 장애로 이어지지 않고, DB에서 데이터를 가져올 수 있다는 장점이 있다.

그런데 만약 캐시에 많은 커넥션이 붙어있는 상태에서 다운이 발생한다면 동시에 DB로 그 커넥션이 다 붙기 때문에 갑자기 DB 부하가 많이 몰릴 수 있다.

 

Look-Aside 전략을 사용할 때 가장 일반적인 쓰기 전략은 DB에 직접 쓰는 Write-Around 쓰기 전략이다. 이 경우 캐시와 DB의 데이터가 일치하지 않을 수 있다. 이를 해결하기 위해 TTL을 사용하고 TTL이 만료될 때까지는 변경되지 않은 캐시 데이터를 계속 제공한다.

데이터 최신성을 보장해야 하는 경우에는 캐시 entry를 무효화하거나 더 적절한 쓰기 전략(Cache를 거친 쓰기 전략)을 이용해야 한다.

 

과정

 

1.  앱은 데이터를 찾을 때 캐시를 먼저 확인한다.
2.  캐시에 데이터가 있으면 해당 데이터를 읽어오는 작업을 반복한다.
3.  만약 Redis에 해당 키가 존재하지 않는다면 (Cache miss) 앱은 DB에 접근해서 데이터를 집접 가지고 온 뒤 다시 Redis에 저장하는 과정을 거친다. 그래서 동일 데이터에 대한 후속 읽기 결과 Cache Hit 가 된다.

---

2. Read-Through 읽기 전략

 

Read-Through 전략은 데아터를 읽을 때 캐시로만 데이터를 읽어온다. 만약 Cache Miss 가 발생하면 DB에서 해당 데이터를 캐시에 바로 저장한다. 즉 캐시는 앱과 DB 중간에 위치해 앱은 캐시만 바라보게 되고 DB는 캐시만 바라보게 된다.

 

•  캐시에서만 데이터를 읽어오는 전략(inline cache)
•  Look Aside 와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이가 있음
•  데이터를 조회하는데 있어 전체적으로 속도가 느림
•  데이터 조회를 전적으로 캐시에만 의지하므로, redis가 다운될 경우 서비스 이용에 차질이 생길 수 있음
•  캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어날 수 있음
•  읽기가 많은 워크로드에 적합

 

뉴스 기사 읽기와 같이 동일한 데이터가 여러 번 읽기 요청이 되는 경우에 적합하다. 디스크 읽기 비용을 절약할 수 있다.

첫 요청은 항상 Cache Miss가 발생하여 데이터가 로딩된다.

Look-Aside와 다른 점은 읽기에 대한 앱의 관점이다. Look-Aside의 경우 Cache Miss가 나면 앱이 직접 DB에 데이터를 조회하는 반면, Read-Through는 캐시에서 DB에 데이터를 직접 조회하여 로드한다. 그리고 Read-Through는 캐시의 데이터 모델과 DB 데이터 모델이 다를 수 없다.

 

과정

 

1.  앱은 모든 데이터를 캐시로만 읽어온다.
2.  Cache Miss 가 발생한 경우 캐시에서 직접 DB 데이터를 읽어온다.

Read-Through 방식은 Cache Aside 방식과 비슷하지만, Cache Store에 저장하는 주체가 Server인지 또는 Data Store 자체인지에 차이점이 있다. 

이 방식은 직접적인 데이터베이스 접근을 최소화하고 Read에 소모되는 자원을 최소화 할 수 있다.

하지만 캐시에 문제가 발생하였을 경우 이는 바로 서비스 전체 중단으로 빠질 수 있다. 그렇기 때문에 redis와 같은 구성 요소를 Replication 또는 Cluster 로 구성하여 가용성을 높여야 한다.

---

Cache Warming - 데이터 미리 캐싱해두기

 

Look-Aside에서 캐시가 다운되면 다시 새로운 캐시를 투입해야 하고 DB에 새로운 데이터를 넣으면 커넥션은 자연스레 DB로 몰리게 된다. 이러한 경우 초기에 Cache Miss 가 엄청 발생해서 성능 저하가 올 수 있다. 매번 첫 요청에 Cache Miss가 발생하는 Read-Through 도 마찬가지 이다.

 

이럴 때는 캐시로 미리 데이터를 밀어 넣어주는 Cache Warming 작업을 해주면 된다. 실제로 실무에서는 특정 이벤트 상품 오픈 전 해당 상품의 조회수가 몰릴 것을 대비해 상품 정보를 미리 DB에서 캐시로 올려주는 작업을 처리한다고 한다.

 

---

3. Write-Through 쓰기 전략

 

이는 Read-Through와 같다. Write-Through 전략은 DB에 데이터를 저장할 때 먼저 캐시에 기록된 다음 DB에 저장되는 방식이다.

 

•  데이터베이스와 Cache에 동시에 데이터를 저장하는 전략
•  데이터를 저장할 때 먼저 캐시에 저장한 다음 바로 DB에 저장 (모아놓았다가 나중에 저장이 아닌 바로 저장)
•  Read Through 와 마찬가지로 DB 동기화 작업을 캐시에게 위임
•  DB와 캐시가 항상 동기화 되어 있어, 캐시의 데이터는 항상 최신 상태로 유지
•  캐시와 백업 저장소에 업데이트를 같이 하여 데이터 일관성을 유지할 수 있어서 안정적
•  데이터 유실이 발생하면 안 되는 상황에 적합
•  자주 사용되지 않는 불필요한 리소스 저장
•  매 요청마다 두번의 Write가 발생하게 됨으로써 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈 발생
•  기억장치 속도가 느릴 경우, 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능 감소

 

캐시는 항상 최신 정보를 가지고 있고 DB와 동기화되어 데이터 일관성을 보장한다는 장점이 있지만 저장 할 때 마다 두 단계 스템(앱 -> Redis -> DB)을 거쳐야 하기 때문에 추가 쓰기 시간이 발생하여 상대적으로 느리다는 단점이 있다. 

그리고 저장하는 데이터가 재사용하지 않을 수도 있는데 무조건 캐시에 넣는 것은 리소스 낭비이다.

 

따라서 이렇게 데이터를 저장할 때에는 얼마 동안만 캐시에 보관하고 있겠다는 TTL을 설정해주는 것이 좋다.

 

과정 

 

1.  앱은 모든 데이터를 캐시에 저장한 후 DB에 저장한다.

Read-Through 캐시와 함께 사용하면 Read-Through의 모든 이점을 얻을 수 있고, 데이터 일관성도 보장되어 캐시 무효화 기술을 사용하지 않아도 된다.

 

AWS의 DynamoDB Accelerator(DAX)가 Read-Through와 Write-Through를 함께 사용한 좋은 예이다. 이는 DynamoDB와 앱이 인라인으로 배치된다. 그래서 DynamoDB에 대한 읽기 쓰기는 DAX를 통해 수행할 수 있다.

 

그런데 만약 캐시 전략을 잘못 조합하면 성능이 안좋아진다. 예를 들어 실시간 로그를 기록하는 시스템에서 Read-Through / Write-Through 전략을 사용한다면 자주 읽지도 않는 데이터가 캐시에 적재되기 때문에 리소스 낭비가 발생하게 된다. 이러한 경우에는 Read-Through / Write-Through 전략을 사용하는게 적합하다.

 

Write Through 패턴은 Cache Store에도 반영하고 Data Store에도 동시에 반영하는 방식이다. (Write Back 은 일정 시간을 두고 나중에 한꺼번에 저장)

그래서 항상 동기화가 되어 있어 최신정보를 가지고 있다는 장점이 있다.

하지만 결국 저장할 때마다 2단계 과정이 거쳐지기 때문에 상대적으로 느리며, 무조건 일단 Cache Store에 저장하기 때문에 캐시에 넣은 데이터를 저장만 하고 사용하지 않을 가능성이 있어서 리소스 낭비 가능성이 있다.

 

---

4. Write-Around 쓰기 전략

 

Write-Around 전략은 DB에만 데이터를 저장하고 읽은 데이터만 캐시에 저장하는 방식이다. 

일단 모든 데이터는 DB에 저장되고 Cache Miss 가 발생 한 경우에만 DB에서 캐시로 데이터를 끌어오게 된다.

 

•  Write Through 보다 훨씬 빠름
•  모든 데이터는 DB에 저장 (캐시를 갱신하지 않음)
•  Cache miss가 발생하는 경우에만 DB와 캐시에도 데이터를 저장
•  따라서 캐시와 DB 내의 데이터가 다를 수 있음(데이터 불일치)

 

자주 읽히지 않는 데이터는 캐시에 로드되지 않으니 리소스를 절약할 수 있다.

그러나 캐시 내의 데이터와 DB내의 데이터가 다를 수 있다는 단점이 있다. ex) 캐시에 이미 로드된 데이터를 수정할 경우

 

과정

 

1.  앱은 모든 데이터를 DB에 저장한다.
2.  Cache Miss 가 발생한 경우에만 DB에서 캐시로 데이터를 저장한다.

그래서 Write-Around는 데이터가 한 번 쓰여지고 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공할 수 있다.

이 경우 읽기 전략은 크게 상관 없다. (Read-Through나 Look-Aside와 모두 결합 가능)

 

실시간 로그나 채팅방 메시지에 사용된다.

 

Write Around 패턴은 속도가 빠르지만, Cache miss 가 발생하기 전에 데이터베이스에 저장된 데이터가 수정되었을 때, 사용자가 조회하는 캐시와 데이터베이스 간의 데이터 불일치가 발생하게 된다.

따라서 데이터베이스에 저장된 데이터가 수정, 삭제 될 때마다, 캐시또한 삭제하거나 변경해야하며, 캐시의 expire를 짧게 조정하는 식으로 대처해야 한다.

 

---

5. Write-Back 쓰기 전략

 

Write-Back 전략은 쓰기 작업을 먼저 저장했다가 특정 시점마다 DB에 저장하는 방식이다. 디스크 기반 DB로 치면 데이터를 굉장히 많이 써야 되기 때문에 무조건 디스크에 저장해야 하는 상황에서 주로 사용한다.

매번 디스크 쓰기를 실행하면 시간이 오래 걸리기 때문에 캐시에 저장해 두었다가 묶음으로 디스크 쓰기 작업을 실행해주는 것이다.

 

•  Write Behind 패턴이라고도 불림
•  캐시와 DB 동기화를 비동기하기 때문에 동기화 과정이 생략
•  데이터를 저장할 때 DB에 바로 쿼리하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영
•  캐시에 모아놨다가 DB에 쓰기 때문에 쓰기 쿼리 회수 비용과 부하를 줄일 수 있다.
•  Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
•  데이터 정합성 확보
•  자주 사용되지 않는 불필요한 리소스 저장
•  캐시에서 오류가 발생하면 데이터를 영구 소실함

 

쓰기가 많은 경우에 적합하다. DB 디스크 쓰기 비용을 절약할 수 있다. 그리고 특정 시점에만 DB에 쓰기 요청을 하기 때문에 DB 오류에도 탄력적이다.

바꿔서 생각해보면 데이터를 캐시에 모아 뒀다가 DB에 옮기기 때문에 도중 캐시에 장애가 발생하면 데이터 유실이 크게 발생할 수 있다.

 

대부분 RDB 스토리지 엔진 내부에는 Write-Back 캐시 기능을 가지고 있다. 쿼리는 먼저 메모리에 기록되다가 특정 시점에 한 번에 Disk 에 flush 된다.

 

과정 

 

1.  앱은 모든 데이터를 캐시에 저장한다.
2.  특정 시점이 되면 캐시에 저장된 데이터를 DB에 저장한다.
3.  그렇게 DB에 저장된 데이터는 캐시에서 삭제해준다.

Write-Back은 Read-Through와 결합하면 가장 최근 업데이트되고 액세스 된 데이터를 항상 캐시에 사용할 수 있다.

 

데이터를 저장할때 DB가 아닌 먼저 캐시에 저장하여 모아놓았다가 특정 시점마다 DB로 쓰는 방식으로 캐시가 일종의 Queue 역할을 겸하게 된다.

캐시에 데이터를 모았다가 한 번에 DB에 저장하기 때문에 DB 쓰기 횟수 비용과 부하를 줄일 수 있지만, 데이터를 옮기기 전에 캐시 장애가 발생하면 데이터 유실이 발생할 수 있다는 단점이 존재한다.

오히려 반대로 데이터베이스에 장애가 발생하더라도 지속적인 서비스를 제공할 수 있도록 보장한다.

 

이 전략 또한 캐시에 Replication이나 Cluster 구조를 적용함으로써 Cache 서비스의 가용성을 높이는 것이 좋으며, 캐시 읽기 전략인 Read-Through와 결합하면 가장 최근에 업데이트된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합하다.

 

---

조합

 

1. LookAside + Write Around 조합

일반적으로 자주 쓰임

 

 

2. Read Through + Write Around 조합

항상 DB에 쓰고, 캐시에서 읽을 때 항상 DB에서 먼저 읽어오므로 데이터 정합성 이슈에 대한 완벽한 안전장치를 구성할 수 있음

 

3. Read Through + Write Through 조합

데이터를 쓸 때 항상 캐시에 먼저 쓰므로, 읽어올 때 최신 캐시 데이터 보장

데이터를 쓸 때 항상 캐시에서 DB로 보내므로, 데이터 정합성 보장

 

---

캐시 저장 방식 지침

 

캐시 솔루션은 자주 사용되면서 변경되지 않는 데이터의 경우 캐시 서버에 적용하여 반영할 경우 높은 성능 향상을 이뤄낼 수 있다. 이를 Cache Hit Rating 이라고 한다.

 

일반적으로 캐시는 메모리에 저장되는 형태를 선호한다.

메모리 저장소로는 대표적으로 Redis와 MemCached가 있으며 이와 같은 솔루션은 메모리를 1차 저장소로 사용하기 때문에 디스크와 달리 제약적인 저장 공간을 사용하게 된다.

 

많아야 수십기가 정도의 저장소를 보유하게 되며, 이는 결국 자주 사용되는 데이터를 어떻게 뽑아 캐시에 저장하고 자주 사용하지 않는 데이터를 어떻게 제거해 나갈 것이냐를 지속적으로 고민해야 할 필요성이 있다.

 

따라서 캐시를 저장하는 시점은 자주 사용되며 자주 변경되지 않는 데이터를 기준으로 하는 것이 좋다.

 

언제든지 데이터가 날라갈 수 있는 휘발성으로 기본으로 한다는점을 고민해야 한다.

데이터를 주기적으로 디스크에 저장함으로서 어느정도 해결을 할 수는 있지만, 실시간으로 모든 데이터를 디스크에 저장할 경우 성능 저하를 일으 킬 수 있어 어느정도 데이터 수집과 저장 주기를 가지도록 설계해야 한다.

즉 데이터의 유실 또는 정합성이 일정부분 깨질 수 있다는 점을 항상 고려해야 한다.

 

따라서 캐시에 저장되는 데이터는 중요한 정보, 민감 정보 등은 저장하지 않는 것이 좋으며, 캐시 솔루션이 장애가 발생했을 경우 적절한 대응 방안을 모색해 두는 것이 바람직 하다. (TimeOut, 데이터 베이스 조회 병행 등)

 

---

캐시 제거 방식 지침

 

캐시 데이터의 경우 캐시 서버에만 단독으로 저장되는 경우도 있지만, 대부분 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많다.

이는 2차 저장소(영구 저장소)에 저장되어 있는 데이터와 캐시 솔루션의 데이터를 동기화 하는 작업이 반드시 필요함을 의미하며, 개발 과정에 고려사항이 늘어난다는 점을 반드시 기억해야한다.

예를 들어 캐시 서버와 데이터베이스에 저장되는 데이터의 commit 시점에 대한 고려 등이 예가 될 수 있다.

캐시의 만료 정책이 제대로 구현되지 않은 경우 클라이언트는 데이터가 변경되었음에도 오래된 정보가 캐싱되어 있어 오래된 정보를 사용할 수 있다는 문제점이 발생한다.

 

따라서 캐시를 구성할 때 기본 만료 정책을 설정해야한다.

캐시된 데이터가 기간 만료되면 캐시에서 데이터가 제거되고, 응용 프로그램은 원래 데이터 저장소에서 데이터를 검색해야 한다.

그래서 캐시 만료 주기가 너무 짧으면 데이터는 너무 빨리 제거되고 캐시를 사용하는 이점은 줄어든다.

반대로 너무 기간이 길면 데이터가 변경될 가능성과 메모리 부족 현상이 발생하거나, 자주 사용되어야 하는 데이터가 제거되는 등의 역효과를 나타낼 수도 있다.

 

---

Cache Stampede 현상

 

대규모 트래픽 환경에서 TTL 값이 너무 작게 설정하면 cache stampede 현상이 발생할 수 있다.

Look-aside 패턴에서 redis에 데이터가 없다는 응답을 받은 서버(캐시 미스)가 직접 DB로 데이터 요청한 뒤, 다시 redis 에 저장하는 과정을 거친다.

그런데 위 상황에서 key가 만료(Key Expires)되는 순간 많은 서버에서 이 key를 같이 보고 있었다면 모든 어플리케이션 서버에서 DB로 가서 찾게 되는 duplicate read 가 발생한다.

또 읽어온 값을 각각 redis 에 쓰는 duplicate write도 발생되어, 처리량도 다 같이 느려질 뿐 아니라 불필요한 작업이 굉장히 늘어나 요청량 폭주로 장애로 이어질 가능성도 있다.

 

---

캐시 공유 방식 지침

 

캐시는 애플리케이션의 여러 인스턴스에서 공유하도록 설계되었다.

그래서 각 애플리케이션 인스턴스가 캐시에서 데이터를 읽고 수정할 수 있다.

따라서 어느 한 애플리케이션이 캐시에 보유하는 데이터를 수정해야 하는 경우, 애플리케이션의 한 인스턴스가 만드는 업데이트가 다른 인스턴스가 만든 변경을 덮어쓰지 않도록 해야한다.

그렇지 않으면 데이터 정합성 문제가 발생하기 때문이다. (각 애플리케이션마다 표시되는 갯수가 달라지는 현상)

데이터 충돌을 방지하기 위해 다음과 같은 애플리케이션 개발 방식을 취해야한다.

 

먼저, 캐시 데이터를 변경하기 직전에 데이터가 검색된 이후 변경되지 않았는지 일일히 확인하는 방법이다.

변경되지 않았다면 즉시 업데이트하고 변경되었다면 업데이트 여부를 애플리케이션 레벨에서 결정하도록 수정해야한다.

이와 같은 방식은 업데이트가 드물고 충돌이 발생하지 않는 상황에 적용하기 용이하다.

 

두번째로, 캐시 데이터를 업데이트 하기 전에 Lock을 잡는 방식이다.

이와 같은 경우 조회성 업무를 처리하는 서비스에 Lock으로 인한 대기현상이 발생한다.

이 방식은 데이터의 사이즈가 작아 빠르게 업데이트가 가능한 업무와 빈번한 업데이트가 발생하는 상황에 적용하기 용이하다.

---

캐시 가용성 지침

 

캐시를 구성하는 목적은 빠른 성능 확보와 데이터 전달에 있으며, 데이터의 영속성을 보장하기 위함이 아니라는 점을 기억하고 설계해야 한다.

데이터의 영속성은 기존 데이터 스토어에 위임하고, 캐시는 데이터 읽기에 집중하는 것이 성능 확보의 지침 사항이 될 수 있다.

또한 캐시 서버가 장애로 인해 다운되었을 경우나 서비스가 불가능할 경우에도 지속적인 서비스가 가능해야 한다.

이는 캐시에 저장되는 데이터는 결국 기존 영구 데이터 스토어에 동일하게 저장되고 유지된다는 점을 뒷받침하는 설계 방식이다. (Write Through)

 

즉, 캐시 서버가 장애로 부터 복구되는 동안 성능상의 지연은 발생할 수 있지만, 서비스가 불가능한 상태가 되지 않도록 고려해야 한다는 말이다.

---

참고링크

 

https://loosie.tistory.com/800

[DB] 캐싱과 캐싱 전략에 대해 알아보자

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EC%BA%90%EC%8B%9CCache-%EC%84%A4%EA%B3%84-%EC%A0%84%EB%9E%B5-%EC%A7%80%EC%B9%A8-%EC%B4%9D%EC%A0%95%EB%A6%AC

[REDIS] 📚 캐시(Cache) 설계 전략 지침 💯 총정리

https://waspro.tistory.com/697

Redis5 설계하기 총정리

https://sabarada.tistory.com/103

[Redis] 캐시(Cache)와 Redis