레이지 로딩(Lazy Loading)
이름에 나타나듯이 레이지 로딩은 클라이언트에게서 데이터가 필요로 해질 때 Cache에 로딩하는 전략입니다. DB나 외부 API에 접근하기 전 Cache를 먼저 확인 한 후 Cache에 데이터가 존재한다면 Cache 데이터를 그렇지 않다면 원본(DB나 외부 API)에 접근하여 값을 가져와 캐시에 올려놓습니다.
Lazy Loading (look aside) 전략
캐시에 데이터가 있을 경우 (만료 X)
클라이언트가 서버에 데이터를 요청합니다.
서버는 Cache에 해당 데이터가 있는지 확인합니다.
캐시에 데이터가 있으므로 바로 반환합니다.
캐시에 데이터가 없을 경우
클라이언트가 서버에 데이터를 요청합니다.
서버는 Cache에 해당 데이터가 있는지 확인합니다.
캐시에 데이터가 없으므로 원 데이터를 가져옵니다.
가져온 데이터를 캐시에 저장합니다.
데이터를 클라이언트에게 반환합니다.
레이지 로딩 장점
요청 받은 데이터만 캐시에 저장합니다. 파르토의 법칙에 따르면 전체 데이터 중 20% 정도가 대부분이 접근 하고 나머지 80%는 거의 접근이 없습니다. 따라서 실제로 접근이 있는 데이터만 캐시에 담을 수 있습니다.
캐시 미스가 발생했을 때 치명적이지 않습니다. 왜냐하면 차선책으로 실제 데이터에 접근하여 최신의 데이터 가져오기 때문입니다. 그 후 데이터 접근에 대해서는 다시 캐시가 적용됩니다.
레이지 로딩 단점
값을 읽을 때 캐시 미스마다 3가지의 패널티를 가집니다. 첫번째, 캐시에 확인 요청입니다. 두번째, 데이터베이스에 확인 요청입니다. 마지막으로 캐시에 데이터를 데이터베이스에서 가져온 데이터를 쓰는 부분입니다. 캐시 미스가 많이 일어난다면 딜레이는 눈에 띄게 증가할 것입니다.
캐시 미스가 발생했을 때 마다 캐시에 데이터를 쓰기 때문에 캐시의 데이터는 최신을 유지 못할 가능성이 있습니다. 따라서 캐시의 데이터를 반환했는데 부정확한 데이터가 반환될 수 있습니다.
Write-Through
write-through 전략은 데이터를 추가하거나 업데이트할 때 캐시에 동시에 업데이트하는 전략입니다. 아래의 이미지와 같습니다.
그리고 읽을때는 아래와 같이 실제 DB를 볼 필요 없이 cache만 읽으면 됩니다.
Write-Through 장점
캐시에 들어있는 데이터는 항상 최신의 데이터를 유지합니다. 왜냐하면 DB와 캐시의 값은 항상 동시에 쓰기 때문입니다.
Write-Through 단점
값을 쓸 때 마다 캐시와 데이터베이스에 모두 쓰기때문에 업데이트와 생성은 항상 2번의 패널티를 가집니다. 이는 쓰기 작업이 많은 시스템이라면 눈에 띄는 딜레이를 유발할 수 있습니다.
새로운 노드가 추가되거나 했을 경우 데이터를 찾지 못할 수 있습니다. 왜냐하면 새로운 노드에는 해당 데이터가 없을 것이기 때문입니다.
만약 읽을 때 캐시 미싱이 일어났다면 이를 다시 매꿔주기가 애매해집니다.
대부분의 데이터는 거의 읽히지 않으므로 리소스 낭비로 이어질 수 있습니다.
Adding TTL
레이지 로딩 전략은 최신 데이터가 아닐 가능성이 있습니다. 하지만 캐싱 미스가 발생했을 때 심각한 오류를 발생하진 않습니다. Write-through 전략은 항상 최신의 데이터를 유지합니다. 하지만 캐싱 미스가 발생 했을 경우 잘못된 경우가 발생할 수 있으며 불필요한 메모리를 사용하여 낭비가 발생할 수 있습니다.
각 전략에 TTL(time to live)를 추가함으로써 이득을 취할 수 있습니다. TTL은 key가 자연스럽게 만료되어 없어지게 하는 시간(Redis의 경우 Integer 당 1밀리초 단위)입니다. 레이지 로딩 전략에서는 TTL을 설정 함으로써 자연스럽게 값이 없어지고 캐싱 미스를 일으켜 최신을 유지할 수 있게됩니다. Write-through 전략에서 TTL을 설정하면 업데이트가 되지 않는 데이터들은 없어지게 됩니다. 그렇게 되면 메모리적인 이득을 얻을 수 있게됩니다.
