[캐시]캐싱 전략에 대해서 (feat. Redis)

안녕하세요, 오늘은 Redis에서 캐싱을 위한 여러가지 전략들에 대해서 알아보려고 합니다.

 

이전까지는 캐싱에 대해서 단순하게 잘 바뀌지 않는 데이터를 캐싱하면 좋을거야, DB 엑세스보다 메모리 엑세스가 빠르니 캐싱이 좋을거야와 같은 1차원적인 생각만을 가지고 있었는데요.

 

Redis에서 캐시를 읽고 쓰기 위한 여러가지 전략들에 대해 알게되어, 공부하는 차원에서 캐싱 전략에 대한 내용들을 정리해보려고 합니다.

 

Redis 캐시 읽기 전략

Look Aside (Cache Aside) 전략

1. 기본적으로 캐시에 데이터가 있는지 확인합니다.
2. 데이터가 없다면 DB에서 데이터를 찾아봅니다.
3. DB에서 가져온 데이터를 캐시에 저장합니다.
4. 데이터를 사용자에게 전달합니다.

이처럼 Look Aside 전략은 데이터가 캐시에 있는지를 먼저 확인하는 Read 전략입니다.

 

Pros

• 반복적인 읽기 연산을 하는 경우에 빠른 속도를 보장합니다.
• 캐시(Redis)가 에러나도 DB를 통해 대응이 가능합니다.

Cons

• DB의 값은 변경되었지만 캐시내의 데이터는 예전 것일 수 있습니다. 즉, 데이터 정합성이 보장되지 않습니다. (적절한 만료시간의 설정이 필요합니다)
• 초기 조회시 캐시에 값이 없다면 매번 DB에 엑세스가 필요합니다. (미리 캐시에 적재하는 Cache Warming으로 해결이 가능합니다)
• 캐시에 장애가 발생한다면 순간적으로 DB의 부하가 높아질 수 있습니다.

 

Read Through 전략

1. 캐시에 데이터가 있는지 확인합니다.
2. 데이터가 없다면 "캐시가" DB에서 데이터를 찾아봅니다. (데이터 동기화 문제를 캐시가 위임한 형태입니다)
3. DB에서 가져온 데이터를 캐시에 저장합니다.
4. 캐시가 데이터를 사용자에게 전달합니다.

이처럼 Read Through 전략은 캐시에서만 데이터를 읽어오는 전략입니다. 데이터가 없는 경우의 DB 엑세스 또한 캐시가 담당합니다.

즉, 데이터 동기화를 캐시가 담당합니다.

 

Pros

• 반복적인 Read 연산을 하는 경우에는 빠른 속도를 보장합니다.
• 캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성을 보장받을 수 있씁니다.
• 서버가 DB에 직접적으로 접근하지 않으므로 데이터베이스의 소모 자원이 줄어듭니다.

Cons

• 캐시가 장애나는 경우에는 SPOF 문제가 발생합니다. (Replication, Clustering을 통해 가용성 확보가 필요합니다)
• 초기 조회시 캐시에 값이 없다면 Look Aside와 마찬가지로 DB에 엑세스가 필요합니다. (미리 캐시에 적재하는 Cache Warming으로 해결이 가능합니다)

 

Redis - 캐시 쓰기 전략

Write Back 전략

1. 모든 데이터를 캐시에 저장합니다.
2. 특정 시간마다 DB에 캐시에 저장된 데이터를 동기화(저장) 합니다.
3. DB에 데이터가 저장되면, 캐시에서는 해당 데이터를 지우거나 가지고 있을 수 있습니다.

이처럼 Write Back 전략은 데이터를 삽입할 때 캐시에 보관후, 일정 시간마다 DB에 저장합니다. 로그성 데이터에 용이합니다.

 

Pros

• (캐시에서 데이터를 가져오는 경우에 한해서) 데이터 정합성이 확보됩니다.
• 캐시에 데이터를 한번에 저장하므로 DB의 부하를 줄일 수 있습니다.
• 쓰기가 빈번하면서 읽기를 하는데 많은 양의 리소스가 필요한 서비스에 적합합니다.

Cons

• 캐시에서 장애가나면 데이터가 사라질 수 있습니다. (데이터 영구 소실 가능성이 있습니다)
• 필요없는 정보가 많이 저장될 수 있습니다.

 

Write Through 전략

1. 데이터 쓰기시 캐시에 데이터를 저장합니다.
2. 캐시가 해당 데이터를 바로 DB에 저장합니다.
3. 캐시에서도 데이터를 유지합니다.

이처럼 Write Through 전략은 DB와 캐시 두곳에 동시에 데이터를 저장하는 방법입니다. Read Through 전략과 마찬가지로 캐시가 DB 동기화 작업까지 위임한 형태입니다.

 

Pros

• WrIte한 데이터를 바로 읽는 경우 캐시 이용이 가능합니다. (e.g 최신 피드를 가져오는 경우에 좋습니다)
• 캐시와 DB의 데이터 차이가 없습니다. 즉, 데이터 정합성이 보장됩니다.
• 데이터의 유실 위험이 낮습니다.

Cons

• Write, Update가 빈번한 경우 캐시, DB 두 곳의 데이터를 매번 변경하므로 성능이 좋지 않습니다.
• 쓰기 작업시 캐시~DB 2단계를 거치기 때문에 상대적으로 느립니다.

 

Write Around 전략

1. 데이터 쓰기시 DB에 모든 데이터를 저장합니다. (캐시를 갱신하지는 않습니다)
2. 데이터 읽기시 캐시에서 캐싱된 데이터가 있는지 찾아봅니다.
3. 캐시에 해당 데이터가 없는 경우 DB를 통해 찾고, 서버가 해당 데이터를 캐시에 저장합니다.

이처럼 Write Around 전략은 기본적으로 데이터를 DB에 저장하고, 캐시 미스인 경우에만 캐시에 저장하는 방법입니다.

Write Around 전략은 주로 Look Aside 혹은 Read Through와 결합해서 사용됩니다.

 

Pros

• Write Through 전략보다 속도가 빠릅니다. (캐시 미스인 경우에만 변경하기 때문입니다)
• 데이터가 한 번만 쓰여지고 읽기가 잘 일어나지 않는 상황에서 좋은 성능을 제공합니다.

Cons

• 데이터 정합성을 보장받을 수 없습니다.

 

지금까지 캐싱 전략에 대해서 알아보았습니다. 가장 기본적인 전략들만 알아보았는데 적절한 캐싱을 위해서는 이 외에도 다양한 전략들이 필요합니다. (타임아웃 전략, 캐시 데이터 최신화 전략 등)

 

만약 저와 비슷하게 캐시를 무의식적으로 그냥 사용하셨던 분들이라면, 위 개념을 이해한다면 더욱 다양한 캐싱 전략의 구성에 대해서도 응용하는데 도움이 되리라고 생각합니다.

 

읽어주셔서 감사합니다 :)

 



참고자료

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

Caching Strategies and How to Choose the Right One