Cloudflare로 알아보는 CDN

서문

이 글을 찾아온 독자라면 Cloudflare를 들어봤을 것이다.

지루하고 현학적인(?) 설명을 하자면, CDN은 Content Delivery Network의 앞글자를 따온 것이다. CDN(콘텐츠 전송 네트워크)은 전 세계 여러 서버에 웹 콘텐츠를 캐싱하여 사용자에게 지리적으로 가까운 서버에서 빠르게 데이터를 제공하는 시스템이다. 이를 통해 웹사이트의 로딩 속도 향상, 서버 부하 감소, 장애 대응 능력 강화 등의 이점을 제공한다.

본인이 사이트를 운영하며, 이 사이트에 보여줄 내용이 많다고 하자. 여기엔 웹페이지(동적 HTML), 이미지, js, css 파일 등 여러가지가 있을 것이다.

이제 서버가 미국 서부에 있고, 접속자가 미국 동부에 있다고 하자. 그러면 거진 80ms의 핑이 나온다. 이 상태에서 중간 경유 회선이 포화 상태면 이미지 로딩에 한세월이 걸려서 최악의 사용자 경험을 만들어 낼 것이다.

한국인은 잘 와닫지 못하겠지만... 지리적 거리 때문에 같은 미국 서부라고 해도 남쪽-북쪽 간의 핑(RTT)이 한국-일본 핑(RTT) 보다 더 높다.

CDN업체는 전세계 주요 지점마다 중계 서버를 운영한다. 그리고 사용자들을 가장 괜찮은 지점으로 접속하게 한다. 다시 말해서, CDN은 자신이 중계 서버인것 마냥 행동한다. 사용자는 CDN에 접속한다. 그리고 CDN이 실제 웹 사이트로 접속한다.

중계 서버를 끼면 느려지지 않나..?

한국 내에 서버를 둔 상황이라면, Cloudflare를 비롯한 CDN 서비스가 TTFB에 악영향을 미친다. 하지만 수십~수백ms 정도는 일반 사용자가 체감하기 어렵다. 그렇기에 별 문제가 없다

특히 Cloudflare Enterprise를 쓰는게 아닌 이상 요청이 해외로 나간다. 홍콩, 일본, 미국을 중계 서버로 사용할 것이므로 반응속도는 더 느릴 것이다.

하지만 서버가 외국에서 외국이라면 말이 달라진다. 본인이 사용하는 인터넷 회사(ISP)와 서버가 사용하고 있는 네트워크 회사의 조합에 따라서 속도 차이가 천차만별이 된다. (엄밀하게 말하면 네트워크 경로, Transit 대역폭에 따라 속도 차이가 발생한다) 이 경우 아래의 장점을 통해 반응속도 개선을 꽤 할 수 있다:

1. CDN 서비스 업체가 여러 ISP, IX와 피어링 한다면 사용자-CDN, CDN-서버 구간을 직결하는 효과를 누릴 수 있다.
2. CDN에서 정적 파일을 캐싱함으로서 중계 없이 파일을 제공

1번의 경우 Cloudflare 자체가 체급이 커지면서 일정 수준의 효과를 누릴 수 있다. 추가적인 효과를 원한다면 Argo Smart Routing 라는 상품군을 쓸 수도 있다.

2번의 경우 정적 파일에 대해서 큰 효과를 누릴 수 있다. 사용자가 원했던 파일이 CDN 중계 서버에서 바로 튀어 나온다. 추가로 서버의 트래픽도 줄어든다는 점에서 운영상에도 매력적이다.

추가적으로, DDos 또는 유사한 공격이 발생해도 Cloudflare가 우선적으로 요청을 받아내기 때문에 자유로울 수 있다.

단, 이 경우, 서버의 IP가 노출되면 안되며 HTTP 공격은 방어가 힘들 수 있다. (참고로 이 글을 쓰고있는 loghub는 ip가 노출된거 같기도 하다.. 네이버 클라우드 읍읍)

CDN 업체는 어떻게 "가장 가까운 노드"에 접속시키나?

맨 앞에서 "CDN 업체는 전세계 주요 지점마다 중계 서버를 운영"한다고 했다. 그러면 사용자들을 가장 가까운 중계 서버(= 중계 노드)로 접속하게 해야한다. 이때 사용되는 방법이 두가지 있다

1. BGP + Anycast를 이용해서 ISP가 중계 서버쪽으로 접속하도록 유도 (Cloudflare가 사용)
2. DNS Geo-targeting을 통해 사용자의 위치를 추측하고 가장 가까운 노드로 접속 유도 (Bunny.net)

전자의 경우에는 BGP로 "123.123.123.0/24" IP로 발신하는 패킷은 나한테로 보내라고 주변에 전파하는 방법이다. 이것을 위해서는 수많은 망 사업자 (ISP, 또는 IX)와 직접 피어링 계약을 해서 BGP 세션을 맺어야 한다. 세밀한 제어도 불가능하다.

물론, BGP를 지원하는 업체를 통하는 방법도 있다. 그러나 이 경우 정확도가 떨어진다.

후자의 경우에는 DNS 서버의 위치를 통해 사용자 위치를 가늠한다. DNS 서버의 위치만 정확히 측정 가능하다면 더 상세한 설정이 가능하다. Bunny.net의 경우 아래와 같이 "특정 노드로는 들어가지 못하게" 까지도 정할 수 있다.

