Redis 캐시 전략에 대해서 - 웹 서비스를 위한 레디스 캐시 전략과 RDBMS와 동기화를 어떻게 할 것인가?

Redis는 메모리 기반의 NoSQL 데이터베이스로, 데이터베이스보다 빠른 데이터 처리 속도를 제공합니다. 이를 활용하여 웹 서비스 환경에서 시스템 성능 향상을 기대할 수 있습니다. 캐시는 메모리(RAM)를 사용하여 데이터베이스보다 빠르게 데이터를 응답할 수 있어 이용자에게 빠른 서비스를 제공할 수 있습니다.

오늘은 실제 웹 서비스에서 Redis를 어떻게 활용하고 어떤 캐시 전략을 어떻게 가져갈 수 있는지 알아보겠습니다. 

1. Redis 캐시 

mysql이나 postgresql과 같은 디스크 기반의 RDBMS를 사용하다보면 성능이 문제가 되는 경우가 종종 있습니다. 

처음에는 잘 운영되다가 사용자가 늘어 부하가 몰리게 되면 더이상 mysql이나 postgresql로는 성능의 한계가 오기도 합니다. 

캐시는 자주 사용하는 데이터를 미리 복사해 놓는 임시 저장 공간입니다. 캐시는 일반적으로 저장 공간이 작고 비용이 비싸지만, 빠른 성능을 제공합니다. 주로 접근 시간이 긴 데이터나 반복적으로 동일한 결과를 반환하는 경우에 사용됩니다.

Redis는 메모리 기반의 저장소로 디스크 기반의 mysql이나 postgresql과 같은 RDBMS의 캐시로 많이 사용됩니다. 

캐시는 다음과 같은 이유로 사용됩니다. 

• DBMS 부하 감소: 캐시를 사용하면 데이터베이스에 대한 반복적인 요청을 줄일 수 있어 DBMS의 부하를 감소시킬 수 있습니다.
• 성능 향상: 캐시에 저장된 데이터는 메모리에 있기 때문에 디스크나 데이터베이스에 접근하는 것보다 빠르게 접근할 수 있습니다. 

캐시는 일반적으로 캐시 미스 상황에서 데이터를 로딩하는 형태로 사용됩니다. 

cache hit : redis 캐시에 데이터가 있으므로 빠르게 접근
cache miss : redis 캐시에 데이터가 없으므로 DB에 접근해서 가져오므로 느림

 

아래 그림은 웹 서버가 app으로 부터 요청을 받아 데이터를 redis cache 혹은 database에서 가져오는 것을 보여줍니다. 

붉은색은 cache hit로 한번에 레디스에서 가져오는 경우를 보여주며, 파란색은 캐시에서 데이터를 찾지 못해서 cache miss로 mysql 데이터베이스로부터 다시 접근하는 상황을 보여줍니다. 

Redis 캐시 전략이란? 

웹 서비스를 개발하면서 Redis를 DBMS의 캐시로 활용하는 경우, 효율적인 캐시 전략을 수립하는 것이 매우 중요합니다.

이 때 고려해야할 것들은 다음과 같은 것들이 있습니다. 

1. 캐시 대상 선정

캐시 대상을 선정할 때, 자주 조회되는 데이터나 데이터베이스 부하를 줄일 수 있는 데이터를 중점적으로 선택합니다. 예를 들어, 인기 상품 목록, 사용자 프로필 정보, 정적 콘텐츠 등을 캐시 대상으로 고려할 수 있습니다.

2. 캐시 키 설계

캐시 키를 설계할 때, 데이터를 고유하게 식별할 수 있는 방법을 선택합니다. 데이터베이스의 주요 키나 유니크한 식별자를 활용하여 적절한 캐시 키를 정의합니다. 또한, 캐시 키의 네이밍 규칙을 일관성 있게 유지하여 관리를 용이하게 합니다.

3. 캐시 만료 정책 및 전략

캐시된 데이터의 유효 기간을 설정하여 메모리를 효율적으로 활용할 수 있습니다. 데이터의 업데이트 빈도에 따라 적절한 만료 정책을 설정하고, 만료 정책에 따라 적시에 캐시를 갱신하거나 삭제합니다.

4. 캐시 갱신 전략

데이터베이스의 데이터가 변경될 때, 캐시를 어떻게 갱신할지에 대한 전략을 수립해야 합니다. 데이터 변경 시 캐시를 갱신하거나 삭제하는 방법을 고려하여 데이터 일관성을 유지합니다.

 

5. 캐시와 DBMS 동기화 전략

캐시는 검색(Select)에만 사용되지 않습니다. 갱신(update)시에도 캐시를 사용하면 빠르게 갱신할 수 있는데, 이 경우 DBMS와 동기화 전략에 대한 고려가 필요합니다. 

