[Kotlin&Spring] 5기 로컬과 웹에서의 Cache

본격적으로 웹 개발에 대한 공부를 하게되었다

오늘은 전반적으로 알고 있어야 할 개념들을 강의를 통해 공부했다

그런데 캐시, 캐싱이라는 단어가 빈번하게 들려왔다

중요한 개념을 지나치고 싶지 않아서 캐시를 정리해보게 되었다

 

먼저 캐시라는 단어를 들었을 때 내가 가장 먼저 생각한 것은 캐시 메모리(Cache Memory)이다

캐시 메모리는 CPU와 메인 메모리(RAM) 사이에서 데이터를 일시적으로 저장하는 고속 메모리이다

캐시 매모리의 탄생 배경은 아래 저장 장치 계층 구도(Memory Hierarchy)에 의해서라고 할 수 있다

Memory Hierarchy

위 계층 으로 올라갈수록 CPU와 가깝고 용량은 작지만 빠르고 비싼 저장 장치이다

그리고 아래 계층으로 내려갈 수록 CPU와 멀고 용량은 크지만 느리고 저렴한 저장 장치이다

CPU가 메모리에 접근하는 속도는 레지스터에 접근하는 속도보다 느리다

그러나 CPU는 프로그램을 실행하며 메모리에 접근해야한다

CPU의 빠른 연산 속도가 메모리 접근 속도보다 빠른 상황에서 속도 차이를 줄이기 위해 캐시메모리가 등장했다

캐시 메모리는 CPU와 메모리 사이에 위치한 SRAM 기반의 저장 장치이다

 

캐시 메모리는 참조지역성의 원리(locality of reference)를 바탕으로 CPU가 자주 사용할 것으로 예측한 데이터를 저장한다

참조 지역성의 원리는 아래 두가지를 근거로 한다

1. 시간 지역성: CPU는 최근의 접근했던 메모리 공간에 다시 접근하려는 경향이 있다

한 프로그램이 실행되는 동안 CPU는 그 프로그램의 데이터가 적재된 곳(최근에 방문한 곳)을 다시 접근할 것이다

2. 공간 지역성: CPU는 접근한 메모리 공간 근처를 접근하려는 경향이 있다

한 프로그램 관련 데이터는 한 공간에 적재되기 때문에 똑같은 프로그램이 실행되면 CPU는 그 공간 근처를 접근할 것이다

하드웨어에 위치한 캐시 개념만으로는 웹의 캐시를 완전히 알기는 어려웠다

 

HTTP(Hyper Text Transfer Protocol)의 메소드 속성 중 하나는 캐시가능성(Casheable)이었다

이는 요청에 대한 응답을 재사용하기 위해 저장할 수 있는지 여부를 판단한다

그리고 캐시(Cache)는 클라이언트가 서버에 한번 요청했던 데이터에 대해서 매번 요청할 때마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하는 것이라고 한다

웹 브라우저의 캐시는 웹브라우저가 웹사이트의 데이터를 로컬 장치에 저장해 동일한 웹사이트를 다시 방문할 때 데이터를 재사용하도록 한다

HTTP는 주로 변경 가능성이 적은 정적 자원(Static Resouce)을 캐싱한다

정적 자원의 대표적인 예시는 HTML, CSS, 이미지, JS 등이 있다

일반적으로 조회하는 기능 GET 과 HEAD 메소드만 캐싱한다

GET 메소드는 리소스를 조회하는 기능을 하며 Query String(또는 Query Parameter)을 통해 서버에 데이터 전송도 할 수 있다

HEAD 메소드는 GET과 같이 리소스를 조회하지만 GET이 Message Body를 가질 수 있는 것과 다르게 반드시 Message Body가 없어야한다 

Datatracker RFC 7230

 

Datatracker 사이트의 인터넷 표준 문서에 따르면 위와 같이 응답 시간과 미래의 대역폭 사용량을 줄이고 효율적인 요청을 위해 Cacheable(캐시가능한) 응답을 저장한다고 Cache를 정의하고 있다

 

이때 캐시의 동작원리는 다음과 같다

1. 첫 방문시 데이터 저장

사용자가 웹사이트에 처음 접속하면 브라우저는 해당 웹사이트의 정적 리소스를 다운로드해 캐시 디렉토리에 저장한다

2. 다시 방문 시 캐시 활용

동일한 웹사이트를 다시 방문하면 브라우저는 캐시된 데이터를 활용해 필요한 파일을 재다운로드 하지 않고 빠르게 웹페이지를 로드한다

3. 변경 확인

웹사이트에서 캐시된 데이터가 변경되었는지 확인하기 위해 HTTP 헤더의 캐시 제어 및 Etag 등의 정보를 사용한다

