[ASAC 06] 캐시 1편 - 사용 목적과 위치에 따른 분류

이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.

 

 

웹 브라우저 성능 개선 및 웹 서버 부하 완화를 위하여 캐시와 프록시를 사용할 수 있다.

이번 글에서는 캐시에 대해서 알아보겠다.

Cache

캐시 사용의 목적

웹의 본질은 요청과 응답이다. 웹 브라우저는 웹 서버에게 요청을 하고 응답을 받으며, 웹 서버는 웹 브라우저의 요청에 따라서 응답을 만들고 반환한다. 응답은 HTTP Resource로 보통 웹 페이지, 영상, 음성, 이미지 등을 담고있다. 웹의 성능은 요청을 보냈을 때 가능한 빠르게 받는 것이며, 웹의 성능이 좋다면 웹 페이지 로드 시간을 단축시킬 수 있다.

 

하지만 매번 요청을 하고 응답을 받는 것은 힘들다. 요청을 하고 응답을 받을 때 네트워크 비용이 소모되기 때문에 비용적 측면에서 좋지 않다. 또한 매번 응답을 만들고 응답하는 것은 비효율적이다. 두 사례를 통틀어 시간이라는 비용이 소모되기도 한다.

 

응답이 매번 똑같은 경우, 캐시에 저장해놓으면 매번 물어볼 필요가 없다.

캐시에 있으면 HIT, 없으면 MISS
HIT 시 서버에 요청 X => WS의 부담이 없어진다.

 

결국 캐시 사용의 목적은 1. 비용 2. 속도 이다.
=> 결론적으로 웹 서버 부하 완화 및 웹 페이지 로드 성능 개선을 통해 유저 경험을 증진시킬 수 있다.  

 

웹의 성능은 SEO에도 영향을 미치기 때문에 캐시 사용은 매우 중요하다.

 

웹 브라우저의 캐시

웹 브라우저 : 결과 반환 비용(시간, NW)을 줄이자.

 

서버로의 요청에서 네트워크 트래픽 및 비용 발생 문제가 발생할 수 있고, 긴 대기시간을 가져야 한다.

같은 자료를 반복해서 요청하는 경우 이와 같은 문제를 반복해서 겪을 필요가 없다. 

 

브라우저에 캐시가 존재하는 경우 => 만드는 시간 0초, 전송 시간 0초

프론트엔드 개발자는 최대한 많은 자원을 캐싱해서 사용할 수 있도록 개발해야 한다.

 

결국 브라우저에서 캐싱은 다음과 같은 효과들을 얻을 수 있다.  

 

1. 네트워크 트래픽 감소
2. 유저 경험 증진

HTTP 캐시를 가지고 있는 주체는 브라우저이지만 웹 서버에서 Cache-Control 헤더 사용하여 제어된다.

웹 서버의 캐시

 

웹 서버 : 결과 생성 비용(노동, 자원)을 줄이자

 

서버에 캐시가 존재하는 경우 => 만드는 시간 0초, 전송 시간 3초

 

결국 서버에서 캐싱은 다음과 같은 효과들을 얻을 수 있다. 

1. 반복 연산 감소 : 매번 웹 페이지 만들 필요가 없다. (ex. 동적 웹 페이지를 생성하는 연산)
   • 서버 자원(CPU, Memory) 여유 = 반복되는 모든 유저의 요청 간단히 처리 가능
   • 불특정 다수의 웹 브라우저에게도 캐시된 자원 제공 가능
2. 트래픽 분산 : 웹 서버가 모든 요청 트래픽을 부담하지 않고, 캐시가 트래픽 분담을 하게 된다.
   • 부분 DDoS 방어 

Server Cache

서버 캐시 종류는 로컬과 글로벌로 나뉜다.

• 로컬 캐시 : LRU-Cache, Memcache, ECache
  • Least Recently Used = 가장 오랫동안 사용되지 않는 것 먼저 폐기한다. ex) 자바스크립트 웹 서버에서 사용된다.
• 글로벌 캐시 : Redis
  
  • Redis는 서버 캐시로, 데이터베이스에 가깝게 사용된다. Redis는 인메모리 기반의 NoSQL(Key-Value) DB로 속도가 뛰어나다는 장점이 있지만, 인메모리 기반이기 때문에 비용이 매우 비싸다.

서버 입장에서 DB는 영구적 저장소, 캐시는 일시적(반영구) 저장소라고 볼 수 있다.

캐시는 반영구적이기 때문에, 주기를 가지고 미사용 데이터를 지우거나 특정 상황에 지우도록 설정이 필요하다.

서버 캐시는 API 서버 자체를 캐싱하여 매 요청마다 응답을 만들지 않고 캐싱된 데이터를 응답하게 된다.  

 

서버 캐시는 다음과 같은 장점들을 가진다.

 

1. 서버 자원(CPU, Memory)의 여유
   • 반복되는 모든 유저의 요청을 간단히 처리할 수 있다. 
2. 불특정 다수의 웹 브라우저에게도 캐시된 자원 제공 가능

=> 저렴한 서버 비용. 서버리스와 같이 요청 단위로 요금이 산정되는 경우 캐싱해둔 데이터를 사용하게 되면, 서버 비용의 감소 

 

