CDN費用如何評估？拆解CDN節點的規格與效能，分析如何採購

作者：多多

2022 年 11 月 17 日

#CDN教學

「成本與效能的利益最佳化」是使用 CDN 服務常見的兩難。當實際使用 CDN 服務後，您可能會發現 CDN 節點解析出來的位置不佳，例如，傳遞路線繞了一大圈導致高延遲，或 CDN 節點到你的回源（origin server）此段延遲過高等等，通常解決這些問題的唯一途徑，就是升級至高級方案，但也因此成本增至每個月數千美元。

簡單說，每個企業有不同的CDN服務需求，無論是哪個廠商的「固定方案」都不可能完全切中您的需要，使得升級方案或同時使用與多家CDN供應商合作成為必須，導致成本增加或管理困難。

iNODE NINJA智慧CDN建立平台，替您打破固定方案的限制，您只要準備好CDN節點，就能馬上在平台上，快速建立並啟用專屬CDN服務，效能、成本、平台樣式由您一手控制，就像網路開店一樣容易。

接下來將為您說明「CDN節點怎麼買，最符合成本效益」。

內容包括：

CDN 節點「建議規格」
CDN 節點「效能分析」
CDN 服務「節點評比」

CDN節點規格怎麼選？

iNODE NINJA的 CDN 架構由「Site-SLB-EDGE」組成（點此了解），其中 SLB 與 EDGE 為 CDN 節點實際運行單位，也是建立 CDN 服務前，企業需事先採購的主機。

經實測，CPU 最能被有效利用的 SLB：EDGE 比例為 1：8，但考慮到成本或尚不清楚網路流量的情形下，以下配置在初期便已足夠，之後可視實際用量調整主機規格。

建議：

一台SLB：2vCPU/4GiB
二台EDGE：4vCPU/8GiB¹

註1: EDGE的記憶體至少要高於2GiB

CDN節點「效能分析」

以下測試數據²幫助您判斷最合適的CDN節點採購策略。

註2：數據以 Edge 為主。從網路層面看，iNODE NINJA 的 SLB 只處理第四層（傳輸層 Transport Layer），而 Edge 需要處理到第七層（應用層 Application Layer），所以 SLB 不是效能瓶頸點，Edge 才是，故測試數據以 Edge 為重。

Edge 的效能測試表格如下：

（一）測試環境

