cash말고! 데이터 베이스 캐시(Database Cache) 활용 전략(2)

이전 포스팅에 이어서
오늘 공부할 것은 다양한 캐싱 전략 중 WriteBack, WriteThrough, Write Around에 대해서 알아보도록 하겠습니다.

 

https://colevelup.tistory.com/7

cash말고! 데이터 베이스 캐시(Database Cache) 활용 전략(1)

 

캐싱 전략

---

Wirte Back(Write Behind)

---

출처 ;  https://velog.io/@hwaya2828/Redis-캐시-전략

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

• 모든 데이터를 Cache Store에 저장한 뒤 일정 시간 후 Data Store에 저장한다.
• ex) Log를 DB에 넣어야 하는 경우 cache에 몰아넣어 두고 한 번에 배치 작업으로 진행한다.

 

특징

---

• DB에 대한 전체 쓰기를 줄일 수 있어서 해당 비용을 감소할 수 있다.
• 데이터의 정합성이 확보된다.
• 단 캐시가 장애가 났을 경우 Data가 유실될 수 있다는 단점이 있다.
• 불필요한 리소스가 저장될 수 있다.
• Write Back 패턴의 경우 Cache Store가 데이터 저장소 역할을 하면서 동시에 Data Store에 Write 부하를 줄이기 위한 Queue의 역할도 한다.
  • https://colevelup.tistory.com/3 메시지 큐에 대해서는 이전 포스팅에서 다루었습니다 참고하시면 됩니다.
  • Database의 부하를 경감시킬 수 있는 장점이 있다.
  • 대체로 쓰기 작업이 많은 경우 적용을 권장함.

 

• Write Back 패턴의 장점
  • 데이터베이스의 일시적인 다운타임을 허용하거나 장애에 대응할 수 있다.
  • Cache와 Date Store 간 데이터 정합성 유지하기 유용하다.
  • 쓰기 성능을 향상하고 쓰기 작업량이 많은 워크로드에 적합하다
    • read-through와 결합하면 최근 업데이트되고 엑스스된 데이터를 항상 캐시에 사용할 수 있는 혼합 워크로드에 적합하다.

일부 개발자들은 cache-aside와 write-back에서 Peak 상태 둘 다 로드 기간 동안 트래픽 spike를 잘 처리하기 위해 Redis를 활용하기도 한다.
대부분 RDBMS에서 스토리지 엔진(InnoDB)은 기본적으로 내부에서 후기입 캐시를 활성화한다.
쿼리는 먼저 메모리에 기록되고 나중에 결국에 디스크로 플러시 되는 방식.

 

• Write Back 패턴의 단점
  • Cache Store에서 Data Store로 데이터를 전송하기 전에 장애 발생 시 데이터 분실 발생 위험이 있을 수 있음
  • 자주 사용되지 않는 데이터가 저장되어 리소스 낭비, Write 작업에 부하 발생할 수 있음
    • *TTL을 꼭 사용하여 사용되지 않은 데이터를 삭제해야 한다

TTL 이란
타임 투 리브(Time to live, TTL)는 컴퓨터 나 네트워크에서 데이터의 유효 기간을 나타내기 위한 방법이다.
TTL은  계수기나 타임스탬프의 형태로 데이터에 포함되며, 정해진 유효기간이 지나면 데이터는 폐기된다. 
컴퓨터 네트워크에서 TTL은 패킷의 무한 순환을 방지하는 역할을 한다.
컴퓨터 애플리케이션에서 TTL은 캐시의 성능이나 프라이버시 수준을 향상하는 데에 사용되기도 한다.

 

Write Through

---

출처 : https://velog.io/@hwaya2828/Redis-캐시-전략

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

• Client가 Data를 쓰거나 값을 update 하려고 할 때

1. Client는 Data를 Cache에 직접 쓴다.
2. Cache는 DB에 Data를 update 한다.
3. 쓰기가 완료되면 Cache와 Database 모두 동일한 값을 가지며 Cache는 항상 일관성을 유지한다.

특징

---

• 항상 Cache와 DB가 동기화되어 있어 DB 작성할 때마다 Cache에 Data를 추가해야 한다.
• Cache와 Back up DB에 업데이트를 같이 하여 데이터 일관성을 유지할 수 있어서 안정적이다.
• 데이터 유실이 절대로 발생하면 안 되는 상황에 적합하다.
• 기억장치에 데이터를 기록할 때 cpu 대기시간이 필요하기 때문에 성능이 떨어진다.
• 사실상 Cache가 자체적으로 많은 작업을 수행하지 않는다.
• Wrtie Through 패턴은 Cache Store 에도 반영하고 Data Store에도 동시에 반영하는 방식
  • Write Back은 일정 시간을 두고 나중에 한꺼번에 저장한다.
  • 그래서 항상 동기화가 되어 있어 항상 최신 정보를 가지고 있다는 장점이 있다.
• 하지만 결국 저장할 때마다 2단계 과정을 거쳐 치기 때문에 상대적으로 느리며 무조건 일단 Cache Store에 저장하기 때문에 캐시에 넣은 데이터를 저장만 하고 사용하지 않을 가능성이 있어서 리소스 낭비 가능성이 있다.
  • 이 역시 이를 해결하기 위해 TTL을 꼭 사용하여 사용되지 않는 데이터를 반드시 삭제해야 한다.

 

Write Around

---

출처 : https://aws.amazon.com/ko/blogs/database/amazon-dynamodb-accelerator-dax-a-read-throughwrite-through-cache-for-dynamodb/

• 데이터는 데이터베이스에 직접 기록되고 읽은 데이터만 캐시로 들어간다.
• IoT 또는 ad Tech Space의 일부 워크로드에는 한 번 쓰고 절대 읽지 않는 상당한 양의 데이터가 있다.
• 이런 시나리오에서는 write - through 전략을 사용하는 것이 의미 없는 경우가 많다.
• Cache가 읽지 않은 데이터로 채워지면 일반적으로 사용률과 Cache/Catch, miss 비율이 낮아 효용이 감소한다.
• 쓰기가 DB로 직접 이동하는 쓰기 패턴을 사용할 수 있음 따라서 읽은 데이터만 캐시 된다.

특징

---

• 읽은 데이터만 캐시에 저장한다.
• Write Through보다 빠르다.
• 데이터 정합성 문제가 발생할 수 있다.
• 요청이 들어오면 DB에 직접적으로 다 저장한 뒤 읽은 데이터만 Cache에 저장된다.
• 속도는 빠르나 Cache에 update 하고 보조 기억장치에는 바로 update 하지 않아
  Cache와 보조 메모리의 값이 서로 다른 경우 발생한다.
• ex) 실시간 로그 또는 채팅방 메시지로 사용될 수 있다.

 

참조

---

https://velog.io/@hwaya2828/Redis-%EC%BA%90%EC%8B%9C-%EC%A0%84%EB%9E%B5

Redis 캐싱 전략

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

Caching Strategies and How to Choose the Right One