본문 바로가기

시스템 디자인

(3)
캐시 쓰기 전략과 피크에 강한 캐싱 전략 Write-Through 전략쓰기가 항상 캐시를 거쳐 DB에 쓰이는 전략. 즉, 데이터가 먼저 캐시에 쓰이고 그 다음에 DB에 쓰이는 전략. 일을 두 번 하는 것처럼 보이지만(데이터를 항상 캐시에 1차, DB에 2차로 두 번씩 쓰게 되므로) Read-Through 전략과 함께 사용하면 Read-Through 전략의 이점을 모두 누릴 수 있는 한편 DB와 데이터 싱크가 항상 맞기 때문에 캐시 무효화를 할 필요가 없다.  Write-Around 전략데이터는 DB에 쓰이고 한 번이라도 읽히는 데이터만 캐시에 올라간다. 이렇게 하면 데이터가 한 번 쓰인 뒤 거의 읽히지 않는 경우에 그런 데이터까지 캐싱하지 않으므로 효율적이다. 예를 들어 실시간 로그나 채팅 메시지 같은 것들은 이 전략을 사용하는 것이 좋다.  ..
캐시 쓰기 전략 캐시 전략 결정 요인캐시할 데이터 종류캐시할 데이터 크기데이터 액세스 패턴  데이터 액세스 패턴이란?데이터가 어떻게 쓰이고 읽히는지를 말한다. 쓰기 작업이 많고 읽기 작업은 적은가? (예: 시간별 로그)한 번 쓰인 후 여러 번 읽히는가? (예: 사용자 프로필)결과가 항상 고유한가? 즉, 동일한 요청이라도 매번 다른 결과가 나올 수 있는가? (예: 검색 쿼리는 사용자의 위치나 시간 등에 따라 검색 결과가 달라질 수 있음)  읽기 전략 1 - 캐시 어사이드(Cache-Aside)가장 일반적으로 사용됨앱이 캐시/DB와 직접 통신함캐시와 DB 사이에는 연결이 없음. 캐시와 DB의 싱크를 위해 일반적으로 TTL(Time to Live)를 사용한다.    캐시 어사이드(Cache-Aside) 프로세스1. 앱이 캐시..
캐싱의 정의와 똑똑하게 캐싱하기 캐시의 보편성캐시는 가장 낮은 수준부터 가장 높은 수준까지 어디에나 존재한다.   캐시의 정의일시적으로 일부 데이터를 일정 시간 동안 저장하기 위한 계층.  캐시의 필요성정보를 때마다 새로 생성하는 비용이 높기 때문사용자 응답 속도를 높이기 위해서  캐시 무효화의 정의캐시에 있는 데이터를 무효로 표시하는 프로세스캐시 무효화 이후에 요청이 도착하면 캐시 미스로 처리되어 데이터베이스에서 새로 생성되어야 함.  캐시 무효화의 필요성out-dated 데이터를 제공하게 될 수도 있기 때문에.  캐시 무효화가 어려운 이유프로그램에 그렇다 할 장애가 없기 때문에 디버깅이 매우 어려움."관련 콘텐츠 링크"를 뿌려주는 페이지가 있다고 했을 때, 어떤 링크가 404가 떠서 이 링크를 삭제하기로 했지만 여전히 캐시 데이터가..