또한 서버 캐시는 세션 인증 방식에서 사용되기도 한다. 서버에 세션을 저장하는 대신, 서버 캐시에 세션을 저장하는 것이다. 세션 인증 방식에서 서버 캐시를 사용하는 이유는 다음과 같다.

 

1. 서버를 Scale-Out 했을 때 세션을 분산된 서버에 저장하는 경우 세션 관리와 관련하여 여러 문제가 발생한다.
2. 서버 자체에 문제가 생기는 경우 저장된 세션에 영향을 미친다.

그렇기 때문에 세션 인증 방식에서 서버에 세션을 저장하는 대신 Redis와 같은 글로벌 서버 캐시를 사용하는 것이 좋다. 

 

HTTP Cache

Cache

 

캐시가 존재할 수 있는 위치는 3군데이다.

1. 웹 브라우저 (private) - HTTP Cache
2. 프록시 (public) - HTTP Cache
3. 서버 - Server Cache

 

위 그림에서 HTTP Cache에 해당하는 부분은 노란색으로 표시된 부분만이다. 빨간색 부분은 Server Cache로 웹 서버에서 사용하게 되는 캐시이다.

 

HTTP Cache 데이터를 캐시하는 곳은 크게 두 곳으로 나뉜다.  

• Private
  => Private Cache에는 개인적인 데이터를 저장한다.
• Shared
  => 모두가 공유해도 상관 없는 경우에 Shared Cache를 사용한다. 이 공간은 다른 웹 브라우저에서도 모두 볼 수 있다

Private Cache

Private Cache는 웹 브라우저에 위치한다. 웹 브라우저 캐시는 해당 브라우저만을 위해 사용되며, 다른 브라우저에서는 해당 브라우저의 캐시에 대해서 알 수 없다.

브라우저 캐시는 웹 서버가 HTTP Cache 헤더 (Cache-Control) 를 통한 제어를 하게 된다. 

Shared Cache

Shared Cache는 웹 브라우저와 웹 서버 사이 프록시에 위치한다. 모든 웹 브라우저를 위해 캐시가 사용되며, 예로는 가장 많이 사용하는 Reverse Proxy, CDN 등이 있다. 

 

• 프록시 캐시
  •  "웹 서버가 HTTP Cache 헤더" (Cache-Control) 를 통한 "제어"
• 관리형 캐시
  • "서비스 개발자(사용자)"가 "직접 정책 제어", 배포, 캐싱할 데이터를 직접 업로드로 관리
    프록시 캐시와 관리형 캐시의 구분은 Cache-Control 헤더를 통해 제어하느냐 직접하냐의 여부
    관리형 캐시의 대표격 => Reverse Proxy, CDN
    관리형 캐시도 프록시 캐시의 기능을 충분히 수행할 수 있다.
    관리형 캐시 = 프록시 캐시 + 사용자의 제어
  • nginx, apache 등을 관리형 캐시로 사용 가능하다. 
  • 만약 nginx를 관리형 캐시로 사용하는 경우에, HTTP Cache 헤더가 아닌 nginx의 내부 기능을 통해서 캐시를 제어하게 된다. 

•  

HTTPS를 적용하는 경우의 프록시

이 경우 요청-응답의 주체가 3개가 된다.

=> 1. 웹 브라우저 2. 프록시 3. 웹 서버

 

HTTPS는 HTTP에 TLS(SSL)을 적용한 것으로, TLS(SSL)은 보안(서버와 브라우저 간의 신뢰할 수 있는 연결)을 위한 핸드셰이크 과정이다. 

웹 브라우저와 웹 서버 사이에 프록시가 존재하지 않는 경우에는 TLS(SSL) 암복호화를 웹 서버가 하게 된다.

 

웹 브라우저와 웹 서버 사이에 프록시가 존재하지 않는 경우 에는 방식이 두가지가 있다.

 

1. TLS(SSL) Termination (Offloading)

• TLS(SSL) 암복호화를 프록시에서 하게 되고, 프록시는 서버로 복호화된 데이터를 전달한다.
• 웹 브라우저와 서버 간에는 TLS(SSL)가 적용되어야 하지만 프록시와 서버, 로드 밸런서와 서버 간에는 TLS(SSL)이 적용될 필요가 없기 때문에 TLS(SSL) Termination이 가능하다. 
• L7 로드 밸런싱이 가능하다. 프록시 뿐만 아니라 로드 밸런서에서도 TLS(SSL) Termination이 가능. 
• CT : TLS Certificates 발행 적합성 투명 공증 로깅
  • TLS(SSL) Termination에서는 CT(Certificate Transparency) 통해 Outdated(Expired) 캐시 방지 가능

2. TLS(SSL) Passthrough

• TLS(SSL) 암복호화를 서버에서 하게 되고, 프록시는 서버로 암호화된 데이터를 복호화하지 않고 그대로 전달한다.
• 모든 서버가 Private Key를 가지고 있어야 하는 단점을 가진다.

https://blog.naver.com/n_cloudplatform/222175960924

[네이버클라우드 기술&경험] SSL이 적용된 로드밸런서에서의 호스트 기반 라우팅 동작 방식

https://medium.com/@reach2shristi.81/ssl-tls-termination-b7cc7de3eb54

SSL/TLS termination

https://letsencrypt.org/ko/docs/ct-logs/

인증서 투명성(CT, Certificate Transparency) 로그 - Let's Encrypt - 무료 SSL/TLS 인증서