Cache의 사용 예

캐시는 어떤 경우에 사용할 수 있을까?

• 캐시는 느린 것을 빠르게 하기 위해 서 사용한다
• 느린 저장장치의 데이터 중 일부를 빠른 저장장치에 올려두고 사용하는 것이 캐시

 

Cache Aside (Look Aside)

---

캐시에 먼저 접근하고 없으면 DB에 직접 접근 후 캐시 업데이트

• 가장 일반적인 형태 의 캐시 사용
• 어떤 경우에 성능이 가장 좋을까?
  • 캐시 Hit가 많이 발생할 때
• 어떤 경우에 성능이 가장 떨어질까?
  • DB에 없는 데이터를 계속해서 접근하게 될 때
    • DB에 없는 데이터에 접근하는 경우에는 Miss가 발생해도 데이터를 캐시에 올려둘 수 없기 때문에 매번 DB에 방문하게 된다
    • 이러한 경우에는 이 데이터는 존재하지 않는다는 것을 캐시에 저장 하면, DB에 가지 않아도 데이터가 없음을 알 수 있다
• 이러한 구조에서 더 고려해야 할 것은, 캐시에 없는 데이터에 대한 Read가 동시에 10만개가 들어왔다고 해보자
  • 그럼 모든 요청이 DB로 가게 될 것이다
  • 그렇게 되면 DB에 엄청난 부하가 걸리게 된다

 

Read Through

---

캐시 서버에서 알아서 DB에 접근하고 업데이트를 해주는 형태

• 어떤 부분에서 유용할까?
• 누가 캐시를 업데이트 하는지에 대한 고민을 해보자
  • 원래는 백엔드 서버(Application)이 하게 된다
  • 서버 입장에서 생각해보면 캐시 솔루션에서 캐시 업데이트를 해준다면 더욱 편리 할 것이다
  • 서버 입장에서는 Read를 했을 때, 데이터가 없다는 것은 캐시에도 없고, DB까지 갔다왔는데도 없으면 데이터가 없다라고 응답을 받는 것이 훨씬 편할 것이다
    • 그렇게 되면 서버 입장에서는 그냥 Read만 하면 된다

 

Write Around

---

값을 쓸 때, DB에 바로 쓰고 캐시에는 업데이트 하지 않는다

• 어떤 부분에서 유용할까?
  • 위의 경우에는 DB가 변경되어도, 캐시에서 데이터를 읽어가게 되면 과거의 데이터를 읽게되는 셈이다
• 누가 캐시를 업데이트 하는지에 대해 다시 생각해보자
• Write는 자주 일어나는데, Write한 데이터를 Read를 많이 하지는 않는 경우 에서 사용된다
  • 예를 들어, 게시물의 댓글을 수정한다고 했을 때 업데이트만 정상적으로 됐다면 댓글을 굳이 곧바로 업데이트되지 않아도 큰 문제가 되지 않는다

 

Write Back

---

계속 캐시에서 읽고 쓰다가, 특정 시점마다 DB와 Sync를 맞춰준다

• 읽고 쓰는 것은 무조건 캐시에만 하고, 특정 시점마다 캐시의 내용을 DB에 업데이트
• 또는 변경되었음을 미리 표시해두고(Dirty Bit) 캐시에서 해당 데이터가 밀려날 때 표시가 되어 있다면 DB에 반영해준다
  • DB에 반영하기 전에 캐시 서버가 죽어버리면, 데이터가 날아갈 수 있다는 문제 가 있다
  • 날아가도 피해가 덜한 데이터들을 다룰 때 Write Back 방식을 사용한다
    • 송금 내역과 같이 날아가면 안되는 데이터에 대해서는 Write Back을 사용하면 안 된다
    • 로그와 같이 조금 날아가도 큰 문제가 되지 않는 데이터에 대해서 사용하는 건 괜찮을지도
• Write가 자주 발생하는 경우에 속도 향상에 도움이 된다
• Write Back을 사용하는 경우는 우리 주변에 더 있을 것이다

 

Write Through

---

캐시에 쓰고, 곧바로 DB에 가서 쓴다

• 캐시와 DB의 일관성은 계속 유지가 되지만, 속도가 느리다는 문제가 있다
• Write에 대해서는 캐시를 사용하지 않는 것보다 느리다

 

우리는 캐시가 잘못된 데이터를 가지고 있는 경우를 스톨(Stall)이라고 한다

DB는 업데이트 되었지만, 캐시는 업데이트가 되지 않은 경우가 일반적이다

이러한 스톨을 고려해서 캐시 정책을 선택 해야 한다