분산 캐시는 여러 앱 인스턴스가 네트워크로 데이터를 재사용하게 합니다. 비싼 작업의 반복을 줄이는 것이 목적이며, 최신성과 장애에 대한 규칙이 분명해야 합니다.
백엔드 세 개가 같은 상품 목록을 읽는다고 합시다. 프로세스 내부 캐시는 각각 사본을 관리합니다. 공유 캐시 서비스에서는 한 인스턴스가 채운 값을 다른 인스턴스도 씁니다. 캐시 서비스 자체도 여러 노드로 구성될 수 있습니다.
데이터 생성 비용과 허용할 오래된 정도부터 확인합니다. 상품 설명은 짧은 지연이 괜찮아도 구매의 최종 재고 확인에는 원본이 필요할 수 있습니다.
테넌트, 언어 등 관련 입력을 포함해 전체 결과를 식별하는 키를 정합니다. 그렇지 않으면 빠른 캐시가 다른 고객 데이터를 반환할 수 있습니다. 캐시 값은 사라질 수 있으므로 영구 업무 기록의 권위는 데이터베이스에 둡니다.
일반적인 cache-aside는 앱이 캐시를 확인하고, 없으면 DB를 읽은 뒤 TTL이라는 만료 시간과 함께 저장하는 방식입니다.
Request -> Cache -> hit -> Return value
-> miss -> Database -> Fill cache -> Return value
같은 값이 필요한 요청이 많으면 반복 DB 읽기를 줄입니다. 하지만 네트워크 호출과 의존성이 추가되므로 절약하는 작업이 그 비용보다 커야 유용합니다. Redis cache-aside를 참고합니다.
카탈로그에서는 DB 갱신을 커밋한 뒤 상품 캐시를 무효화하는 것이 실용적인 시작점입니다. 다음 읽기가 새로 채웁니다. 하지만 경쟁은 남습니다. 읽는 쪽이 커밋 전 오래된 값을 가져와 무효화 후 캐시에 넣을 수 있습니다.
TTL은 새로 저장된 사본의 수명을 제한할 뿐, 모든 읽기가 즉시 최신 쓰기를 본다고 보장하지 않습니다. 오래된 권한, 가격, 잔액이 규칙을 위반한다면 원본을 검증하거나 버전을 고려한 갱신에 명확한 보장을 설계합니다. Redis가 해결한다고 가정하지 말고 업무 동작에 맞춰 일관성을 선택합니다.
인기 값이 만료되면 많은 요청이 동시에 DB를 읽을 수 있습니다. 캐시 스탬피드입니다. 캐시 장애는 여러 값에서 같은 문제를 일으킵니다.
이 경로를 의도적으로 시험합니다. 정상 상태의 높은 적중률만으로 캐시가 사라졌을 때의 동작은 알 수 없습니다.
샤딩은 키를 노드로 나누고 복제는 가용성이나 읽기용 사본을 유지합니다. 해결하는 문제가 다릅니다. Redis Cluster는 해시 슬롯을 사용하므로 노드 추가가 한 핫 키의 작업을 자동 분할하지 않습니다. Redis Cluster 명세를 참고합니다.
적중률, 지연, timeout, 메모리, 축출, DB 유입 부하를 봅니다. 축출은 메모리를 관리하려고 값을 제거하는 것이며 TTL 전에도 일어납니다. 캐시 항목을 업무 데이터나 대기 작업의 영구 저장 보장으로 취급하지 않습니다.
카탈로그는 명확한 키의 cache-aside, 최신성 정책, 보호된 대체 경로로 시작하겠습니다. 분산으로 실제 해결할 용량 문제가 측정된 뒤 노드를 추가하겠습니다. 좋은 캐시 설계는 값이 있을 때뿐 아니라 없거나 틀렸을 때의 동작도 설명합니다.
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기