파일이 변경되었으면 최신 데이터를 다운로드하고, 그렇지 않으면 캐시를 사용한다

 

캐시는 웹페이지의 로딩 속도를 향상시키고 네트워크 트래픽을 감소하는 장점도 있지만 단점도 존재한다

1. 웹 사이트가 업데이트되어도 오래된 데이터를 불러올 수 있다

2. 캐시 파일이 쌓여 로컬 저장 공간을 많이 차지할 수 있다

3. 개발자가 캐시를 무효화하지 않으면 사용자는 최신 데이터를 확인 못할 수 있다

4. 보안이나 사생활 관련 데이터가 저장돼 외부 접근에 노출될 수 있다

 

서버 측에서 캐시를 하는 방법도 있다

서버 캐시(Server Cache)는 서버에서 데이터를 미리 저장해 동일하거나 유사한 요청에 대해 빠르게 응답하는 기술이다

서버 캐시는 데이터베이스나 외부 API 호출 등의 처리를 줄이고 웹 어플리케이션의 성능을 최적화한다

 

서버 캐시의 동작 원리는 다음과 같다

1. 요청 수신

클라이언트가 서버에 데이터를 요청한다

2. 캐시 확인

서버는 먼저 캐시에 요청된 데이터가 있는지 확인한다

3. 캐시 히트(Cache Hit): 캐시메모리가 예측한 데이터가 사용되는 것

요청된 데이터가 캐시에 있다면 캐시에서 데이터를 반환한다

4. 캐시 미스(Cache Miss): 캐시메모리가 예측한 데이터가 쓰이지 않는 것

요청된 데이터가 캐시에 없으면 원본 데이터 소스(데이터베이스 등)에서 데이터를 가져와 응답한다

가져온 데이터는 캐시에 저장해 이후 요청에 대비한다

 

서버 캐시는 저장 데이터에 따라 여러 유형이 있다

1. 메모리 캐시(In-Memory Cache)

서버의 RAM에 데이터를 저장한다

매우 빠른 속도를 제공하며, 대표적인 도구로 Redis 와 Memscahed 가 있다

2. 디스크 캐시(Disk Cache)

데이터를 서버의 디스크(SSD/HDD)에 저장한다

메모리 캐시에 비해 느리지만 위 저장 장치 계층 구도 그림에서 볼 수 있듯이 더 큰 데이터를 저장할 수 있다

3. HTTP 캐시

HTTP 에서 제공하는 캐싱 매커니즘으로, 브라우저와 서버 간 데이터 요청을 최적화한다

Cache-Control, Etag 와 같은 HTTP 헤더를 활용한다

4. 역방향 프록시 캐시(Reverse Proxy Cache)

Nginx, Varnish 같은 프록시 서버를 사용하여 클라이언트 요청을 처리한다

요청을 서버에 전달하기 전에 캐시된 데이터를 제공한다

 

서버 캐시는 웹브라우저 캐시와 유사한 단점을 가진다

장점에는 응답 시간 단축, 서버 시간 단축 외에 다른 두가지 특징이 있어 정리해보았다

서버 캐시는 고트래픽 상황에서도 안정적인 응답을 제공하기 때문에 확장성이 향상된다

이는 오늘 강의에서 들은 Scale-out(수평적 확장) 개념과도 이어지는 것 같다

서버 캐시는 캐시된 데이터 사용으로 원격 데이터 요청을 줄여 네트워크 비용을 감소시킨다

아래 사진은 Google Cloud API 의 호출 당 가격 책정을 보여준다

최대한 요청을 줄이는 것이 수직적 확장(Scale-Up)이 일어나지 않을 것이다

Google Cloud API 가격 책정 정책

 

여러 캐시 개념을 정리하면서 결국 하드웨어 캐시 메모리로부터 출발했다는 것을 알 수 있었다

주된 공통점이 응답 속도와 결과를 빠르게 도출하는 것이었고, 또한 내부 매커니즘이 사용될 데이터를 예측해 저장하는 것이었다

프로그램을 실행하는 가장 효율적인 방법, 메모리와 성능에 관련해서 계속해서 고민하게 된다

아직은 웹 개발이 많이 어색하지만 점차 Spring Boot 등 프레임워크와 웹개발이 익숙해지면 지금의 고민이 유의미할 것이라고 믿는다

캐시 관련해서 의미를 어렴풋하게 알아서 조금 답답했는데 그래도 조금은 이해하게 되어서 마음이 편하다

차근차근 열심히 내 할 일을 하자 ~ 화이팅 ~

 

출처

https://datatracker.ietf.org/doc/html/rfc7230#autoid-8

RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

https://cloud.google.com/api-gateway/pricing?hl=ko

가격 책정  |  API Gateway  |  Google Cloud