[매일메일] 캐싱 전략 (BE.250205)

캐시의 목표: 성능 향상, 부하 감소

 

Cach Aside(Lazy Loading)

캐시 히트 시 캐시에서 데이터를 불러옴

캐시 미스 시 원본 데이터베이스에서 조회해서 반환하고, 캐시에 데이터를 적재함

 

캐시는 데이터베이스와 직접 통신하지 않고, 어플리케이션이 캐시의 모든 것을 관리함.

 

장점

실제 요청된 데이터만 캐시에 저장됨. 불필요한 데이터 캐싱을 줄일 수 있음

캐시에 문제가 발생해도, 원본 데이터베이스에 직접 접근해서 서비스가 계속 작동될 수 있음

단점

요청 초기에는 모든 요청마다 캐시 미스가 발생해 데이터베이스에 부하가 발생할 수 있음

캐시 미스가 발생한 경우만 데이터를 캐시에 적재하므로 원본 데이터베이스와 값이 다를 수 있다(캐시 불일치)

 

Cach Inconsistency(캐시 불일치) 해결법

원본 데이터베이스에 저장된 데이터와 캐시에 저장된 데이터가 서로 다른 상황

Write Through, Cache Invalidation, Write Behind 방식으로 캐시 불일치 해소

 

Write Through

원본 데이터에 대한 변경이 생긴 경우, 매번 캐시에 해당 데이터를 찾아 함께 변경

모든 데이터가 반드시 캐시를 거쳐 데이터 베이스에 기록되어 캐시는 항상 최신 데이터를 유지함

매번 갱신하는 것은 자원 낭비일 수 있으니, 캐시 만료 시간을 정해서 주기적으로 갱신하는 것을 권장함

 

캐시는 데이터베이스와 직접 연력되어 있음

 

Write Behind(Write Back)

원본 데이터 변경 요청이 생기면, 캐시를 먼저 업데이트한 후 원본 데이터를 변경함

디스크 쓰기 작업을 비동기 작업으로 수행해 성능을 개선할 수 있음

원본 데이터와 캐시가 일시적으로 일치하지 않을 수 있음

쓰기 작업이 빈번하고, 일시적인 캐시 불일치가 허용되는 서비스에서 유용함

 

Write Around

데이터를 데이터베이스에 직접 기록하고, 실제로 읽히는 데이터만 선택적으로 캐시에 저장함

데이터가 한 번 작성된 후 거의 읽히지 않는 경우에 적합함

(ex. 로그 기록이나 채팅방 메시지)

 

Read Through

캐시 미스가 발생하면 자동으로 원본 데이터베이스에서 읽어와 캐시에 저장함

동일한 데이터가 반복적으로 요청되는 읽기 중심 워크로드에서 효과적임

 

Cache Invalidation

원본 데이터에 대한 변경이 생기면, 캐시 데이터를 만료시킴

 

Time-based Invalidation(시간 기반 무효화)

특정 시간이 지나면 캐시된 데이터를 자동으로 무효화하고 새 데이터를 로드함

데이터의 변경 여부와 관계 없이 일정 시간이 지나면 캐시 무효화되므로, 실시간 반영은 아님.

 

Event-based Invalidation(이벤트 기반 무효화)

데이터가 변경되었을 때 즉시 캐시를 무효화

데이터가 업데이트되거나 삭제되면, 해당 데이터 관련 캐시를 삭제하거나 갱신함

캐시된 데이터의 정확성을 유지하지만, 구현이 복잡하고 실시간 캐시 관리를 고려해야 함.

---

이거 완전 운영체제 내용이잖어~!~

 

출처

[1] 매일메일. 250205. 캐싱 전략에 대해서 설명해주세요. 121번 https://maeil-mail.kr 

[1] 잘못된 캐싱 전략이 당신의 서비스를 망치고 있습니다. https://maily.so/devpill/posts/8do7dxleogq