6. 캐시 성능 모니터링

캐시의 성능을 모니터링하여 적절한 시점에 캐시 용량을 조정하고, 성능 향상을 위한 최적화 작업을 수행합니다. 캐시 히트율, 메모리 사용량, 응답 속도 등을 지속적으로 모니터링하여 적시에 대응합니다.

위와 같은 전략을 고려하여 Redis를 DBMS의 캐시로 활용하면, 데이터베이스 부하를 줄이고 응답 속도를 향상시킬 수 있습니다. 또한, 적절한 캐시 전략을 수립함으로써 웹 서비스의 성능을 최적화할 수 있습니다.

 

Redis를 캐시로 사용할 때 고려해야할 위 사항들 중 오늘은 전략에 해당하는 캐시 갱신 및 만료 정책 그리고 동기화 전략에 해당하는 알려진 방법들을 정리해 보도록 하겠습니다. 

 

레디스 캐시 전략에서 자주 사용되는 패턴

캐시를 사용하면 데이터 정합성 문제가 발생할 수 있습니다. 데이터 정합성이란, 캐시(Cache Store)와 데이터베이스(Data Store) 간에 동일한 데이터가 서로 다른 값을 가지는 현상을 말합니다. 예를 들어, 캐시에는 게시글의 좋아요 수가 10개로 저장되어 있지만, 데이터베이스에는 7개로 저장되어 있는 경우입니다.

이러한 문제를 해결하기 위해 다음과 같은 캐싱 전략 패턴을 사용할 수 있습니다. 

1. Look-Aside, Cache-Aside 패턴
   • 데이터 요청 시 먼저 캐시를 확인하고, 캐시에 없는 경우 데이터베이스에서 데이터를 가져와 캐시에 저장합니다.
   • 데이터 변경 시 캐시와 데이터베이스를 모두 업데이트합니다.
2. Read-Through 패턴
   • 데이터 요청 시 먼저 캐시를 확인하고, 캐시에 없는 경우 데이터베이스에서 데이터를 가져와 캐시에 저장합니다.
   • 데이터 변경 시 데이터베이스만 업데이트하고, 캐시는 자동으로 무효화됩니다.
3. Write-Through 패턴
   • 데이터 변경 시 먼저 데이터베이스를 업데이트하고, 그 후 캐시를 업데이트합니다.
   • 데이터 요청 시 캐시에서 데이터를 가져옵니다.

이러한 전략을 통해 캐시와 데이터베이스 간의 데이터 불일치 문제를 해결하면서도 빠른 성능을 유지하는데 도움이 됩니다. 이제부터 각 패턴에 대해서 조금 더 자세히 설명해 보겠습니다. 

 

읽기 (Read) 캐싱 전략

Cache-Aside ( Look-Aside ) 캐싱 전략

Look-Aside 캐싱 전략은 Cache-Aside 패턴이라고도 불리며, 데이터를 조회할 때 먼저 캐시에 저장된 데이터가 있는지 확인하는 전략입니다. 만약 캐시에 데이터가 없다면 데이터베이스에서 데이터를 가져옵니다.

이 전략은 다음과 같은 장점이 있습니다:

• 반복적인 읽기 작업에 적합합니다.
• 캐시와 데이터베이스가 분리되어 있어 원하는 데이터만 캐시에 저장할 수 있습니다.
• 캐시 장애 발생 시에도 데이터베이스에서 데이터를 가져올 수 있어 서비스 중단을 방지할 수 있습니다.

그러나 이 전략에는 다음과 같은 단점도 있습니다:

• 캐시와 데이터베이스 간의 데이터 정합성 문제가 발생할 수 있습니다.
• 초기 조회 시 무조건 데이터베이스를 호출해야 하므로, 단건 호출 빈도가 높은 서비스에는 적합하지 않습니다.

이러한 단점을 해결하기 위해 캐시 워밍(Cache Warming) 기법을 사용할 수 있습니다. 캐시 워밍은 서비스 시작 전에 데이터베이스의 데이터를 미리 캐시에 저장해두는 작업입니다. 이를 통해 초기 트래픽 급증으로 인한 캐시 미스(Cache Miss) 문제를 해결할 수 있습니다.

 

다만, 캐시의 용량이 제한적이므로 일정 시간이 지나면 데이터가 만료되어 다시 Thundering Herd 현상이 발생할 수 있습니다. 따라서 캐시의 TTL(Time-To-Live)을 적절히 조정하는 것이 중요합니다.

