[하지 마세요] CDN을 사용하지 마세요

사이트 속도 최적화를 위한 거의 모든 기사나 도구에는 "CDN 사용"이라는 적당한 조항이 있습니다. 일반적으로 CDN은 콘텐츠 전송 네트워크 또는 콘텐츠 전송 네트워크입니다. Method Lab에서는 이 주제에 대한 고객의 질문을 자주 접하는데, 그 중 일부는 자체 CDN을 활성화합니다. 이 문서의 목적은 사이트 로딩 속도 측면에서 CDN이 무엇을 제공할 수 있는지, 어떤 문제가 발생할 수 있는지, 어떤 경우 CDN 사용이 정당한지를 이해하는 것입니다.

그림에 동그라미로 표시된 지연은 CDN 사용으로 인해 발생합니다.

역사의 비트

많은 기술과 마찬가지로 CDN도 필요에 따라 등장했습니다. 인터넷 사용자 간의 인터넷 채널이 발전하면서 온라인 비디오 서비스가 등장했습니다. 당연히 비디오 콘텐츠에는 일반 웹사이트 콘텐츠(사진, 텍스트, CSS 또는 JS 코드)에 비해 훨씬 더 많은 대역폭이 필요합니다.

하나의 서버에서 여러 클라이언트에 병렬로 비디오 스트림을 브로드캐스트하려고 하면 서버의 인터넷 채널이 병목 현상을 일으킬 가능성이 높습니다. 일반적으로 수천 개의 스레드만으로도 일반적인 서버 채널을 막을 수 있습니다. 물론 다른 리소스 제한이 있을 수 있지만 지금은 중요하지 않습니다. 서버 채널을 확장하는 데에는 비용이 너무 많이 들고(때로는 불가능할 수도 있음) 비실용적이라는 점도 중요합니다. 방송 중 채널의 부하는 주기적입니다.

개별 서버의 채널 제한 문제는 CDN을 통해 완벽하게 해결됩니다. 클라이언트는 서버에 직접 연결하지 않고 CDN 네트워크의 노드에 연결합니다. 이상적인 상황에서는 서버가 하나의 스트림을 CDN 노드로 보내고 네트워크는 자체 리소스를 사용하여 이 스트림을 많은 사용자에게 전달합니다. 경제적 관점에서 우리는 실제로 소비된 리소스(대역폭이나 트래픽일 수 있음)에 대해서만 비용을 지불하고 서비스의 뛰어난 확장성을 얻습니다. CDN을 사용하여 대용량 콘텐츠를 전달하는 것은 완전히 정당하고 논리적입니다. 이 분야의 가장 큰 플레이어(예: Netflix)가 대규모 상용 CDN(Akamai, Cloudflare, Fastly 등)을 사용하는 대신 자체 CDN을 구축하고 있다는 점은 주목할 가치가 있습니다.

웹이 발전함에 따라 웹 애플리케이션 자체도 더욱 복잡해지고 복잡해졌습니다. 로딩 속도 문제가 대두되었습니다. 웹 사이트 속도를 좋아하는 사람들은 웹 사이트 로드 속도를 느리게 만드는 몇 가지 주요 문제를 빠르게 식별했습니다. 그 중 하나는 네트워크 지연(RTT - 왕복 시간 또는 핑 시간)이었습니다. 지연은 TCP 연결 설정, TLS 세션 시작, 각 개별 리소스(이미지, JS 파일, HTML 문서 등) 로드 등 웹 사이트 로딩의 많은 프로세스에 영향을 미칩니다.

HTTP/1.1 프로토콜(SPDY, QUIC 및 HTTP/2가 출현하기 전에는 이것이 유일한 옵션이었습니다)을 사용할 때 브라우저가 하나의 호스트에 대해 6개 이하의 TCP 연결을 열 수 있다는 사실로 인해 문제가 더욱 악화되었습니다. 이로 인해 연결이 중단되고 채널 대역폭이 비효율적으로 사용되었습니다. 문제는 연결 수 제한을 극복하기 위해 추가 호스트를 생성하는 도메인 샤딩을 통해 부분적으로 해결되었습니다.

