CDNetworks의 CDN Pro, CPU 비용으로 CDN 가격 모델 혁신

인센티브

오늘날의 콘텐츠 전송 네트워크(CDN)는 단순한 캐싱 및 비트 푸시보다 훨씬 더 많은 일을 하고 있습니다. 모든 주요 업체는 비즈니스를 에지 컴퓨팅 영역으로 확장하려고 합니다. 다음과 같은 고급 플랫폼 씨디네트웍스의 CDN 프로, 권하다 프로그램 가능성 에지 서버에서 정교한 로직을 지원합니다. 암호화 알고리즘, 정규식 조작 및 데이터 압축과 같은 일부 논리는 극도로 계산 집약적일 수 있습니다. CDN 에지에서 실행하면 이러한 리소스 집약적인 활동을 오리진에서 오프로드할 뿐만 아니라 대기 시간을 크게 줄여 최종 사용자에게 만족스러운 경험을 제공합니다.

그러나 이러한 추세가 업계 가격 모델에 항상 반영되는 것은 아닙니다. 대부분의 CDN 제공업체는 주로 트래픽 볼륨(제공된 바이트) 또는 대역폭(대부분 95p)을 기준으로 계속 요금을 부과합니다. 이 모델은 대부분의 CDN 비용이 ISP에서 조달한 대역폭을 기반으로 했던 수십 년 전에 만들어졌습니다. 이 모델은 CDN이 HCLF(Highly Cacheable Large Files)를 전달하는 데만 사용되었을 때 잘 작동했습니다. 그러나 오늘날에는 더 이상 그렇지 않습니다. 예를 들어 최신 서버는 40Gbps의 HCLF를 쉽게 제공할 수 있습니다. 그러나 태평양 전역에서 동일한 대역폭의 동적 API 서비스를 가속화하려면 500개의 서버가 필요할 수 있습니다. 데이터 센터 비용은 대체로 서버 수에 비례합니다. 서로 다른 서비스에 의한 리소스 소비의 이러한 엄청난 차이는 CDN 공급자와 고객 모두에게 많은 가격 문제를 야기합니다.

수익성을 보장하기 위해 CDN 공급자는 모든 추가 비용을 GB당 또는 Mbps당 가격으로 통합해야 합니다. 그러나 서비스가 완전히 탑재되기 전에 생성될 추가 비용을 정확하게 예측하는 것은 불가능합니다. 고객은 일반적으로 트래픽 양이나 대역폭에 대한 대략적인 수치를 제공할 수 있지만 얼마나 많은 서버가 필요할지는 알 수 없습니다. 셀프 서비스 인터페이스를 통해 언제든지 비즈니스 논리를 변경할 수 있다는 것은 말할 것도 없습니다. 전통적인 모델을 기반으로 가격을 책정하려면 많은 추측이 필요합니다. 결과적으로 모든 고객과 서비스 유형에 대해 공정한 가격표를 만드는 것은 거의 불가능합니다. 해결책은 매우 간단합니다. CPU 소비에 대한 요금을 부과하는 것입니다. CPU는 클라우드가 시작된 이래로 클라우드 컴퓨팅의 청구 항목이었습니다. 따라서 CDN이 진화하고 있는 에지 컴퓨팅에 채택되는 것은 놀라운 일이 아닙니다.

어떻게 작동합니까?

CDN 플랫폼의 자원은 여러 고객이 공유하기 때문에 개별 고객의 사용량을 측정하기가 쉽지 않습니다. 가장 일반적으로 사용되는 과금 항목인 트래픽량에 대해서도 애플리케이션 레이어의 데이터만 정확하게 반영할 수 있습니다. 하위 계층에서 네트워크 오버헤드를 수집하고 이를 각 고객에게 귀속시키는 것은 매우 까다롭기 때문에 대부분의 공급자는 이에 신경 쓰지 않기로 결정합니다. 각 고객의 CPU 사용률을 측정하는 것은 훨씬 더 어려울 수 있습니다. 그러나 우리는 2016년 CDN Pro 프로젝트 초기에 이 기능을 필수 기능으로 확인했습니다. NGINX를 기반으로 에지 서버를 구축하기로 결정했을 때 우리 팀은 NGINX의 오픈 소스 버전을 대대적으로 변경했습니다.