Thundering Herd 문제는 컴퓨터 과학에서 발생하는 문제로, 많은 프로세스나 스레드가 동시에 이벤트를 기다리다가 한꺼번에 깨어나는 현상을 말합니다. 이러한 현상은 분산 시스템에서 지연 시간 증가와 같은 심각한 영향을 줄 수 있습니다. 
분산 캐시환경에서 Thundering Herd는 캐시 데이터 만료로 인해 캐시에서 사라지면 한꺼번에 캐시를 요청할 때, 데이터베이스에서 가져오기 위해서 처리시간이 지연되는 것을 말합니다. 

 

Look-Aside, Cache-Aside 패턴의 로직 처리는 다음과 같이 이뤄집니다. 

1. Cache Store에 검색하는 데이터가 있는지 확인하여, 있으면(cache hit) 데이터 검색 처리 완료
2. Cache Store에 없을 경우(cache miss),  DB에서 데이터를 검색
3. DB에서 검색해온 데이터를 redis cache에 업데이트

Look-Aside 캐싱 전략 로직

 

Read Through 캐싱 전략이란?

Read Through 캐싱 전략은 데이터를 조회할 때 캐시에서만 데이터를 읽어오는 방식입니다. 이는 Cache Aside 전략과 유사하지만, 데이터 동기화를 캐시 관리 라이브러리나 캐시 제공자에게 위임한다는 차이가 있습니다.

이 전략의 장점은 다음과 같습니다:

• 캐시와 데이터베이스 간 데이터 동기화가 자동으로 이루어져 데이터 정합성 문제를 해결할 수 있습니다.

하지만 단점도 있습니다:

• 캐시에 문제가 발생하면 서비스 전체가 중단될 수 있어 가용성이 낮습니다.
• 데이터 조회 속도가 Cache Aside 전략에 비해 느릴 수 있습니다.

따라서 Read Through 전략은 읽기 요청이 많은 워크로드에 적합하지만, 캐시 가용성을 높이기 위한 추가 조치가 필요합니다. 

redis의 Replication 또는 Cluster로 구성하여 가용성을 높이는 작업이 필요합니다. 

 

한편, 이 전략은 캐시 warming 과정을 거치는 것이 좋습니다. 이를 통해 초기 데이터 로딩 시간을 단축할 수 있습니다.

요약하면, Read Through 캐싱 전략은 데이터베이스 직접 접근을 최소화하고 데이터 정합성을 유지할 수 있지만, 캐시 가용성 문제가 있어 추가 조치가 필요합니다. 이 전략은 읽기 요청이 많은 워크로드에 적합합니다.

 

Read Through 패턴의 로직 처리는 다음과 같이 이뤄집니다. 

1. Cache Store에 검색하는 데이터가 있는지 확인하여, 있으면(cache hit) 데이터 검색 처리 완료
2. Cache Store에 없을 경우(cache miss), Redis 혹은 cache 라이브러에서 데이터를 검색하여 캐시 업데이트
3. redis cache 데이터를 검색

Read Through 패턴의 로직 처리

실제로 redis에는 데이터를 database로 부터 가져와서 동기화하는 기능을 Hibernate 프레임워크에서 제공하는 rghibernate(Redis Gear Function) 레시피를 제공합니다. 

레디스의 rghibernate 레시피를 통해 구현하는 법 보러 가기

 

rghibernate 소스 코드 보러 가기

 

쓰기 (Write) 캐싱 전략

Write Behind 캐싱 전략이란?

Write Behind 캐싱 전략은 Write-Back이라고도 하며 데이터를 저장할 때 데이터베이스에 바로 쿼리하지 않고, 먼저 캐시에 저장한 뒤 일정 주기마다 일괄적으로 데이터베이스에 반영하는 방식입니다.

 

이 전략의 장점은 다음과 같습니다.

• 데이터베이스 쓰기 횟수를 줄여 쓰기 성능을 향상시킬 수 있습니다.
• 캐시와 데이터베이스 간 데이터 동기화를 비동기적으로 처리하여 응답 시간을 단축할 수 있습니다.
• 애플리케이션 코드를 단순화하고 캐시 일관성을 보장할 수 있습니다.

하지만 단점도 있습니다.

• 캐시에 장애가 발생하면 데이터 유실이 발생할 수 있습니다.
• 데이터베이스에 장애가 발생하면 서비스 가용성이 낮아질 수 있습니다.

따라서 Write Behind 전략은 쓰기 요청이 많은 워크로드에 적합하지만, 데이터 정합성과 가용성을 높이기 위한 추가 조치가 필요합니다.

레디스에서 write-behind 구현하는 법 보러 가기

Write Behind 캐싱 전략 활용 방안
Write Behind 전략을 활용하기 위해서는 다음과 같은 방안을 고려할 수 있습니다.

• Redis의 Replication이나 Cluster 구조를 활용하여 캐시 서비스의 가용성을 높일 수 있습니다.
• Read-Through 전략과 결합하여 가장 최근에 업데이트된 데이터를 항상 캐시에서 사용할 수 있도록 할 수 있습니다.

