24/01/13 TIL __ cache를 사용하기 위한 전략

 

 

최종프로젝트의 주제를 라이브 스트리밍 사이트로 생각하다 보니, 대용량 트래픽 관련된 부분을 계속 찾고있다. 

많은 기술들이 있지만 오늘은 캐싱 전략에 대해 이야기 해보려 한다. 

 

캐시에 대한 내용은

https://gabojok.tistory.com/262

24/01/04 TIL __ cache

 

 

캐싱 전략

어떤 서비스를 위해 캐싱을 사용하는지 그 용도에 따라 다르게 전략을 잡으면 좋을것 같다. 

왜 그런지 전략들을 하나씩 살펴보자. 

 

Cache Aside

 

• 캐시를 옆에 두고 필요할때만 데이터를 로드한다. 
• 순서를 살펴보자면 아래와 같다. 
  • 캐시에 데이터가 있나? ---- Y ----- 캐시에서 가져온다(cache hit)
  • 캐시에 데이터가 없나? ---- N ----- (cache miss)----
  • --- 데이터베이스 에서 가져와 application에 넣는다. --- 그 데이터를 application에서 cache에도 넣는다.
• 장점
  • 캐시에 데이터를 넣어두고 읽기 때문에 읽기가 많이 수행되는 경우 좋은 전략이다. 
  • 인메모리 데이터베이스중 하나인 레디스(빠르게 데이터를 찾아올 수 있음!) 를 주로 사용한다. 
  • 읽기 작업만 수행되는걸로 보면 캐시 분리를 했다고 볼 수 있는데, 캐시 분리 덕분에 캐시 오류가 발생한 경우 캐시 클러스터 다운이 발생했을때 시스템 전체의 오류로 발생하지 않는다.
• 단점
  • 캐시에 없는 데이터라면 데이터베이스에서 데이터를 가져오기 까지 많은 시간이 걸린다. 
  • 캐시의 동기화 문제가 중요해 진다. (데이터가 갱신되었는데 캐시에 데이터는 이전 데이터를 가지고 있는 경우를 생각해야 한다.)

 

 

Read-Through

 

 

• 순서
  • 캐시에 데이터가 있나?  ----- Y ----- 캐시에서 가져온다.
  • 캐시에 데이터가 없나? ------ N ----- cache miss ---
  • --- 데이터베이스 에서 정보를 캐시로 가져온다 ----- 캐시에서 application으로 정보를 준다.
• cache aside와 다른점은 application이 직접 캐시에 데이터를 채우지 않는다. db에게 받아서 채운다.
• 장점
  • 캐시에 넣어두고 읽기 때문에,  읽기 작업이 많은 경우 알맞다.
• 단점
  • 데이터를 처음 요청하는 경우, 캐시에는 아무 데이터도 없기 때문에 항상 cache miss가 발생할수 밖에 없다. 
  • 만약 첫 요청이 지연된다면 그 다음 요청에도 cache miss가 발생할 수 밖에 없다.
• 이것도 초기로딩 방식과 부분 로딩 방식으로 나뉘는데 
  • 초기로딩 
    • 응답시간이 향상되고, 데이터베이스에 부하를 분산시킬 수 있다는 큰 장점이 있지만,
    • 필요하지 않은 데이터까지 로딩을 해서 캐시에 보관해야 하기때문에 리소스 낭비가 있고,
    • 만약 가져오는 데이터의 양이 많다면, 한번에 모든 데이터를 가져오는게 굉장한 부담이 있을 수 있다.
  • 부분로딩
    • 필요한 부분만 로딩해서 가져오기 때문에 매모리를 효율적으로 사용할 수 있다는 장점이 있다.( 특히 대용량 데이터의 경우 )
    • 그러나 필요한 데이터에 대한 첫 요청은 아무래도 캐시에서 가져오는 것보다 지연시간이 있을수 밖에 없고,
    • 지연시간이 있다보면, 유저는 여러번 클릭을 하는 현상이 나타날 수 있고, 그러면 여러번 요청하는 상황이 되어 db에 부하가 생길 확률이 높다. 

 

 

 

Write-Through

 

 