여기에서 CDN의 두 번째 기능이 나타나는 곳입니다. 즉, 많은 수의 포인트와 사용자에 대한 노드의 근접성으로 인해 대기 시간(RTT)이 줄어듭니다. 여기서 거리가 결정적인 역할을 합니다. 빛의 속도는 제한되어 있습니다(광섬유에서는 약 200km/초). 즉, 000km를 이동할 때마다 1000ms의 지연 또는 RTT에 5ms가 추가됩니다. 이는 중간 장비에서도 지연이 발생하므로 전송에 필요한 최소 시간입니다. CDN은 일반적으로 서버에서 개체를 캐시하는 방법을 알고 있으므로 CDN을 통해 이러한 개체를 로드하면 이점을 얻을 수 있습니다. 이를 위해 필요한 조건: 캐시에 객체가 존재하는지, 웹 애플리케이션 서버(원본 서버)와 비교하여 사용자에 대한 CDN 지점의 근접성. CDN 노드의 지리적 근접성이 낮은 대기 시간을 보장하지 않는다는 점을 이해하는 것이 중요합니다. 클라이언트와 CDN 간의 라우팅은 클라이언트가 다른 국가, 가능하면 다른 대륙의 호스트에 연결하는 방식으로 구축될 수 있습니다. 여기서 통신 사업자와 CDN 서비스(피어링, 연결, IX 참여 등) 간의 관계와 CDN 자체의 트래픽 라우팅 정책이 작용합니다. 예를 들어, Cloudflare는 두 가지 초기 계획(무료 및 저가)을 사용할 때 가장 가까운 호스트로부터의 콘텐츠 전달을 보장하지 않습니다. 호스트는 최소 비용을 달성하도록 선택됩니다.

많은 선도적인 인터넷 기업들이 로딩 속도와 웹사이트 성능이라는 주제로 대중의 관심(웹 개발자 및 서비스 소유자)을 끌고 있습니다. 이러한 회사 중에는 Yahoo(Yslow 도구), AOL(WebPageTest) 및 Google(Page Speed ​​​​Insights 서비스)이 있으며 사이트 속도 향상을 위한 자체 권장 사항을 개발하고 있습니다(주로 클라이언트 최적화와 관련됨). 나중에 웹사이트 속도를 높이는 방법에 대한 팁도 제공하는 새로운 웹사이트 속도 테스트 도구가 등장합니다. 이러한 각 서비스 또는 플러그인에는 "CDN 사용"이라는 일관된 권장 사항이 있습니다. 네트워크 지연 시간의 감소는 일반적으로 CDN의 효과에 대한 설명으로 인용됩니다. 불행하게도 모든 사람이 CDN의 가속 효과가 어떻게 달성되고 어떻게 측정할 수 있는지 정확히 이해할 준비가 되어 있지 않으므로 권장 사항을 믿음으로 받아들이고 가정으로 사용합니다. 실제로 모든 CDN이 동일하게 생성되는 것은 아닙니다.

지금 CDN 사용하기

CDN 사용의 유용성을 평가하려면 CDN을 분류해야 합니다. 현재 실제로 확인할 수 있는 내용은 다음과 같습니다(물론 괄호 안의 예는 완전한 것은 아닙니다).

1. JS 라이브러리 배포를 위한 무료 CDN(MaxCDN, Google. Yandex).
2. 클라이언트 최적화를 위한 서비스 CDN(예: 글꼴용 Google Fonts, 이미지용 Cloudinary, Cloudimage)
3. CMS의 정적 및 리소스 최적화를 위한 CDN(Bitrix, WordPress 및 기타에서 사용 가능)
4. 범용 CDN(StackPath, CDNVideo, NGENIX, Megafon).
5. 웹사이트 가속화를 위한 CDN(Cloudflare, Imperva, Airi).

이러한 유형 간의 주요 차이점은 CDN을 통과하는 트래픽의 양입니다. 유형 1-3은 하나의 요청부터 수십 개(보통 사진)까지 콘텐츠의 일부만 전달하는 것입니다. 유형 4와 5는 CDN을 통한 트래픽의 전체 프록시입니다.

