캐싱 전략은 크게 읽기 전략과 쓰기 전략으로 나눌 수 있습니다. 읽기 전략에는 Look Aside(Cache Aside), Read Through 전략이 있고, 쓰기 전략에는 Write Through, Write Around, Write Back(Write Behind) 전략이 있습니다.
읽기 전략
Look Aside(Cache Aside) 방식은 캐시는 독립적으로 존재하고, 애플리케이션이 캐시와 데이터베이스 모두 직접 통신합니다. 캐시와 데이터베이스 사이에는 직접적인 연결이 없으며, 모든 캐시 및 데이터베이스 작업은 애플리케이션에서 관리합니다. 동작 방식에 대해서 설명하자면,
1. 애플리케이션이 먼저 캐시를 확인합니다.
2. 캐시 히트가 발생하면, 해당 데이터를 읽어서 바로 클라이언트에 반환합니다.
3. 캐시 미스가 발생하면, 애플리케이션은 추가 작업을 수행합니다. 데이터베이스에 쿼리하여 데이터를 가져오고, 이를 클라이언트에 반환함과 동시에 캐시에도 저장하여 동일한 데이터에 대한 후속 요청이 캐시 히트가 되도록 합니다.
이 방식은 캐시 클러스터가 다운되더라도 시스템은 데이터베이스에 직접 접근하여 계속 작동할 수 있기 때문에 캐시 장애에 대한 내구성이 좋다는 장점이 있습니다. 그러나 캐시와 데이터베이스 간에 데이터 정합성을 유지하기 어려움과 초기에는 대량의 캐시 미스로 인한 데이터베이스 과부하가 발생하는 단점이 있습니다. 데이터 정합성 문제는 보통 TTL(Time To Live) 설정으로 해결합니다.
Read Through 방식은 캐시와 데이터베이스가 직접적으로 통신하는 방식입니다. 캐시 미스가 발생하면 캐시에서 자동으로 누락된 데이터를 데이터베이스에서 가져와 캐시를 갱신한 후, 애플리케이션에 반환합니다. Look Aside 방식과 마찬가지로 지연 로딩 방식을 사용합니다. 즉, 데이터는 처음 요청받을 때 로드됩니다. Look Aside 방식과 비슷하지만, 두 가지 중요한 차이점이 있습니다.
1. Look Aside(Cache Aside) 방식은 애플리케이션이 데이터베이스 조회와 캐시 갱신을 직접 관리해야 합니다. 반면 Read Through 방식은 이러한 로직이 캐시 라이브러리나 독립 캐시 서비스에서 자동으로 처리됩니다.
2. Look Aside (Cache Aside) 와 달리, Read Through 캐시는 반드시 데이터베이스의 데이터 모델과 동일한 구조를 유지해야 합니다.
이 방식은 인기 뉴스 기사의 조회와 같은 동일한 데이터가 반복적으로 요청되는 서비스에서 효과적입니다. 다만 데이터가 처음 요청될 때는 반드시 캐시 미스가 발생하며, 이때 캐시를 채우는 추가적인 시간이 소요된다는 단점이 있습니다.
이 문제는 보통 캐시 워밍업 작업을 수행하여 해결합니다. 주요 데이터를 미리 캐시에 로드해 두는 것입니다. Look Aside(Cache Aside)와 마찬가지로 캐시와 데이터베이스 간의 데이터 불일치 문제가 발생할 수 있는데, 쓰기 전략들을 통해 해결할 수 있습니다.
쓰기 전략
Write Through 방식은 모든 데이터가 반드시 캐시를 거쳐 데이터베이스에 기록됩니다. 캐시는 데이터베이스와 연결되어 있으며, 모든 쓰기 작업은 캐시를 통해 메인 데이터베이스로 전달됩니다. 이러한 구조로 캐시와 데이터베이스 간의 데이터 일관성을 자연스럽게 보장합니다. 동작 방식에 대해서 설명하자면,
1. 애플리케이션이 데이터를 캐시에 기록합니다.
2. 캐시는 해당 데이터를 메인 데이터베이스에 기록합니다. 이 과정이 완료되면 캐시와 데이터베이스가 완벽히 동기화 된 상태가 됩니다.
이 방식이 단독으로 사용될 때는 데이터를 캐시와 데이터베이스에 순차적으로 기록해야 하므로 추가적인 지연이 발생합니다. 그러나 Read Through와 함께 사용하면 Read Through의 모든 장점과 데이터 일관성까지 보장받을 수 있습니다. 모든 쓰기 작업이 캐시를 통과하므로 별도의 캐시 무효화 처리가 필요하지 않다는 것도 장점입니다.
Write Around 방식은 데이터를 데이터베이스에 직접 기록하고, 실제로 읽히는 데이터만 선택적으로 캐시에 저장합니다. 이 방식은 특히 Read Through와 조합했을 때 효과적입니다. 데이터가 한 번 작성된 후 거의 읽히지 않거나 전혀 읽히지 않는 경우에 효율적입니다. 대표적인 예로 실시간 로그 기록이나 채팅방 메시지가 있습니다. Look Aside(Cache Aside)와도 잘 어울립니다.
Write Back(Write Behind) 방식은 애플리케이션이 캐시에 데이터를 기록하면, 캐시가 즉시 완료 응답을 보내고 나중에 비동기적으로 데이터베이스에 기록합니다. Write Through에서는 캐시에 기록된 데이터가 즉시 데이터베이스에 동기화는 반면, 이 방식에서는 동기화가 비동기적으로 이루어집니다. 따라서 애플리케이션 입장에서는 Write Back 방식의 쓰기 작업이 더 빠르게 느껴집니다. 응답을 반환하기 전에 캐시만 업데이트하면 되기 때문입니다.
쓰기 성능을 크게 향상시키고, 데이터베이스 장애에 대한 내구성이 좋다는 장점이 있습니다. 그러나 캐시 장애 시 데이터가 영구적으로 손실될 수 있다는 문제가 있습니다.
'백엔드 면접' 카테고리의 다른 글
| ACID에 대해서 설명해 주세요. (0) | 2025.01.13 |
|---|---|
| REST란 무엇인가요? (0) | 2025.01.10 |
| 동시성과 병렬성에 대해서 설명해 주세요. (0) | 2025.01.08 |
| 로드 밸런싱에 대해서 설명해 주세요. (0) | 2025.01.07 |
| 다중 서버 환경에서 세션 기반 인증 방식을 사용하는 경우 발생할 수 있는 문제점은 무엇이 있을까요? (0) | 2025.01.06 |