당신이 알아야 할 시스템 설계의 핵심 개념 20가지 - 2. 캐싱

1. 캐싱이란

캐싱이란 자주 사용되는 데이터의 복사본을 캐시 또는 임시 저장 위치에 저장하여 빠르게 접근할 수 있도록 하는 프로세스를 의미합니다.

왜 사용할까

클라이언트에서 서버에 데이터를 요청하거나 서버에서 DB의 데이터를 읽어오는 등 데이터를 받아올 때는 항상 일정 리소스가 소모됩니다. 그래서 원래의 데이터보다 더 빠르게 접근이 가능한 곳에 복사본을 위치시켜 리소스를 줄이고 응답 시간을 향상 시키기 위해 캐싱을 사용하게 됩니다. 보통 Redis를 활용하여 캐싱을 사용합니다. 

2. 캐싱 전략

1) 읽기 전략 (Read Strategies)

Look Aside

데이터를 찾을 때 캐시에 데이터가 있는지 먼저 확인한 후 만약 캐시에 데이터가 없으면 DB에서 조회하는 전략입니다. 읽기 작업이 빈번한 경우에 적합하지만 데이터의 변경사항을 캐시에도 반영하지 않으면 문제가 발생할 수 있습니다.

Read Through

데이터를 찾을 때 캐시에서 먼저 찾는단 점은 Look Aside와 동일합니다. 차이점은 캐시 미스가 발생했을 때 애플리케이션이 직접 DB를 조회하는 것이 아닌 캐시가 DB를 직접 조회한다는 차이점이 있습니다. 이는 캐시와 DB간 데이터 동기화가 항상 이뤄져 정합성 문제가 발생하지 않는단 장점이 있지만 속도가 느리다는 단점이 있습니다.

2) 쓰기 전략 (Writing Strategies)

Write Back

데이터를 저장할 때 DB에 바로 저장하지 않고 캐시에만 저장한 다음 일정 주기로 배치 작업을 통해 DB에 반영하는 방법입니다. 이는 DB의 쓰기 작업을 줄여주기 때문에 쓰기 작업이 빈번한 서비스에 적합합니다. 하지만 캐시에서 오류가 발생하면 DB에 반영되지 않은 데이터는 소실된다는 단점이 있습니다.

Write Through

데이터를 저장할 때 DB와 캐시에 동시에 저장하는 방식입니다. 이는 DB와 캐시를 항상 동기화 시키기 때문에 캐시의 데이터를 항상 최신 상태로 유지할 수 있습니다. 하지만 매 쓰기 요청마다 캐시와 DB 두 곳에 반영해야 하므로 성능이 느리다는 단점이 있습니다.

Write Around

앞의 두 방법은 쓰기 작업 시 항상 캐시에도 반영했습니다. 하지만 이 방법은 쓰기 작업을 DB에만 하고 캐시에는 반영하지 않습니다. 오직 캐시 미스가 발생할 때만 캐시에 반영합니다. 이는 쓰기 작업을 최적화 하며, 앞의 두 방법에 비해 불필요한 데이터가 캐시에 저장될 가능성도 줄여줍니다. 하지만 항상 처음 읽기 작업은 DB를 조회해야 하므로 초기 읽기 응답은 느릴 수 있다는 단점이 있습니다.

참고자료

EP160: Top 20 System Design Concepts You Should Know

EP160: Top 20 System Design Concepts You Should Know