NGINX has an “event-driven, non-blocking” architecture. Every request is “put to sleep” when waiting for I/O, awakened when some data is ready to be processed, and then put to sleep again when the processing is completed. This can occur many times during the lifecycle of a request. We use the function clock_gettime() on Linux to obtain the amount of CPU time, in nanoseconds, spent on each active interval of each request and accumulated along the way. At the end of the request’s lifecycle, we write the total CPU time consumed into the access log, the same way we treat the number of bytes transferred. The CPU time is included in the traffic summary log to generate low-latency, per-domain reports.

이 방법은 각 요청에서 NGINX 프로세스가 소비하는 CPU 시간을 정확하게 측정할 수 있지만 다음은 포함하지 않습니다.
● 네트워크 인터페이스 카드 또는 기타 I/O 장치의 인터럽트를 처리하는 커널.
● NGINX 메인 프로세스에서 수행하는 일반적인 작업.
● 로그 사전 처리 및 모니터링과 같은 동일한 서버에서 실행되는 기타 서비스.

자료

위에서 언급했듯이 CDN Pro 플랫폼은 각 도메인에서 소비한 CPU 시간을 보여주는 시계열 보고서를 제공합니다. 지정된 세분성의 각 시간 간격에 대해 이 메트릭을 초 단위로 반환합니다. 자세한 내용은 다음을 참조하십시오. API 문서. 이 보고서는 각 간격에서 전달된 바이트 수를 반환하는 트래픽 볼륨 보고서와 유사합니다. 이 경우 트래픽 대역폭을 결정하기 위해 값을 간격의 너비로 나눕니다. CPU 보고서의 경우 분할 결과 각 간격에서 소비된 CPU 코어 수가 됩니다. 또 다른 흥미로운 메트릭은 요청당 평균 CPU 시간입니다. 이 값은 CDN Pro에서 제공하는 여러 도메인에서 몇 마이크로초에서 몇 초 사이에 다릅니다. 다음은 이 값에 영향을 미치는 몇 가지 주요 요인입니다.

TLS 핸드셰이크: 다음 차트는 연결 순서별로 그룹화된 요청당 평균 CPU 시간을 보여줍니다. 레이블 "1"이 있는 곡선은 각 연결의 첫 번째 요청에 해당합니다. 그것과 후속 요청 "2", "3" 및 "4"의 차이는 TLS 핸드셰이크에서 소비된 CPU 시간을 반영합니다. RSA-2048 인증서로 RSA 연결 시 평균적으로 약 2.0ms가 소모되는 것을 확인할 수 있습니다. 반대로 ECDSA-256 인증서를 사용한 EC 연결은 약 0.9ms를 사용합니다.

TLS 재사용 요인: TLS 연결이 여러 요청에서 재사용되는 경우 핸드셰이크 비용은 모든 해당 요청에서 공유됩니다.

캐시 적중 상태: 적중은 일반적으로 다음 차트와 같이 CPU 시간이 적게 걸립니다.

응답의 크기: 응답이 클수록 다음을 제공하는 데 더 많은 CPU 성능이 필요합니다.

고정된 양의 데이터를 전달하는 데 필요한 CPU 리소스의 양을 결정하려면 CPU 시간을 트래픽 양으로 나눕니다. 도메인마다 상당한 차이가 있습니다. 아래 표에 표시된 것처럼 HCLF가 있는 도메인은 GB당 1초 미만이 필요할 수 있지만 매우 동적인 API 서비스에는 수백 배 더 많은 CPU가 필요할 수 있습니다.

다음은 트래픽이 기가바이트인 CDN Pro 고객 도메인의 최근 통계입니다. CPU 시간 열은 데이터의 각 GB를 처리하는 데 필요한 CPU 시간을 나타냅니다.

(개인 정보 보호를 위해 도메인 이름은 숨겨져 있습니다.)

청구

위의 데이터는 첫 번째 섹션에서 만든 요점을 명확하게 보여줍니다. CDN 서비스 요금을 네트워크 트래픽에만 부과하는 것은 공정하지 않습니다. 이 접근 방식은 슈퍼마켓에서 무게만을 기준으로 모든 것을 청구하는 것과 비슷합니다. CPU 시간에 따른 청구를 도입하면 각 고객이 사용하는 리소스에 대해 공평하게 청구됩니다. 씨디네트웍스 웹사이트는 청구에 대한 이 새로운 접근 방식을 공식적으로 소개했습니다. 결과적으로 관련 비용이 더 정확하게 적용되므로 HTTPS 요청에 대한 요금이 제거됩니다. 동시에, 모든 서버 그룹의 트래픽 볼륨 가격 현저히 줄어들게 됩니다. 채널 고정 해주세요!