캐시 쓰기 전략과 피크에 강한 캐싱 전략

 

Write-Through 전략

쓰기가 항상 캐시를 거쳐 DB에 쓰이는 전략. 즉, 데이터가 먼저 캐시에 쓰이고 그 다음에 DB에 쓰이는 전략. 일을 두 번 하는 것처럼 보이지만(데이터를 항상 캐시에 1차, DB에 2차로 두 번씩 쓰게 되므로) Read-Through 전략과 함께 사용하면 Read-Through 전략의 이점을 모두 누릴 수 있는 한편 DB와 데이터 싱크가 항상 맞기 때문에 캐시 무효화를 할 필요가 없다.

 

 

Write-Around 전략

데이터는 DB에 쓰이고 한 번이라도 읽히는 데이터만 캐시에 올라간다. 이렇게 하면 데이터가 한 번 쓰인 뒤 거의 읽히지 않는 경우에 그런 데이터까지 캐싱하지 않으므로 효율적이다. 예를 들어 실시간 로그나 채팅 메시지 같은 것들은 이 전략을 사용하는 것이 좋다.

 

 

Write-Back 전략

Write-Through와 비슷하지만 비동기적으로 DB에 쓰기가 일어난다는 것이 다르다. 앱의 관점에서는 Write-Back전략이 Write-Through 전략보다 더 빠르게 보인다. 

 

 

Write-Back 전략의 프로세스

• 앱이 데이터를 캐시에 쓴다.
• 캐시는 데이터를 저장 후 즉시 acknowledge 한다.
• 그 후 캐시는 DB에 데이터를 다시 쓰기 한다.

 

Write-Back 전략이 적합한 케이스

쓰기 성능을 줄여주기 때문에 쓰기가 많은 시스템에 적합하다. Read-Through 전략과 함께 사용하면 항상 최신 데이터가 캐시에 존재하기 때문에 합이 잘 맞는다(Writhe-Back은 항상 캐시에 먼저 데이터를 쓰고, Read-Through는 항상 캐시에 먼저 데이터가 있는지 확인하기 때문).

 

 

Write-Back 전략의 장단점

쓰기가 비동기적으로 이루어지므로 배치가 지원되면 DB가 request당 요금을 매기는 경우 쓰기 비용을 줄일 수 있다는 장점이 있다. 하지만 Write-Back의 단점은 아무래도 캐시가 다운 되었을 때 데이터가 영구적으로 손실될 위험이 있다는 것이다.

 

 

피크 부하에 강한 캐싱전략은?

피크 부하에 잘 대응하기 위해서 Redis로 Cache-Aside(애플리케이션이 캐싱을 적절히 조절할 수 있게 해주기 때문에 읽기 부하 최적화를 위해 채택하는 경향이 있음. 특히 앱에서 hot data를 선별해서 캐시에 올리는 등의 조절이 가능.)와 Write-Back를 채택하기도 한다.