실제로 이는 사이트를 로드하는 데 사용되는 연결 수를 의미합니다. HTTP/2에서는 호스트에 대한 단일 TCP 연결을 사용하여 원하는 수의 요청을 처리합니다. 리소스를 메인 호스트(원본)와 CDN으로 나누면 요청을 여러 도메인에 분산하고 여러 TCP 연결을 생성해야 합니다. 최악의 경우는 DNS(1 RTT) + TCP(1 RTT) + TLS(2-3 RTT) = 6-7 RTT입니다. 이 공식은 장치의 무선 채널 활성화를 위한 모바일 네트워크의 지연(활성화되지 않은 경우)과 기지국의 지연을 고려하지 않습니다.

사이트의 로딩 폭포 모양은 다음과 같습니다(CDN 연결 지연 시간은 RTT 150ms로 강조 표시됨).

CDN이 모든 사이트 트래픽(타사 서비스 제외)을 처리하는 경우 단일 TCP 연결을 사용하여 추가 호스트에 대한 연결 지연을 줄일 수 있습니다. 물론 이는 HTTP/2 연결에도 적용됩니다.

추가 차이점은 특정 CDN의 기능에 따라 결정됩니다. 첫 번째 유형의 경우 정적 파일을 호스팅하는 것이고, 다섯 번째 유형의 경우 최적화를 위해 여러 유형의 사이트 콘텐츠를 변경하는 것입니다.

웹사이트 가속화를 위한 CDN 기능

개별 CDN 유형의 기능에 관계없이 사이트 가속화를 위한 전체 CDN 기능을 설명한 다음 각 유형에서 구현되는 내용을 살펴보겠습니다.

1. 텍스트 리소스 압축

가장 기본적이고 이해하기 쉬운 기능이지만 제대로 구현되지 않는 경우가 많습니다. 모든 CDN은 압축 기능을 가속 기능으로 선언합니다. 하지만 좀 더 자세히 살펴보면 단점이 분명해집니다.

• 동적 압축을 위해 낮은 수준을 사용할 수 있습니다 - 5-6(예: gzip의 경우 최대값은 9)
• 정적 압축(캐시에 있는 파일)은 추가 기능(예: 11등급의 zopfi 또는 brotli)을 사용하지 않습니다.
• 효율적인 brotli 압축은 지원되지 않습니다(gzip에 비해 약 20% 절약).

CDN을 사용하는 경우 다음 몇 가지 사항을 확인해 볼 가치가 있습니다. CDN에서 가져온 파일을 가져와서 압축된 크기를 기록하고 비교를 위해 수동으로 압축합니다. 예를 들어 brotli 지원이 포함된 일부 온라인 서비스를 사용할 수 있습니다. vsszhat.rf).

2. 클라이언트 캐싱 헤더 설정

또한 간단한 속도 향상 기능: 클라이언트(브라우저)의 콘텐츠 캐싱을 위한 헤더를 추가합니다. 최신 헤더는 캐시 제어이고, 오래된 헤더는 만료됩니다. 또한 Etag를 사용할 수도 있습니다. 가장 중요한 것은 캐시 제어의 최대 수명이 충분히 크다는 것입니다(한 달 이상). 리소스를 최대한 캐시할 준비가 되면 불변 옵션을 추가할 수 있습니다.

CDN은 max-age 값을 낮추어 사용자가 정적 콘텐츠를 더 자주 다시 로드하도록 할 수 있습니다. 이것이 무엇과 연결되어 있는지는 확실하지 않습니다. 네트워크의 트래픽을 늘리거나 캐시를 재설정하는 방법을 모르는 사이트와의 호환성을 높이려는 욕구입니다. 예를 들어 기본 Cloudflare 헤더 캐시 시간은 1시간으로, 이는 변경할 수 없는 정적 데이터의 경우 매우 낮습니다.

3. 이미지 최적화

CDN은 이미지를 캐싱하고 제공하는 기능을 수행하므로 CDN 측에서 이미지를 최적화하고 이러한 형식으로 사용자에게 제공하는 것이 논리적입니다. 이 기능은 CDN 유형 2, 3, 5에서만 사용할 수 있으므로 바로 예약합시다.

고급 압축 형식(예: WebP), 보다 효율적인 인코더(MozJPEG) 사용, 불필요한 메타데이터 정리 등 다양한 방법으로 이미지를 최적화할 수 있습니다.

