인프런 커뮤니티 질문&답변
작성한 질문수
[수업 자료 질문] Cache Aside의 특징 문의
해결된 질문
작성
·
37
0
1. 현재 학습 진도
몇 챕터/몇 강을 수강 중이신가요?
6-4. 캐싱의 개념 3
2. 어려움을 겪는 부분
어떤 개념이 헷갈리시나요?
수업 자료를 보면 "Cache Aside는 구현이 간단하고 캐시 효율이 뛰어납니다. 하지만 데이터가 변경되었을 때 실시간으로 반영되지 않아 데이터 불일치 가능성이 있습니다."고 하는데,
왜 Cache Aside가 구현이 간단하고 캐시 효율이 뛰어난지 잘 이해가 가지 않습니다. Cache Aside에서는 애플리케이션 단에서 컨트롤을 다 해야 해서 구현이 길어지지 않나요? Cache Aside가 다른 전략과 비교했을 때 캐시 효율이 뛰어난 이유가 있을까요?
3. 시도해보신 내용
문제 해결을 위해 어떤 시도를 해보셨나요?
데이터 변경시 데이터 불일치에 대한 설명이 있는 것을 보면 혹시 해당 부분 설명은 Cache Aside보다는 Write Around Aside 에 대한 설명에 더 가깝지 않을까하는 생각도 해보았습니다.
답변 2
0
happyrichman님 좋은 질문 해주셔서 감사합니다!!!
정말 날카로운 관점이에요.
1. "구현이 간단하다"의 의미
여기서 "간단하다"는 코드 양이 적다는 뜻이 아니였습니다!! Read Through와 비교했을 때의 맥락입니다.
Read Through는 캐시 시스템 자체가 DB 조회와 저장을 자동으로 처리해줘야 하빈다. 이걸 구현하려면 캐시 미들웨어에 DB 연동 로직을 심어야 하고, 캐시 프로바이더가 이 기능을 지원해야 합니다. 즉, 인프라 레벨의 설정과 의존성이 필요합니다.
반면 Cache Aside는 그냥 Redis 하나만 띄워놓고, 애플리케이션 코드에서 조건문 몇 줄이면 바로 구현할 수 있어요. 별도의 캐시 프레임워크 설정이나 미들웨어 연동 없이도 동작합니다. 그래서 "진입 장벽이 낮다", "별도 인프라 의존 없이 바로 적용 가능하다"는 의미에서 간단하다고 표현해봤습니다!
2. "캐시 효율이 뛰어나다"의 의미
이건 Lazy Loading의 특성 때문이에요. Cache Aside는 실제로 조회 요청이 들어온 데이터만 캐시에 올라가요.
Write Through 같은 전략은 데이터가 변경될 때마다 캐시에도 저장하기 때문에, 한 번도 조회되지 않을 데이터까지 캐시 메모리를 차지할 수 있어요. 반면 Cache Aside는 누군가 실제로 읽은 데이터만 캐싱되니까, 캐시 공간을 효율적으로 사용하게 됩니다.
3. Write Around와의 관계
질문하신 부분이 정확히 맞아요. 사실 교재 설명의 "데이터가 변경되었을 때 실시간으로 반영되지 않아 데이터 불일치 가능성"은 Cache Aside 단독이 아니라 Cache Aside + Write Around 조합에서 발생하는 특성입니다.
Cache Aside는 읽기 전략이고, Write Around는 쓰기 전략인데, 실무에서는 이 둘을 자주 함께 사용해요. 교재 뒷부분에 나오는 "Cache Aside (읽기) + Write Around (쓰기) + TTL" 조합이 바로 그 예시죠.
이 조합에서는 쓰기 시 DB만 업데이트하고 캐시는 건드리지 않기 때문에, TTL이 만료되기 전까지는 캐시에 오래된 값이 남아있게 됩니다. 그래서 불일치가 발생할 수 있게 됩니다!
정리하면, 교재의 해당 설명은 Cache Aside가 가장 흔히 사용되는 조합(Write Around와 함께)에서의 특성을 함께 설명한 것으로 보시면 됩니다.
이런 식으로 전략들의 조합과 트레이드오프를 이해하시면, 면접에서 "왜 이 전략을 선택했는지" 설명하실 때 훨씬 설득력 있게 말씀하실 수 있을 거예요. 넘 좋은 질문 감사합니다!!!! 🥰
0
안녕하세요, 인프런 AI 인턴입니다. happyrichman님.
캐싱 전략에 대한 개념 중에서 Cache Aside 패턴과 관련하여 혼란스러워하시는 것 같습니다. Cache Aside 전략은 직접 애플리케이션에서 캐시를 제어하는 방식으로, 비교적 원리 자체는 간단하게 구현할 수 있는 구조입니다. 하지만 이 전략의 특성과 작동 방식을 명확히 이해하는 데 도움이 되도록 아래에 추가 설명을 드리겠습니다.
Cache Aside의 특징 및 장점
구현의 간단함:
- Cache Aside는 애플리케이션에서 데이터베이스와 캐시를 직접 갱신합니다. 이 과정은 애플리케이션 로직에 따라 제어되므로 다른 전략에 비해 처음부터 복잡한 설계가 필요하지 않습니다. 예를 들어, 읽기 요청이 오면 우선 캐시를 확인하고 데이터가 없으면 데이터베이스에 접근하여 데이터를 가져온 후, 이 데이터를 캐시에 저장합니다.
- Cache Aside는 애플리케이션에서 데이터베이스와 캐시를 직접 갱신합니다. 이 과정은 애플리케이션 로직에 따라 제어되므로 다른 전략에 비해 처음부터 복잡한 설계가 필요하지 않습니다. 예를 들어, 읽기 요청이 오면 우선 캐시를 확인하고 데이터가 없으면 데이터베이스에 접근하여 데이터를 가져온 후, 이 데이터를 캐시에 저장합니다.
캐시 효율성:
- 필요할 때만 데이터를 캐시에 가져와 쓴다는 점에서 캐시의 활용도를 증가시킵니다. 즉, 자주 접근하는 데이터만 캐시에 저장되며 불필요한 데이터까지 캐시에 저장하여 메모리를 낭비하지 않습니다. 이러한 세부적인 제어가 가능해 효율적이라 평가받습니다.
- 필요할 때만 데이터를 캐시에 가져와 쓴다는 점에서 캐시의 활용도를 증가시킵니다. 즉, 자주 접근하는 데이터만 캐시에 저장되며 불필요한 데이터까지 캐시에 저장하여 메모리를 낭비하지 않습니다. 이러한 세부적인 제어가 가능해 효율적이라 평가받습니다.
데이터 불일치 문제 및 해결
- 데이터 불일치 가능성:
- Cache Aside는 데이터베이스에 직접 변경이 발생한 경우, 변경된 데이터를 캐시에 반영하는 별도의 작업이 필요합니다. 예를 들어, 데이터베이스의 정보가 업데이트되었을 때 캐시에 남아있는 오래된 정보가 문제가 될 수 있습니다. 이를 방지하려면 데이터베이스에 변경이 있을 때 캐시를 직접 비우거나 일관되게 갱신해야 합니다.
- Cache Aside는 데이터베이스에 직접 변경이 발생한 경우, 변경된 데이터를 캐시에 반영하는 별도의 작업이 필요합니다. 예를 들어, 데이터베이스의 정보가 업데이트되었을 때 캐시에 남아있는 오래된 정보가 문제가 될 수 있습니다. 이를 방지하려면 데이터베이스에 변경이 있을 때 캐시를 직접 비우거나 일관되게 갱신해야 합니다.
기타 캐싱 전략과의 비교 내용은 그림에서 확인하실 수 있습니다. 각 전략의 장점과 단점을 고려하여 상황에 맞는 캐싱 전략을 사용하시면 좋을 것 같습니다.
이미지에서 설명된 각 전략의 특징을 자세히 살펴보세요:
- 캐싱 전략의 다양한 비교와 상황별 활용
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.