BGP는 최소 /24 단위로만 작동한다. (= 1.2.3.xxx로 256개 IP). 그래서 Cloudflare도 Free / paid / enterprise 정도로 IP를 분리하는것 같다. BGP만으로 Bunny.net 처럼 할 경우 (국가 갯수)! * 256개의 IP를 사용해야 할 것이다.

번외: DNS Geo-Targeting에 8.8.8.8 DNS는?

8.8.8.8이나 1.1.1.1 DNS를 사용하면 문제가 되지 않나..? 생각할 수 있다. 사용자는 8.8.8.8로 DNS 요청을 보내지만, DNS 서버는 실제로는 고유의 IP를 가진다. DNS 서버는 NS 요청을 보낼때 서버 고유의 IP를 사용한다. 그래서 IP 기반으로 위치 추정이 가능하다.

네트워크는 "가는 경로"와 "오는 경로"가 다를 수 있다. 한국 Google DNS서버에서 NS 쿼리를 날렸더니 일본 DNS 서버로 NS 쿼리 응답이 갈 수도 있다. 그래서, 사용자가 보는 IP만 Anycast이고 서버는 본인의 고유 IP를 사용한다.

 

CloudFlare는 어떻게 돈을 버는가?

CDN 업체는 중계 서버 역할을 하는것이라고 했다. 그러면 모든 인터넷 데이터가 CDN을 거칠 것이다. 네트워크 사용량이 꽤나 나올거라 짐작할 수 있다. 그런데도 Cloudflare는 무료 요금제를 제공한다. 이 곳은 어떻게 무료로 서비스를 제공할 수 있을까?

이것은 큰 사이트를 운영해 보면 답을 알 수 있다. 얄짤없이 메일로 "Enterprise로 요금제 바꾸지 않으면 차단한다"고 날라온다. 금액은 계약 사항으로 밝히기 어렵지만 엄~~청 쎄개 부른다. 서버비 보다 더 나온다.

어짜피 Cloudflare와 같은 대형 CDN 업체는 일반적으로 사용량이 아니라 일정 대역폭을 기준으로 계약을 체결한다. 즉, 100Gbps 같은 망을 상시 운영중이다. Free, Pro 등의 요금제는 남는 망을 활용하는것 이기 때문에 큰 문제가 되지 않는다.

 

Cloudflare 한국 리전 사용

Cloudflare에는 ICN(인천) 리전이 존재한다. 본인이 어느 중계서버로 접속했는지는 /cdn-cgi/trace 를 통해 쉽게 알 수 있다. 예를 들어 loghub.me/cdn-cgi/trace 를 들어가 보자. colo에 ICN (한국 인천공항), NRT (일본 나리타공항), HKG (홍콩), LAX(미국 LA 공항) 등으로 확인 해 볼 수 있다.

간혹 인터넷에 ICN 리전을 사용하고 싶다는 글이 돌아 다니는데, 비싼 돈 내고 Enterprise 비용을 내는게 거의 유일한 방법이다.

ICN 급의 접속 속도를 낼 수 있는 잘 안알려진 방법이 하나 있긴 하다.

해외망이 안좋은 사람들은..?

본인이 KT, SKT, LGT를 사용한다면 해외 중계 노드에 접속해도 큰 문제가 없다. 하지만 만약 케이블 인터넷 또는 지방 인터넷을 사용한다면 문제가 생긴다. 해외망 대역폭이 적기 때문에 치명적일 정도로 사이트 로딩이 느려진다.

이런 곳은 Cloudflare가 ICN 노드로 접속 시켜준다. 아래 사진을 보면 Seoul 리전으로 접속했다는 것을 볼 수 있다. 이 점을 미루어 볼 때, Cloudflare 측에서 Packet Loss 등을 모니터링 해서 심하다고(?) 판단되는 ISP에는 직접 BGP를 통해 망 연결을 허용해 주는것으로 보인다.

해외망이 좋을수록 (KT) 미국 LA로 가고, 해외 망이 조금 나쁘면 (SK) 일본 NRT가고, 적당적당하면 (LG) 홍콩으로 접속하고, 해외망이 안좋으면 한국으로 접속한다. 해외망이 좋을수록 손해...

Cloudflare에서 해외망이 나쁜 접속자들을 어느정도 파악하고 조치하기 때문에, Cloudflare의 Free 요금제를 써도 일정 수준의 품질을 기대할 수 있다.

 

주의점

캐싱 때문에 의도치 않은 정보를 노출

예전에 Cloudflare가 처음 국내에 깔릴때 있었던 문제이다.

사용자 전용 이미지·JSON 파일이 캐싱될 경우 다른 사용자의 정보가 노출 될 수 있다. 그때는 "내 정보" 페이지가 캐싱돼서, 내가 다른 사람의 정보를 볼 수 있는 문제도 있었었다.

HTTP 응답 헤더에 HIT, dynamic, bypass, expired 등의 상태 결과가 나온다. CDN 서비스가 헷갈릴 만한 파일·경로에 대해 응답 상태를 체크해서 예기치 못할 문제를 막는 것이 필요하다.

웹 사이트에 접속하는 단일 장애지점

CDN이 때론 단일 장애 지점이 되기도 한다. Cloudflare로 사이트를 운영하는데, Cloudflare 자체가 터지면 사이트 접속이 되지 않는다.

한국 시간으로 25년 11월 18일 저녁에도 Cloudflare의 장애가 발생했다. 그로 인해서 많은 사이트들에 접속이 불가능 했다.

의외로 웹 서비스 운영을 하다보면 클플 장애를 자주 마딱뜨리게 된다. 클플 자체의 문제가 아니더라도, 클플과 내 서버간의 연결이 불안정 할 때도 있다.