이를 통해 Write Behind 전략의 장점을 극대화하고, 단점을 최소화할 수 있습니다.

 

Write Behind 패턴의 로직 처리는 다음과 같이 이뤄집니다. 

1. Cache Store에 데이터 갱신 및 저장
2. 주기적 배치 작업으로 데이터베이스에 변경된 캐시 데이터 반영

Write Behind 패턴의 로직 처리

 

 

Write Through 캐싱 전략이란?

Write Through 캐싱 전략은 데이터를 저장할 때 캐시와 데이터베이스에 동시에 데이터를 저장하는 방식입니다. 

이 전략의 장점은 다음과 같습니다:

• 캐시와 데이터베이스가 항상 동기화되어 있어 최신 데이터를 유지할 수 있습니다.
• 데이터 일관성을 유지할 수 있어 안정적입니다.
• 데이터 유실이 발생하면 안 되는 상황에 적합합니다.

하지만 단점도 있습니다:

• 매 요청마다 캐시와 데이터베이스에 두 번의 쓰기 작업이 발생하므로 성능 이슈가 발생할 수 있습니다. 
• 기억장치 속도가 느릴 경우 데이터를 기록할 때 CPU가 대기하는 시간이 필요하여 성능이 감소할 수 있습니다. 

따라서 Write Through 전략은 데이터 일관성과 안정성이 중요한 상황에 적합하지만, 성능 이슈를 고려해야 합니다.

레디스에서 write-through 구현하는 법 보러 가기

Write Through 캐싱 전략 활용 방안
Write Through 전략을 활용하기 위해서는 다음과 같은 방안을 고려할 수 있습니다.

Read-Through 전략과 결합하여 캐시의 최신 데이터 유지와 정합성 이점을 얻을 수 있습니다. 
자주 사용되지 않는 데이터를 효과적으로 관리하기 위해 TTL(Time-To-Live) 기능을 활용하여 불필요한 데이터를 삭제할 수 있습니다.

 

이를 통해 Write Through 전략의 장점을 극대화하고, 단점을 최소화할 수 있습니다.

 

Write Through 패턴의 로직 처리는 다음과 같이 이뤄집니다. 

1. Cache Store에 데이터 갱신 및 저장
2. cache가 바뀌자마자 실시간으로 데이터베이스에 변경된 캐시 데이터 반영

Write Through 패턴의 로직 처리

 

 

Write Around 캐싱 전략이란?

Write Around 캐싱 전략은 데이터를 저장할 때 데이터베이스에만 데이터를 저장하고, 캐시에는 저장하지 않는 방식입니다. 

이 전략의 장점은 다음과 같습니다.

• Write Through 전략보다 훨씬 빠른 속도를 제공합니다.
• 캐시 오염을 방지하여 캐시 효율성을 높일 수 있습니다.
• 캐시 교체로 인한 불필요한 데이터 삭제를 방지할 수 있습니다.

 

하지만 단점도 있습니다.

• 캐시와 데이터베이스 간의 데이터 불일치가 발생할 수 있습니다.
• 데이터베이스에 저장된 데이터가 수정되었을 때, 캐시를 수동으로 삭제하거나 변경해야 합니다.

따라서 Write Around 전략은 데이터가 한 번 쓰여지고 덜 자주 읽히는 상황에서 좋은 성능을 제공할 수 있지만, 데이터 일관성 유지를 위한 추가적인 관리가 필요합니다.

Write Around 캐싱 전략 활용 방안
Write Around 전략을 활용하기 위해서는 다음과 같은 방안을 고려할 수 있습니다:

Look-Aside 및 Read-Through 전략과 결합하여 사용하면 좋습니다.
데이터베이스에 저장된 데이터가 수정되었을 때 캐시를 자동으로 삭제하거나 변경할 수 있는 메커니즘을 구현해야 합니다. 
캐시의 만료 시간(TTL)을 적절히 조정하여 데이터 일관성을 유지할 수 있습니다.

이를 통해 Write Around 전략의 장점을 극대화하고, 단점을 최소화할 수 있습니다.

 

Write Around 패턴의 로직 처리는 다음과 같이 이뤄집니다. 

1. 모든 갱신 데이터는 데이터베이스에만 반영

Write Around 패턴의 로직 처리

 

 

오늘은 레디스를 데이터베이스 캐시로 사용할 때 취할 수 있는 캐시 전략에 대해서 전반적으로 알아보았습니다. 

다음에는 레디스와 Mysql 또는 Postgresql등의 RDBMS가 어떻게 데이터를 동기화 할 수 있는지 알아보도록 하겠습니다.