[컴퓨터공학] Cache, Caching

yooni·2022년 2월 21일

Cache 컴퓨터공학

📌 References
https://aws.amazon.com/ko/caching/
https://mangkyu.tistory.com/69

1. Hardware 측면에서의 캐싱

일시적인 데이터 하위 집합을 저장하는 고속 데이터 스토리지 계층으로, 캐싱을 사용하면 이전에 검색/계산한 데이터를 빠르고 효율적으로 재사용할 수 있다. (데이터나 값을 미리 복사해놓는 임시 장소)

디스크 캐시
하드디스크에 접근하는 시간을 개선하기 위해 RAM에 저장하는 기법
캐시 메모리
CPU 칩 안에 있는 작은 메모리로, RAM보다 더 빠르게 접근이 가능하며 저장 공간이 작고 비용이 비싼 대신에 빠른 성능을 제공한다.

📈 Long Tail 법칙 (20%의 요구가 시스템 리소스의 대부분을 사용한다.)

이 20%에 caching를 이용하여 리소스 사용량을 대폭 줄이고 성능을 향상시킨다.

2. Web Service(Browser) 측면에서의 캐싱

네트워크에서 오고가는 데이터의 양을 줄이는 방향으로 발전해왔다. 자주 바뀌지 않지만 매번 요청되는 정보들(이미지, 폰트, CSS, 유저 정보 등)을 클라이언트 단에 저장하여 캐시로 활용한다.

서버에서 관계형 DB에 자주 요청을 하다보면 비용이 매우 높아지기 때문에, 쿼리 요청도 한번 실행하고 결과를 클라이언트 단에 저장해둔다.

2-1. 브라우저 캐시 사용 과정

기본적으로 response http message header 내에 cache-control 속성을 이용하여 캐시가 유효한 시간을 지정하여 설정한다.

캐시 기본 원리 및 적용

첫 번째 요청
응답의 cache-control 설정에 따라 브라우저 캐시에 해당 응답 결과를 저장한다.
재요청
재요청에서 유효한 캐시라면 해당 캐시에서 데이터를 가져오고, 유효시간이 초과한 경우에는 다시 서버에 요청을 하고 데이터를 다시 다운로드하여 캐시에 저장한다. 이 때 캐시 유효시간이 다시 초기화된다.

📃 Cache-Control

Cache-Control: max-age (캐시 유효시간, 초 단위)

Cache-Control: no-cache (캐시는 가능하지만, 항상 원 서버에 검증하고 사용 / max-age가 0인 상태)
원 서버 접근 불가시 임의로 프록시 서버에서 오래된 데이터라도 이용하라고 응답한다.

Cache-Control: must-revalidate (캐시 만료 후 최초 조회시 원 서버에 검증해야 함)
원 서버 접근 불가시 504 Gateway Timeout 오류를 내보내 이용할 수 없게 한다.

Cache-Control: no-store (민감한 데이터가 있어 캐시 저장 불가능)

Pragma: no-cache (http 1.0에서 쓰던 컨트롤, 하위호환이기 때문에 사용 가능)

❗️ 클라이언트가 캐시를 적용하지 않아도 임의로 브라우저가 캐시를 적용하는 경우 이를 무효화 하기 위해서는 다음과 같은 캐시 지시어를 사용할 수 있다.

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache

❓ 유효시간이 지난 캐시를 재사용하기 위해서는?

캐시 유효시간은 지났지만, 데이터의 변경이 없어 해당 데이터를 써도 되는 상황이 있을 수 있다.

✉️ 검증 헤더와 조건부 요청 1 - Last-Modified, If-Modified-Since

클라이언트는 첫 응답시 서버가 보내준 검증 헤더 Last Modified에 저장된 값을 이용하여 데이터 재요청시 If-Modified-Since를 요청 헤더에 포함시키고 응답으로 다시 들어온 헤더의 Last Modified를 확인한다.

이 방식은 서버에서 별도의 캐시 로직을 관리하고 싶은 경우(베타 버전 관리를 위해 서버에서 원하는 시점에만 캐시를 업데이트시켜주고 싶을 때)에 비효율적일 수 있다.

✉️ 검증 헤더와 조건부 요청 2 - ETag, If-None-Match

검증 헤더 Last-Modified 대신 ETag(Entity Tag)를 사용한다. 캐시용 데이터에 임의의 고유한 버전 이름을 달아두고, 데이터가 변경되면 Hash를 다시 생성하여 ETag를 변경한다. ETag를 주고 받아서 같으면 데이터를 유지, 다르면 다시 다운로드 받는 방식이다.

이 방식은 캐시 제어 로직을 서버에서 온전히 관리할 수 있으며, 클라이언트는 캐시 매커니즘에 접근할 수 없다.

2-2. 그렇다면 브라우저 캐시는 어디에 저장될까?

브라우저 캐시 데이터는 일반적으로 하드디스크(HDD)에 저장된다. 하지만 I/O 시간이 길어 처리가 느리기 때문에 더 빠른 처리를 위해 웹코어 내부에 바로 접근할 수 있는 메모리 캐시를 사용할 수도 있다.

from disk cache (RAM)
from memory cache (L1, L2, L3)

2-3. 프록시 캐시 (Proxy Cache)

프록시 (Proxy)
클라이언트와 서버 사이에 대리로 통신을 수행하는 것. 보안/캐싱을 통한 성능 향상 및 트래픽 분산의 장점을 갖는다.
Public Cache 프록시 캐시 서버의 캐시
Private Cache 클라이언트에서 사용하고 저장하는 캐시

2-4. Browser 캐싱 사용의 장점

애플리케이션 성능 개선
메모리는 디스크보다 훨씬 속도가 빠르다.
데이터베이스 비용 절감
단일 캐시 인스턴스는 수십만 IOPS(초당 입출력 작업)를 제공할 수 있어 수많은 DB 인스턴스를 대체할 수 있다.
백엔드 부하 감소
데이터베이스의 로드를 줄이고 로드시 성능이 저하되거나 작동이 중단되지 않도록 보호할 수 있다.
예측 가능한 성능
데이터베이스 로드가 급증하면 전반적 애플리케이션 성능 예측이 불가능해진다. 고성능의 메모리캐시가 이 문제를 완화한다.
데이터베이스 핫스팟 제거
특정 데이터가 나머지에 비해 자주 액세스될 때 발생할 수 있는 데이터베이스에 핫스팟을 방지한다.
읽기 처리량 증가
디스크 기반 데이터베이스에 비해 훨씬 높은 요청속도(IOPS)를 제공한다.