프록시(Proxy), 프록시 캐시(Proxy cache), CDN(Content Delivery Network)

프록시(Proxy)

프록시는 원 서버를 대리하여 통신하며, 캐시, 로드밸런서 및 보안 등 중계역할을 하는 서버를 말한다.

프록시 서버가 중간에 위치하기 때문에 클라이언트를 프록시 서버를 '서버'로 인식하고 서버는 프록시 서버를 '클라이언트'로 인식한다.

이러한 프록시는 위치에 따라서 포워드 프록시(Forward proxy), 리버스 프록시(reverse proxy)로 나뉜다.

일반적인 프록시 서버는 포워드 프록시를 말한다. 이는 클라이언트와 서버 사이에서 클라이언트를 대리하여 클라이언트에서 서버로 리소스를 요청할 때 직접 하지 않고 프록시 서버를 거쳐서 요청한다.

로드밸런서(Load Balancer)

서버의 가용성(availability)를 높이기 위해서 하나의 서비스는 두 대 이상의 서버로 구성한다. 각 서버 IP주소가 다르므로 사용자가 서비스를 호출 시 어떤 IP로 서비스를 요청할 지 결정해야 한다.

사용자에 따라 호출하는 서버의 IP가 다른 상황에서 사용되는 것이 로드밸런서다.

캐시(Cache)

데이터나 값을 미리 복사해 놓는 임시 저장소를 말한다. 접근 시간에 비해 원래 데이터에 접근하는 시간이 오래 걸릴 경우, 값을 다시 계산하는 시간을 절약하고 싶을 때 사용한다.

브라우저에 캐시를 저장 시, 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있다. 이 때 60초로 설정하면 60초 간 해당 캐시가 유효하다는 의미가 된다. (캐시가 유효한 경우, 두번째 요청엔 캐시부터 조회하게 된다)

검증 헤더(Last Modified)

검증 헤더를 통해서 캐시의 수정시간을 알 수 있다. 캐시 유효시간이 초과되어도 If-Modified-Since 헤더를 통해서 조건부 요청이 가능하다.

데이터가 수정이 안되었을 경우 304 Not Modified로 나타난다. 

Cache-control : Max-age
캐시 유효 시간으로 초단위

Cache-control : no-cache
데이터는 캐시해도 되지만, 항상 원(Origin)서버에서 검증하고 사용

Cache-control : no-store
데이터에 민감한 정보가 있으므로 저장하면 안됨.

프록시 캐시

원서버와 클라이언트간의 거리가 멀어도 빠른 요청과 응답이 가능한 것은 프록시 캐시 덕분이다. 클라이언트에서 사용하고 저장하는 캐시를 'private 캐시'라고 하며 프록시 캐시 서버의 캐시를 'public'이라고 한다.

프록시 캐시 헤더
Cache-Control : public
응답이 public 캐시에 저장되어도 됨

Cache-Control : private
응답이 해당 사용자만을 위한 것. private 캐시에 저장해야 함(기본값)

Cache-Control : s-maxage
프록시 캐시에만 적용되는 max-age

Age : 60(HTTP 헤더)
오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

Cache-Control : no-cache
데이터는 캐시해도 되지만 항상 원서버에서 검증하고 사용

Cache-Control : no-store
데이터에 민감한 정보가 있으므로 저장하면 안됨

Cache-Control : must-revalidate
캐시 만료 후 최초 조회 시 원 서버에 검증해야함
원 서버 접근 실패 시 반드시 오류가 발생해야함 - 504(Gateway Timeout)

Pragma : no-cache
HTTP 1.0 하위 호환

no-cache

캐시 서버 요청을 하면 프록시 캐시 서버에 도착 시 no-cache인 경우엔 원서버에 요청을 하게 된다.

그리고 원 서버에서 검증한 다음 304응답을 하게 된다. 만약 프록시 캐시 서버와 원 서버 간 네트워크가 단절된다면 no-cache에서는 응답으로 오류가 아닌, 오래된 데이터라도 보여주자는 개념으로 200 OK 응답을 한다.

must-revalidate

원 서버에 접근 불가 시, 504 Gateway Timeout 오류를 보낸다. 통장 잔고 등 중요 정보가 원 서버를 못 받았다고 해서 에전 데이터로 뜬다면 문제가 발생하기 때문에 must-revalidate를 써야한다.

Content Delivery Network (CDN)

컨텐츠를 더 빠르고 효율적으로 제공하기 위해 등장했다. 세계 곳곳에 있는 데이터 센터에 컨텐츠를 저장해 두고 요청을 받으면 지리적으로 가장 가까운 데이터 센터에서 컨텐츠를 제공하는 방식이다.

CDN이 다루는 컨텐츠는 2가지다. 

1) 정적 콘텐츠
동영상, HTML 파일과 같이 변화가 거의 없는 컨텐츠, 개인화되지 않은 뉴스기사와 같은 것들이라 CDN의 캐시 센터에 저장하는 것이 적합하다.

2) 동적 콘텐츠
위치, IP주소 등 접근할 때마다 내용이 달라지는 콘텐츠다. 카드번호, 전화번호 등 개인화된 정보 관련 컨텐츠가 해당. 이 컨텐츠들은 내용이 바뀔 때마다 CDN 서버에도 변경 내용이 전달되어야 한다. 그래서 동적 컨텐츠는 CDN이 지원하기 어렵다. 그래서 동적 컨텐츠 자체를 저장하지 않고 공통적인 HTML을 저장한다.

CDN의 이점

- DDoS 공격에 대응 가능
- 로딩 속도 감소로 인한 사용자 경험 향상
- 트래픽 분산으로 비용 절감

CDN의 구성 방법 2가지.

1) Scattered 방식
최대한 빠른 응답속도를 목표, 세계 곳곳에 비교적 낮은 성능의 데이터 센터를 구성하고 연결. 데이터 센터 수가 많아 유지 비용이 높다. 그래서 클라우드 제공자는 관리 비용을 사용자에게 전가하여 사용 요금이 비싼 편이다. 그러나 수요가 적은 지역에는 유리하다.

2) Consolidated 방식
데이터 센터들을 통합하여 운용하는 방식으로 고성능의 데이터 센터들을 운용해야한다. 응답시간은 증가하지만, 데이터 센터의 수가 줄어들기 때문에 유지비용을 절감할 수 있다. 수요가 많은 지역이면 좋다.