일반적으로 이러한 최적화에는 품질 손실이 있는 최적화와 품질 손실이 없는 최적화의 두 가지 유형이 있습니다. CDN은 일반적으로 이미지 품질 변경에 대한 고객 불만을 피하기 위해 무손실 최적화를 사용하려고 노력합니다. 이러한 조건에서는 이득이 최소화됩니다. 실제로는 JPEG 품질 수준이 필요한 것보다 훨씬 높은 경우가 많으므로 사용자 경험을 손상시키지 않으면서 더 낮은 품질 수준으로 안전하게 다시 압축할 수 있습니다. 반면에, 가능한 모든 웹 애플리케이션에 대해 보편적으로 품질 수준과 설정을 결정하는 것은 어렵기 때문에 CDN은 컨텍스트(이미지의 목적, 웹 애플리케이션 유형)를 고려하여 적용할 수 있는 설정에 비해 좀 더 보수적인 설정을 사용합니다. , 등.)

4. TLS 연결 최적화

오늘날 대부분의 트래픽은 TLS 연결을 통해 이동하므로 TLS 협상에 추가 시간이 소요됩니다. 최근에는 이 프로세스의 속도를 높이기 위해 새로운 기술이 개발되었습니다. 예를 들어 EC 암호화, TLS 1.3, 세션 캐시 및 티켓, 하드웨어 암호화 가속(AES-NI) 등이 있습니다. TLS를 올바르게 설정하면 연결 시간을 0-1 RTT(DNS 및 TCP는 계산하지 않음)로 줄일 수 있습니다.

최신 소프트웨어를 사용하면 이러한 방식을 직접 구현하는 것이 어렵지 않습니다.

모든 CDN이 TLS 모범 사례를 구현하는 것은 아닙니다. 이는 TLS 연결 시간을 측정하여 확인할 수 있습니다(예: Webpagetest). 새로운 연결에 이상적입니다 - 1RTT, 2RTT - 평균 수준, 3RTT 등 - 불량.

또한 CDN 수준에서 TLS를 사용하는 경우에도 웹 애플리케이션이 있는 서버도 TLS를 처리해야 하지만 CDN 측에서는 서버와 CDN 간의 트래픽이 공용 네트워크를 통과하기 때문에 주의해야 합니다. 최악의 경우에는 이중 TLS 연결 지연이 발생합니다(첫 번째는 CDN 호스트에, 두 번째는 CDN 호스트와 서버 사이에서).

일부 애플리케이션의 경우 보안 문제에 주의를 기울일 가치가 있습니다. 트래픽은 일반적으로 CDN 노드에서 해독되며 이는 트래픽을 가로챌 수 있는 잠재적인 기회입니다. 트래픽 공개 없이 작업할 수 있는 옵션은 일반적으로 추가 비용을 지불하고 최고 요금제에서 제공됩니다.

5. 연결 지연 감소

모두가 말하는 CDN의 주요 이점은 CDN 호스트와 사용자 사이의 대기 시간이 짧다는 것(거리가 짧음)입니다. 호스트가 사용자가 집중된 지점(도시, 교통 교환 지점 등)에 위치하는 지리적으로 분산된 네트워크 아키텍처를 생성하여 달성됩니다.

실제로 다양한 네트워크의 우선순위는 특정 지역에 있을 수 있습니다. 예를 들어, 러시아 CDN은 러시아에서 더 많은 접속 지점을 갖게 됩니다. 미국 사람들은 우선 미국에서 네트워크를 개발할 것입니다. 예를 들어, 가장 큰 CDN Cloudflare 중 하나는 러시아에 모스크바와 상트페테르부르크의 2개 지점만 보유하고 있습니다. 즉, 모스크바에 직접 배치하는 것에 비해 최대 약 10ms의 지연 시간을 절약할 수 있습니다.

대부분의 서부 CDN에는 러시아에 지점이 전혀 없습니다. 연결하면 러시아 청중의 지연 시간만 늘릴 수 있습니다.

6. 콘텐츠 최적화(축소, 구조 변경)

