[Network] CDN - 캐시 서버로 빠르게 로드하기

🌱 CDS (Content Delivery Service)

만약, 내가 배포한 서버가 한국에만 존재하지만 전세계 다양한 곳에서 액세스되고 있다고 생각해보자.

수많은 파일과 데이터에 대해 전세계에 응답해야 하는 상황에서, 멀리 있는 국가의 사용자와 대해서 전달해야 한다면?

한국 사용자에게는 빠르게 전달할 수 있지만, 멀리 있는 사용자의 요청을 받아서 한국에서 처리하고, 또 다시 데이터를 곳곳에 존재하는 사용자에게 전달해야 하기 때문에 어느 정도 지연이 발생할 수밖에 없다.

 

이러한 상황에서 다수의 캐시 서버를 여러 개의 지역에 배치하여 트래픽을 분산시키는 방법이 필요하다!

그렇다면 캐시 서버는 어디에 둬야 할까?

 

1. 웹 서버 직전에 두기

웹 서버 직전에 두게 되면 서버 자체의 부하는 줄어들게 되지만, 인터넷에서 흐르는 트래픽을 조절할 수 없다.

 

2. 클라이언트 측에 두기

1번의 경우와 달리, 인터넷에 흐르는 트레픽을 억제할 수 있다.

그래서 대용량 데이터를 포함하는 컨텐츠라면 클라이언트 측에 두는 것이 더 좋다.

하지만, 웹 서버 운영자가 제어 불가능하고, 클라이언트가 정말 캐시 서버를 가지고 있는지 단정할 수가 없다.

(보통 웹 서버 측에서는 클라이언트의 정보를 완전히 믿어서는 안 된다.)

 

3. 인터넷 주위에 두기

프로바이더와 계약하여 서버 운영자가 제어할 수 있는 캐시 서버를 프로바이더에 두는 것이다.

이렇게 되면 인터넷에서 흐르는 트래픽도 제어할 수 있으며, 서버 운영자가 캐시 서버를 제어할 수 있게 된다.

하지만, 서버 측에서는 인터넷의 어느 측에서 액세스하는지 알 수 없기 때문에 POP (point of presence, 인터넷 액세스 포인트) 전부에 캐시 서버를 설치해야 돼서 현실적으로 불가능하다. 이를 해결하기 위해서 보통은 중요한 프로바이더 위주로 캐시 서버를 두어 캐시 서버를 줄이는 방법을 사용한다. 

 

이렇게 하면 할 수는 있지만, 비용적으로 많이 들기 때문에 캐시 서버를 설치하고 웹 서버 운영자에게 대출하는 서비스를 제공하는 운영자가 담당하게 되었는데, 이를 CDS (Content Delivery Service) - 콘텐츠 배포 서비스라고 한다.

CDSP (CDS를 제공하는 사업자)는 중요한 프로바이더와 계약하고, 그곳에 여러 개의 캐시 서버를 설치하면서, 동시에 웹 서버 운영자와도 계약하여 웹 서버와 캐시 서버 사이를 연결해주는 역할을 한다.

 

= 결과적으로 사용자의 요청에 대해서 실제 서버가 아닌 캐시 서버가 응답하도록 만드는 것!

ex) AWS의 CloudFront가 대표적인 제공 서비스 중 하나이다.

+ 보통은 'CDN'이라는 명칭을 많이 사용하기 때문에 아래에서도 그렇게 부르겠다.

 

💬 CDN을 사용하면 무엇이 좋을까?
- 페이지 로드 시간 단축
- 대역폭 비용 절감 (원본 서버의 제공 데이터 양을 줄이게 되니까)
- 콘텐트 가용성 (더 많은 트래픽 처리 가능)
- 웹 사이트의 보안 강화 (DDoS 공격도 분산시키니 조금 더 강함)

💬 보통 언제 사용할까?
- 빠르게 컨텐츠를 전송해야 할 때 (뉴스 같은...?)
- 실시간 스트리밍
- 동시 사용자가 많은 경우

 

기본적으로 CDN의 경우 사용자가 웹 브라우저에 요청을 보내면 (클라이언트의 요청이 서버로 오게 되면) 원본 서버로부터 컨텐츠를 가져와 유저에게 전송한 동시에 캐시 서버에 저장한다. 그리고, 이후에 발생한 요청의 경우 '가장 가까운' 캐시 서버에게 액세스하도록 만든다.

💡 '가장 가까운 캐시 서버를 찾아내고, 그곳에 액세스한다'

이 말은 어디에서 들어본 것 같지 않은가? 바로 DNS 서버에서 IP 주소를 찾아내는 과정이다.

위의 그림을 보자. 위에 써있는 MAC, IP 같은 정보는 클라이언트의 조회 메시지이다.

클라이언트 측의 DNS 서버는 클라이언트와 같은 장소에, 라우팅 테이블을 입수한 라우터는 캐시 서버의 설치 장소에 있다고 가정해보자.

 

이때, 가장 가까운 캐시 서버를 찾아내기 위해서 먼저 서버 측의 DNS 서버는 캐시 서버에 있는 라우터로부터 라우팅 테이블을 받게 된다.

