7장: 분산 캐싱 — 삭제 정책부터 배치 전략까지

캐싱의 기본 개념

캐싱은 자주 사용하거나 계산 비용이 많이 드는 데이터를 더 빠르게 접근할 수 있는 위치에 저장하고 관리하는 기술이다. 용어부터 정리한다.

분산 캐싱(Distributed Caching) 은 여러 서버나 노드에 자주 사용하는 정보를 메모리에 분산 저장하는 기술이다. 핵심 목표는 명확하다. 디스크 기반 저장 시스템에서 데이터를 읽는 속도 문제를 해결하는 것.

일반 캐싱과 분산 캐싱의 차이

이 표에서 마지막 행이 분산 캐싱의 진짜 비용이다. 노드를 늘려 용량과 처리량을 얻는 대가로, "어느 노드의 값이 최신인가"라는 문제를 새로 얻는다.

활용 사례

• 웹 애플리케이션 — 사용자 세션, 페이지 구성 요소 등 자주 접근하는 데이터
• 데이터베이스 쿼리 결과 — 자주 실행하는 쿼리와 그 결과
• 콘텐츠 전송 네트워크 — 엣지 서버에서 정적 데이터 저장 및 제공
• API 응답 캐싱 — 백엔드 부하 감소, 반복 요청에 빠른 응답
• 실시간 분석 — 자주 조회하거나 집계한 분석 데이터
• 메시지 큐 — 중간 결과를 저장해 메모리 처리 시스템의 효율을 높인다

장점과 한계

장점은 예상 가능하다. 성능 개선, 확장 용이성, 백엔드 부하 감소, 장애 허용성, 일관된 접근 속도, 비용 절감, 사용자 경험 향상.

한계 목록이 더 중요하다.

• 일관성 유지 어려움
• 캐시 무효화의 복잡성
• 설정과 관리의 복잡성
• 네트워크 부하 문제
• 캐시 데이터의 오래됨(Staleness) 문제
• 데이터 분배의 어려움
• 높은 메모리 사용량과 비용
• 데이터 접근 패턴에 따른 효율 편차
• 쓰기 작업에서의 한계

분산 캐시 설계하기

책은 요구 사항 정의부터 시작해 실제로 분산 캐시를 설계하는 과정을 따라간다.

• 기능적 요구 사항 — put(key, value), get(key)
• 비기능적 요구 사항 — 높은 성능, 높은 확장성, 높은 가용성

캐시 삭제 정책

메모리는 유한하므로 무엇을 버릴지 결정하는 정책이 필요하다. 책은 두 계열로 분류한다.

삽입 순서 기반 (접근 시간을 고려하지 않음)

• 선입선출(FIFO, First In First Out)
• 후입선출(LIFO, Last In First Out)

접근 기반

LRU와 LFU의 차이를 구분해 두면 좋다. LRU는 최근성을, LFU는 총 빈도를 본다. 어제 100번 호출됐지만 오늘 한 번도 안 쓰인 키는 LRU에서는 버려지고 LFU에서는 남는다. 트래픽 패턴이 시간에 따라 급격히 바뀌는 서비스라면 LRU가, 인기 항목이 안정적인 서비스라면 LFU가 유리하다.

MRU가 목록에 있는 것이 의외로 보이는데, 순차 스캔처럼 "한 번 읽은 데이터는 다시 읽지 않는" 접근 패턴에서는 방금 쓴 항목을 버리는 것이 오히려 합리적이다.

LRU 캐시 설계

LRU는 가장 널리 쓰이는 정책이라 책도 구현을 따라간다. 핵심은 해시맵과 이중 연결 리스트를 결합하는 것이다.

해시맵은 키로 노드를 O(1)에 찾게 해 주고, 이중 연결 리스트는 그 노드를 리스트 맨 앞으로 O(1)에 옮기게 해 준다. 두 구조가 함께 있어야 조회와 갱신 모두 상수 시간이 된다.

동작 시 확인해야 하는 경우의 수는 두 가지다.

• 해시맵에 키가 있으면 — 값을 반환하고, 해당 노드를 리스트의 맨 앞(최근 사용)으로 이동한다
• 해시맵에 키가 없으면 — 원본에서 값을 가져와 삽입한다. 용량이 꽉 찼다면 리스트의 맨 뒤(가장 오래된 항목)를 제거한 뒤 삽입한다

캐시를 어디에 둘 것인가

설계의 마지막 결정은 캐시를 시스템에 어떻게 배치하느냐다. 책은 두 가지 방안을 제시한다.

방법 1: 애플리케이션 서버와 함께 배치

애플리케이션 프로세스 안이나 같은 호스트에 캐시를 두는 방식이다. 네트워크 홉이 없어 가장 빠르지만, 서버마다 캐시가 따로 존재하므로 서버 수가 늘어날수록 캐시 히트율이 떨어지고 서버 간 데이터가 어긋난다.

방법 2: 애플리케이션 서버와 독립적으로 구현

캐시를 별도 클러스터로 분리하는 방식이다. 모든 애플리케이션 서버가 같은 캐시를 공유하므로 히트율과 일관성이 좋지만, 네트워크 왕복 비용이 붙고 캐시 클러스터 자체를 운영해야 한다.

선택 기준으로 책이 나열하는 항목은 다음과 같다. 성능 요구 사항, 확장성, 자원 공유, 유연성, 의존성 및 독립성, 운영 복잡성, 인프라와 비용, 네트워크 지연 허용성.

마지막으로 앞서 정의한 요구 사항을 다시 꺼내 설계가 그것들을 만족하는지 점검한다. 이 "요구 사항 검토" 단계는 3부의 설계 실전 장들에서도 매번 반복되는 절차다.

대표 솔루션

가장 널리 쓰이는 두 가지를 소개한다.

레디스는 캐시를 넘어 다양한 역할을 소화할 수 있고, 맴캐시드는 단순하고 직관적인 키-값 캐시에 집중한다. 4장에서 본 확률적 자료구조 중 하이퍼로그로그가 레디스에 내장되어 있다는 점도 이 유연성의 사례다.

정리

이 장은 캐싱의 정의에서 시작해 분산 캐싱의 세부 사항, 설계 절차, 대표 솔루션까지 이어진다. 다루는 순서가 깔끔해서 캐싱이라는 주제를 처음 정리하기에는 좋다.

가장 실용적인 대목은 삭제 정책의 분류와 캐시 배치 전략 두 가지였다. 삭제 정책은 "무엇을 버릴지"를 결정하는 문제이고, 배치 전략은 "누가 그 캐시를 공유할지"를 결정하는 문제다. 두 결정이 캐시 히트율과 일관성 특성을 사실상 다 정한다.

반면 분산 캐시 자체의 일관성 유지 메커니즘, 즉 노드 간 동기화 프로토콜은 한계 목록에 이름만 올라가고 구체적으로 다뤄지지 않는다. 실제로 분산 캐시를 운영할 때 가장 골치 아픈 부분이 그쪽이라는 점을 감안하면 아쉬운 지점이다.