가장 복잡하고 기술적으로 진보된 지점입니다. 전달 중에 콘텐츠를 변경하는 것은 매우 위험할 수 있습니다. 축소를 취하더라도 소스 코드를 줄이면(추가 공간, 중요하지 않은 구조 등으로 인해) 성능에 영향을 미칠 수 있습니다. 더 심각한 변경 사항(JS 코드를 HTML 끝으로 이동, 파일 병합 등)에 대해 이야기하는 경우 사이트 기능을 방해할 위험이 훨씬 더 높습니다.

따라서 일부 유형 5 CDN만이 이 작업을 수행합니다. 물론 작업 속도를 높이는 데 필요한 모든 변경 사항을 자동화하는 것은 불가능합니다. 수동 분석과 최적화가 필요합니다. 예를 들어, 사용되지 않거나 중복된 코드를 제거하는 것은 수동 작업입니다.

일반적으로 이러한 모든 최적화는 설정에 의해 제어되며 가장 위험한 최적화는 기본적으로 비활성화됩니다.

CDN 유형별 가속 기능 지원

이제 다양한 유형의 CDN이 제공하는 잠재적인 가속화 기회를 살펴보겠습니다.

편의상 분류를 반복합니다.

1. JS 라이브러리 배포를 위한 무료 CDN(MaxCDN, Google. Yandex).
2. 클라이언트 최적화를 위한 서비스 CDN(예: 글꼴용 Google Fonts, 이미지용 Cloudinary, Cloudimage)
3. CMS의 정적 및 리소스 최적화를 위한 CDN(Bitrix, WordPress 및 기타에서 사용 가능)
4. 범용 CDN(StackPath, CDNVideo, NGENIX, Megafon).
5. 웹사이트 가속화를 위한 CDN(Cloudflare, Imperva, Airi).

이제 CDN의 기능과 종류를 비교해 보겠습니다.

기회
1 유형
2 유형
3 유형
4 유형
5 유형

텍스트 압축
+–
-
+–
+–
+

캐시 헤더
+
+
+
+
+

사진들
-
+–
+–
-
+

TLS
-
-
-
+–
+

지연
-
-
-
+
+

만족
-
-
-
-
+

이 표에서 "+"는 전체 지원을 나타내고 "-"는 지원하지 않으며 "+-"는 부분 지원을 나타냅니다. 물론 실제로는 이 표와 차이가 있을 수 있지만(예를 들어 일부 범용 CDN은 이미지 최적화 기능을 구현합니다) 일반적인 아이디어로는 유용합니다.

결과

이 기사를 읽은 후 사이트 속도를 높이기 위한 "CDN 사용" 권장 사항에 대해 더 명확하게 이해하게 되기를 바랍니다.

모든 비즈니스에서와 마찬가지로 모든 서비스의 마케팅 약속을 믿을 수 없습니다. 실제 조건에서 효과를 측정하고 테스트해야 합니다. 이미 CDN을 사용하고 있다면 기사에 설명된 기준을 사용하여 효율성을 확인하세요.

지금 CDN을 사용하면 사이트 로딩 시간이 느려질 수 있습니다.

일반적인 권장 사항으로는 다음 사항에 중점을 둘 수 있습니다. 청중을 연구하고 지리적 범위를 결정합니다. 주요 청중이 반경 1~2km 내에 집중되어 있는 경우 대기 시간 단축이라는 주요 목적을 위해 CDN이 필요하지 않습니다. 대신 서버를 사용자에게 더 가까이 배치하고 적절하게 구성하여 문서에 설명된 대부분의 최적화(무료 및 영구)를 얻을 수 있습니다.

청중이 실제로 지리적으로 분산되어 있는 경우(반경 3000km 이상) 고품질 CDN을 사용하는 것이 정말 유용할 것입니다. 그러나 CDN이 정확히 무엇을 가속화할 수 있는지 미리 이해해야 합니다(기능 표 및 설명 참조). 그러나 웹 사이트 가속은 여전히 ​​CDN 연결로는 해결할 수 없는 복잡한 작업으로 남아 있습니다. 위의 최적화 외에도 가장 효과적인 가속 수단은 CDN 뒤에 남아 있습니다. 즉, 서버 부분 최적화, 클라이언트 부분에 대한 고급 변경(사용하지 않는 코드 제거, 렌더링 프로세스 최적화, 콘텐츠 작업, 글꼴, 적응성 등)이 있습니다. )

출처 : habr.com