라우팅 테이블의 정보를 조합하다 보면 어떠한 라우터 A -> 프로바이더 X -> 프로바이더 Y -> 클라이언트 측 DNS 서버... 이런 식으로 경로에 대한 정보를 알 수 있기 때문에 대략적인 거리 정를 파악할 수 있게 된다.

 

서버 측 DNS 서버는라우터 개수만큼 라우터 테이블을 가지고 있게 되며, 이러한 경로 정보와 받은 송신처 IP 주소를 통해 캐시 서버와 클라이언트 측의 DNS 서버 사이의 거리를 조사하여 가장 가까운 캐시 서버의 IP 주소를 찾는다. (모든 라우터 정보에 대해 비교하여 가장 가까운 라우터 찾기)

 

---

 

🌱 리다이렉트 활용하기

가장 가까운 캐시 서버에 액세스하기 위해 또 다른 방법을 사용할 수 있는데, 'Location'이라는 HTTP 헤더를 사용하는 것이다.

Location 헤더에 담긴 리소스 위치로 이동하여 가까운 서버로 이동해나가는 것이다.

그리고, 이렇게 이동하는 과정을 '리다이렉트'라고 한다.

 

리다이렉트를 통해 가장 가까운 캐시 서버를 클라이언트에 통지할 때는 리다이렉트용 서버를 웹 서버측의 DNS 서버에 등록하게 되며, 클라이언트는 DNS 서버에 등록된 정보를 바탕으로 HTTP 리퀘스트를 보내게 된다.

그러면 리다이렉트 서버 역시 DNS 서버처럼 경로 정보를 모아 가장 가까운 캐시 서버를 찾게 된다.

해당 캐시 서버를 나타내는 경로를 Location 헤더에 넣어 응답을 전송해주면 클라이언트는 해당 정보를 바탕으로 캐시 서버에 액세스하게 된다. 또한, Location 헤더 외에도 패킷의 왕복 시간 같은 정보를 두어 시간 정보를 바탕으로 최적의 캐시 서버에 액세스 하도록 만들 수 있다.

 

사실 거의 비슷하지만, 첫 번째 방법은 가장 가까운 캐시 서버의 IP 주소를 반환해서 해당 캐시 서버에 접속하는 느낌이고...

두 번째 방법은 HTTP 메시지를 별도의 서버로 보내서 해당 서버에서 경로 정보를 계산하여 헤더 값으로 받는 느낌...?

첫 번째 방법은 http 이전 단계인 것 같고, 두 번째 방법은 http 메시지를 통해 얻는 것 같은데 헷갈린다.

 

---

 

🌱 캐시 정보는 언제 갱신하지?

캐시 관련 이야기에서 가장 중요한 점 중에 하나이다.

기존에는 한 번 액세스한 데이터를 두 번째 액세스 시 반환하도록 하는 방법이 있었는데 (ttl 고려) 이 역시 기존 데이터와의 정합성을 보장해줄 수 없기 때문에, 웹 서버에서 기존의 데이터를 갱신할 경우 캐시 서버와 동기화를 진행해야 한다.

이러면 항상 캐시 서버의 데이터가 최신이라는 것을 보장할 수 있으며, CDN의 캐시 서버는 이에 대한 방법이 내장되어 있다.

 

예를 들어, 앞서 말했던 AWS CloudFront의 경우 기본적으로 파일의 캐시가 24시간 정보 유지된다.

HTTP 헤더의 Cache-Control 헤더를 통해서 캐시의 유지 시간을 설정할 수 있지만, 개발자가 직접 캐시가 만료되기 전 파일 내용을 갱신할 수 있는 'Invalidation'이라는 기능을 제공하고 있다.

http://blog.a-cloud.co.kr/2020/01/23/invalidation%EC%9C%BC%EB%A1%9C-cloudfront-%EC%BD%98%ED%85%90%EC%B8%A0-%EA%B0%B1%EC%8B%A0%ED%95%98%EA%B8%B0cache-control/

 

또한, 캐시 규칙을 찾아보았는데 기본적으로 CDN의 캐시 정책은 HTTP에 따르는 것 같다.

Cache Rules_Content Delivery Network_User Guide_Domain Name Settings_Cache Settings_Huawei Cloud

You can control cache aging by configuring the Cache-Control: max-age field in an HTTP response header. By leveraging cache rules, you can optimize cache periods for different services. 

애초에 개발자가 캐싱에 대한 규칙을 정할 수 있는 것처럼 보인다.

---

💡 퀴즈
Q. 현재 주류가 되어 있는 방화벽의 유형이 무엇일까?
A. 패킷 필터링형

Q. 방화벽에서 애플리케이션 종류를 지정할 때 점검하는 정보는?
A. 포트 번호

Q. 웹 서버의 부하를 막기 위해 액세스를 여러 대의 서버에 분배하는 장치는?
A. 로드 밸런서

Q. 서버 측에 설치하는 프록시는 무엇일까?
A. 리버스 프록시

Q. 인터넷에 다수의 캐시 서버를 설치하고, 웹 서버 운영자에게 대출하는 서비스는?
A. CDS