• 쓰기 작업에 대한 전략이며, 캐시에 데이터를 업데이트 한 즉시 db에 업데이트 한다. (
• 장점
  • 캐시에 데이터가 업데이트 되자마자 바로 db에 업데이트 되기 때문에 데이터가 일관된다.
  • 따라서 데이터가 유실되면 안되는 경우 이런 전략은 꽤 알맞을 것 같다.
  • 또한 캐시의 데이터는 항상 최신이 유지되니 이런 특성이 필요한 경우에도 잘 맞을 것 같다..
• 단점
  • 그러나, db에 데이터를 기록하는 그 때에 cpu는 대기하는 시간이 필요하기 때문에 성능이 떨어진다.(지연시간 증가!!)
  • 또 사용하지 않는 데이터 까지 캐시에 항상 저장하기 때문에 리소스가 낭비되는 측면이 있다.
• 보완
  • 이런 단점을 보완하려고 write through 캐싱 전략과, read-through 캐싱 전략을 함께 사용하기도 한다. 
  •  write through 로 쓰기작업에 대한 일관성 보장, read through로 읽기 작업에 대한 성능 업 해서 최적화를 하는것.
  • 글을 작성하거나 사진을 업로드 할때 이렇게 같이 사용하면 좋을 것 같다.

 

 

Write-Around

 

• 쓰기 작업에 대한 전략이다.
• 데이터를 올릴때 db에 바로 저장 하고, 캐시에는 읽은 캐시만 보관한다.
• 장점
  • 따라서 불필요한 캐시 리소스 낭비를 줄일 수 있다.
• 단점
  • 읽기가 자주 된다면, 캐시에 계속 데이터를 로드해야 함으로 성능이 저하될 수 있다.
  • 캐시에는 최신 데이터를 항상 가지고 있지 않기 때문에, 일관성이 깨질 수 있다.

 

 

 

Write-Back

 

• 쓰기작업에 대한 전략이며,
• 캐시에 먼저 데이터를 기록한 후 나중에 비동기적으로 데이터베이스에 저장한다.
• 장점
  • 캐시에 먼저 데이터를 기록하기 때문에 빠르게 쓰기 작업을 완료한것처럼 보인다.
  • 비동기 적으로 데이터 베이스에 데이터를 저장하기 때문에, 응답시간이 향상된다.
  • 데이터베이스에 대한 전체 쓰기 작업을 줄일 수 있어 비용 절감 효과가 있다.
• 단점
  • 캐시에서 데이터가 손실될 수 있다는 리스크가 있다. 
  • 데이터는 비동기 적으로 db에 저장되기 때문에 캐시에서 캐시와 db간 데이터 일관성이 없을 수 있다. 

 

 

실시간 채팅과 실시간 라이브 방송에 대한것은 읽기와 쓰기 작업 모두 활발하게 일어나는데

이런 경우 읽기 작업에 적합한 전략과, 쓰기 작업에 적합한 전략을 섞어서 사용하는 게 좋아보인다. 

 

읽기 전략의 경우 cache aside는 필요할 때만 데이터를 업로드 하기 때문에 현재 만들려고 하는 서비스에는 적합하지 않아 보이고,

read through는 데이터를 캐시에 다 넣고 캐시에서 가져오기 때문에 적합해 보였다. 

 

쓰기 전략의 경우 

write around는 데이터 베이스에 바로 기록하고 읽은 데이터만 캐시에 저장하기 때문에 적합하지 않아 보였고,

write back은 비동기 적으로 데이터베이스에 업데이트 하기 때문에 실시간 채팅과 라이브를 할때 적합해 보이지 않았다.

실시간 업데이트를 위해서는 write through로 데이터베이스에 즉시 저장해 주는게 좋을 것 같다.

 

따라서 나는 read Through와 write through를 함께 사용하면 좋을 것 같은데,

이부분은 월요일에 팀원들이랑 함께 이야기 해봐야 겠다!

 

 

 

 

 

참고한 사이트

https://wnsgml972.github.io/database/2020/12/13/Caching/

Caching 전략 소개 및 사용 예제

https://www.techtarget.com/whatis/definition/write-through

What Is Write-Though? | Definition from TechTarget

https://melonicedlatte.com/computerarchitecture/2019/02/12/203749.html

[Cache] Write Through과 Write Back의 차이 - Easy is Perfect