準備4台機器，分別為壓測機器、SLB、EDGE、回源（origin server），將機器置於同一個網路環境，並將網路環境設在香港。
壓測軟體使用 WRK2，硬體規格為 8vCPU/16GiB、AWS c5.2xlarge (https://github.com/giltene/wrk2)
回源網站（origin server）直接安裝 openresty，硬體規格為 8vCPU/16GiB、AWS c5.2xlarge。
Edge 版本 5.3.6（硬體規格隨著壓測條件不同而變動）。
SLB 版本 4.1.3（硬體規格 2vCPU/4GiB, AWS c5.large）。

（二）壓測指令 c100

wrk -t8 -c100 -d300s -R<動態調整> –latency ‘https://<你創建的域名>/’

機器規格	指標	-R1000	-R2000	-R4000	-R6000	-R8000	-R10000	-R12000	-R14000	-R16000	-R18000
c5.large	CPU Loading	0.41	0.61	1.16	1.75	2.09
	Req/Sec per	998	1999	3997	5993	6546
	AVG Latency	1.41ms	2.71ms	2.81ms	108ms	27.99s
	50% Latency	1.28ms	1.49ms	1.51ms	56.16ms	26.28s
	75% Latency	2.09ms	4.32ms	2.41ms	182.65ms	38.01s
	90% Latency	4.92ms	5.59ms	6.47ms	315.14ms	55.2s
	100% Latency	179.58ms	202.24ms	179.6ms	714.24ms	69.6s
c5.xlarge	CPU Loading	0.11	1.15	1.42	3.12	3.90	4.21
	Req/Sec per	999.49	1998	3997	5996	7657	7897
	AVG Latency	1.18ms	1.37ms	2.45ms	1.59s	6.74s	35.38s
	50% Latency	1.15ms	1.25ms	1.38ms	1.67ms	2.85s	31.7s
	75% Latency	1.41ms	1.53ms	1,81ms	158.21ms	12.76s	53.4s
	90% Latency	1.60ms	1.88ms	2.61ms	6.99s	19.91s	65.4s
	100% Latency	67.84ms	65.38ms	178.56ms	16.52s	32.98s	82..2s
c5.2xlarge	CPU Loading	0.19	0.64	1.06	1.48	2.10	3.70	4.5	6.42	6.44	6.86
	Req/Sec per	999.09	1999	3997	5997	7989	9999	11933	13976	15361	16173
	AVG Latency	1.25ms	1.13ms	1.38ms	1.46ms	1.78ms	14.18ms	272ms	1.41s	6.68s	13.89s
	50% Latency	1.22ms	1.10ms	1.30ms	1.29ms	1.44ms	1.46ms	1.56ms	2.48ms	896ms	5.71s
	75% Latency	1.50ms	1.36ms	1.60ms	1.59ms	1.78ms	2.03ms	4.10ms	1.34s	7.94s	22.46s
	90% Latency	1.79ms	2.28ms	1.92ms	1.99ms	2.15ms	5.45ms	1.01s	5.44s	42.66s	35.72s
	100% Latency	65.60ms	450ms	242.18ms	294.65ms	750.59ms	777.73ms	4.51s	16.33s	53.4s	80.4s

表一

（三）壓測指令c1000

wrk -t8 -c1000 -d300s -R<動態調整>–latency ‘https:// <你創建的域名>/’

機器規格	指標	-R1000	-R2000	-R4000	-R6000	-R8000	-R10000	-R12000	-R14000	-R16000	-R18000
c5.large	CPU Loading	0.79	1.78	2
	Req/Sec per	996.5	1993	2713
	AVG Latency	130.91ms	454.91ms	44.40s
	50% Latency	105.92ms	235.65ms	43.42s
	75% Latency	159.62ms	422.40ms	1.03m
	90% Latency	232.96ms	1.33s	1.34m
	100% Latency	670.72ms	4.04s	1.64m
c5.xlarge	CPU Loading	0.36	0.01	2.71	2.86	3.58	3.83
	Req/Sec per	996.63	1993.2	3986.37	5979.8	7751.99	7894.19
	AVG Latency	23.81ms	26.51ms	30.89ms	100.50ms	2.87s	24.49s
	50% Latency	22.21ms	24.24ms	26.05ms	28.83ms	51.78ms	10.06s
	75% Latency	30.96ms	33.69ms	41.47ms	52.22ms	2.69s	38.40s
	90% Latency	40.22ms	45.69ms	59.68ms	84.10ms	13.93s	1.21m
	100% Latency	81.66ms	96.70ms	770.56ms	5.09s	20.68s	1.66m
c5.2xlarge	CPU Loading	0.13	0.21	1.33	1.73	1.21	1.43	2.94	4.19	5.04	5.87
	Req/Sec per	996.67	1993.30	3986.64	5979.96	7973.17	9966.51	11959.83	13953.19	15946.14	17939.46
	AVG Latency	9.11ms	9.53ms	9.51ms	9.53ms	9.24ms	9.32ms	9.44ms	9.66ms	10.06ms	10.82ms
	50% Latency	8.06ms	8.70ms	8.41ms	8.23ms	7.98ms	7.86ms	7.77ms	8.03ms	8.06ms	8.42ms
	75% Latency	12.26ms	12.68ms	12.75ms	12.62ms	12.50ms	12.49ms	12.73ms	12.79ms	12.98ms	13.18ms
	90% Latency	14.90ms	15.40ms	15.22ms	15.06ms	14.82ms	15.30ms	15.69ms	15.62ms	15.60ms	16.82ms
	100% Latency	193.92ms	38.30ms	48.45ms	538.11ms	189.05ms	212.10ms	216.32ms	193.02ms	221.44ms	264.96ms

表二

（四）效能測試表格判讀

以上兩個壓測數據表，撇開-R參數，唯一的差別是建立連接數的不同（表一：100、表二：1000），如此能看出在不同連接數的情況下，EDGE 表現的狀態。

表格中紅字表示 EDGE 在特定的規格和條件下的最高效能。其判斷依據為主要參考３個數值：CPU Loading、 Req/Sec per、50% Latency。請看以下針對表一的說明：

以C5.large來說，從表一中可發現，當每秒處理超過4000 Request時，處理的效能開始變差。

CPU Loading：-R6000時，數值為1.75，已經超過2/3 CPU使用量。
Req/Sec per：-R8000來說，沒辦法達到8000 Req，每秒只能處理6500的Req。
50% Latency：-R4000時，Latency為2.81ms，-R6000時為108ms，已經產生明顯差距。

機器規格	指標	-R1000	-R2000	-R4000	-R6000	-R8000
c5.large	CPU Loading	0.41	0.61	1.16	1.75	2.09
	Req/Sec per	998	1999	3997	5993	6546
	AVG Latency	1.41ms	2.71ms	2.81ms	108ms	27.99s
	50% Latency	1.28ms	1.49ms	1.51ms	56.16ms	26.28s

表一局部

根據以上分析可判斷：

C5.large能承受的Req數量不多，不太建議使用。
C5.xlarge 每秒不超過6000 HTTPS Request時，能維持一定效能。
C5.2xlarge每秒不超過16000 HTTPS Request時，能維持一定效能。

CDN節點「成本分析」

iNODE NINJA依據台數計價，所以主機規格越大，就越划算。目前收費每台SLB或是EDGE每月皆為20美元（1天為0.667）（iNODE NINJA詳細方案與價格）。下表為各大雲端主機的價格（僅機器價格，不包含其他費用）。

雲端主機價格	單位：美元	2022/9/16
	主機	主機規格	（vCPU/GiB）
		2/4	4/8	8/16
AWS	C5系列、香港	80	160	320
AZURE	F系列、EAST ASIA	110	220	440
ALI	C7系列、香港	105	210	420

為何選擇iNODE NINJA？

CDN服務「評比」：台灣連線差強人意

實測他牌CDN服務的免費方案後，發現其在台灣連線的速度普通。下圖為進一步解析免費方案的域名結果，可見其共有兩個節點，針對這兩個節點測試後，得知一個位於日本，一個在美國，所以，如果您的回源（origin server）在台灣或香港，連線的路線會繞一大圈，也就是從台灣到日本（或美國）再回到台灣，如此一來，連線速度必然很慢。