Cloudflare 推出了讓你買 cache 空間的 Cache Reserve

這幾天 Cloudflare 推出了一大包東西,其中一個是 Cache Reserve:「Introducing Cache Reserve: massively extending Cloudflare’s cache」。

一般的使用情境是依照 LRU 演算法在決定 Cloudflare 的 cache 滿的時候要排除誰:

We do eviction based on an algorithm called “least recently used” or LRU. This means that the least-requested content can be evicted from cache first to make space for more popular content when storage space is full.

Cache Reserve 就是自己買 cache 空間,他的作法是你付 R2 的空間費用:

Cache Reserve is a large, persistent data store that is implemented on top of R2.

這樣就可以完全依照 Cache-Control 這類 HTTP header 內的時間保存了,你就不用擔心會被 purge 掉,首先價錢包括了 R2 的部份:

The Cache Reserve Plan will mimic the low cost of R2. Storage will be $0.015 per GB per month and operations will be $0.36 per million reads, and $4.50 per million writes.

另外還有還沒公告的 Cache Reserve 的部份:

(Cache Reserve pricing page will be out soon)

對於很極致想要拼 hit rate 的使用者來說是個選擇就是了,另外可以想到直播相關的協定 (像是 HLS) 好像可以這樣搞來壓低對 origin server 的壓力?

Akamai Shared Domains 加入 PSL (Public Suffix List)

Akamai 把自家的 shared domains 申請加入 PSL (Public Suffix List):「Adding Akamai Shared Domains to the Public Suffix List」。

提到 PSL,常被拿來舉例的應該就是 supercookie 了,也就是把 cookie 的有效網域設到 .com 或是 .org 這種 top level domain,這樣就可以跨很多站台追蹤使用者了 (所以被稱為 supercookie),而 PSL 則可以被拿來限制這些網域名稱。

而在 Akamai 的例子來說,edgekey.net 下面的使用者都會共用 cookie,對於安全與隱私的考量其實不太好。這次把這些網域加到 PSL 之後,變成 edgekey.net 這層無法設定 cookie,而 one.edgekey.nettwo.edgekey.net 各自有自己的 cookie namespace,這樣就好一些了...

順帶一提,除了瀏覽器會引入 PSL 來過濾外,使用者端可以靠 Privacy Badge 來過濾掉這類的 cookie,因為 Privacy Badge 會針對這類網域清掉 cookie 再送出 HTTP request。

Akamai 的文章裡面也有提到這件事情:

The PSL contains multi-party domain suffixes and is used by a wide range of client software (for example, web browsers) to implement policy decisions, such as to prevent cookies from being set on public or multi-party domains.

Cloudflare 在那霸設點

Cloudflare 宣佈增加了一堆 PoP:「New cities on the Cloudflare global network: March 2022 edition」。

日本在這波加了兩個:

  • Fukuoka, Japan
  • Naha, Japan

福岡不算太意外,畢竟東京與大阪都已經有 PoP 了,以距離來說,開在福岡算是去吃九州的人口,而且以流量來說應該也夠大,是可以投資的點。

而沖繩那霸就真的比較意外了,如果要猜的話,也許就是談福岡的時候順便一起談?

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用,剛剛翻了一下 NomadVault,看起來都支援 APT repository 了:「https://apt.releases.hashicorp.com」;另外也有 RPM repository:「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構,從錯誤訊息觀察,看起來後面是 Amazon S3,前面是 Fastly 的 CDN。

168.95.1.1 與 168.95.192.1 對 CloudFront 的差異

tl;dr 版本:目前先用 PPPoE 發出來的 DNS resolver 設定,如果要自己設定的話,用 168.95.192.1 (主) + 168.95.1.1 (次) 然後關掉 round-robin 模式。

剛剛看 SmokePing 時發現的奇怪現象,同樣都是在 HiNet 下面的機器與 DNS resolver,但 CloudFront 會給出不同的機房提供服務。

講的更仔細的是,168.95.192.1 這組會給出 tpe 系列的機房,所以 latency 會比較低,但如果你用的是 168.95.1.1 的話,就會到處丟,包括日本的 nrt 系列,與香港的 hkg 系列。

這邊拿 d36cz9buwru1tt.cloudfront.net 這組網域觀察,這是 AWS 官網用的資源,從官網的 html 原始碼裡面可以看到。

以第四台網路上面的機器上面來看 (北都,我分配到的線路是走台灣智慧光網的線路),可以看到這邊 latency 會飄:「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

看了一下 DNS 設定,第四台的 ISP 給了兩組 DNS resolver 設定給分享器,分別是 168.95.1.18.8.8.8,然後分享器的 DNS resolver 是 round-robin,所以有時候會在台灣,有時候就連出國...

不過這組不能直接說是 AWS 的問題,因為 ISP 自己不架 DNS server,還跑去用 HiNet 的,有 sub-optimal 的問題也是很正常...

另外就是確認放在 HiNet 線路上的機器,這邊 ISP 透過 PPPoE 給了 168.95.192.1168.95.1.1,但因為是直接進到 /etc/resolv.conf,所以只有在第一組爛掉的時候才會導去第二組 (預設值),所以看起來就很穩:「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

實際分析從 HiNet 去 168.95.1.1168.95.192.1 查時,也可以看到類似的情況,像是用這樣的 command 去看 168.95.1.1 的情況:

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.1.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

可以看到給出來的點都是日本 (nrt 與 kix):

server-13-225-178-1.nrt57.r.cloudfront.net.
server-143-204-74-1.nrt12.r.cloudfront.net.
server-18-65-171-1.nrt57.r.cloudfront.net.
server-18-65-99-1.kix50.r.cloudfront.net.
server-54-192-254-1.nrt51.r.cloudfront.net.
server-54-230-123-1.kix56.r.cloudfront.net.
server-99-84-55-1.nrt20.r.cloudfront.net.

如果改掃 168.95.192.1 的話:

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.192.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

就會完全在台灣機房:

server-13-35-163-1.tpe50.r.cloudfront.net.
server-13-35-36-1.tpe51.r.cloudfront.net.

用先前提到的「用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊」看起來 ECS 相關資訊都被拔掉了,但不確定關聯性是怎麼樣,但可以確定的是如果你設到 168.95.1.1 的話會是 sub-optimal experience...

有人吃飯工具用 CloudFront 的 (像是公司的服務),而且手上有 bussiness support 或是 enterprise support 的,可以自己測過確認後去開 ticket 跟 AWS 看看怎麼弄,我這邊沒這些管道 XD

日本囯土地理院提供的日本地圖圖資

查資料的時候發現日本的囯土地理院有開放使用日本的地圖圖資:「地理院タイル一覧」。

圖資放在 cyberjapandata.gsi.go.jp 這個網址上,前面掛 Fastly 的 CDN:

;; ANSWER SECTION:
cyberjapandata.gsi.go.jp. 300   IN      CNAME   d.sni.global.fastly.net.
d.sni.global.fastly.net. 30     IN      A       199.232.46.133

抓個鶯谷園的點出來看:

然後可以看到非常多不同的資料,像是「1928年頃」、「活断層図(都市圏活断層図)」、「明治期の低湿地」、「磁気図2010.0年値」,另外針對比較大的災難也有提供一些區域圖,像是「平成25年7月17日からの大雨 山口地方「須佐地区」正射画像(2013年7月31日撮影)」。

另外因為 url 形式是 https://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png 這種格式,可以直接用 Leaflet 這類 library 吃進去...

AWS 增加 CloudFront 的 AWS-managed prefix list 讓管理者使用

看到 AWS 公告提供 CloudFront 的 origin subnet 資訊 (AWS-managed prefix list) 讓管理者可以用:「Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront」。

以往會自己去「AWS IP address ranges」這邊提供的 JSON 檔案定時撈出來再丟到 managed prefix list 裡面,這次的功能等於是 AWS 自己管理這個 prefix list 讓管理者使用。

馬上想的到的用途就是 HTTP/HTTPS port 了,只開放給 CloudFront 的伺服器存取:

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

要注意的是這不應該當作唯一的 ACL 手段,因為其他人也可以建立 CloudFront distribution 來穿透打進你的 origin server。

另外有個比較特別的地方,這個 prefix list 的權重很重,使用他會算 55 條 rule 的量,在 security group 內很容易撞到 60 條的限制,在 route table 裡面則是直接撞到 50 條的限制;不過這兩個限制都可以跟 AWS 申請調昇:

The Amazon CloudFront managed prefix list weight is unique in how it affects Amazon VPC quotas:

  • It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.
  • It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

如果 HTTP 一條,HTTPS 也一條,那就會算 110 rules 了,有暴力的感覺...

把 Blog 丟到 CloudFront 上

先前在「AWS 流量相關的 Free Tier 增加不少...」這邊有提到一般性的流量從 1GB/month per region 升到 100GB/month,另外 CloudFront 則是大幅增加,從 50GB/month (只有註冊完的前 12 個月) 提升到 1TB/month (不限制 12 個月),另外 CloudFront 到 EC2 中間的流量是不計費的。

剛剛花了點功夫把 blog 從 Cloudflare 搬到 CloudFront 上,另外先對預設的 /* 調整成 no cache,然後針對 /wp-content/* 另外加上 cache 處理,跑一陣子看看有沒有問題再說...

目前比較明顯的改善就是 latency,從 HiNet 連到免費版的 Cloudflare 會導去美國,用 CloudFront 的話就會是台灣了:

另外一方面,這樣國際頻寬的部份就會走進 AWS 的骨幹,比起透過 HiNet 自己連到美國的 PoP 上,理論上應該是會快一些...

來看 Intel + Varnish 的單機 500Gbps 的 PR 新聞稿

在「Varnish Software Achieves 500Gbps Throughput Per Server for UHD Video Content」這邊看到 PR 稿,由 IntelVarnish 合作,宣稱達到單機 500Gbps 的 throughput 了:

According to Varnish Software, the following were the outcomes of the test:

  • 509.7 Gbps live-linear throughput, using a dual-processor configuration
  • 487.2 Gbps video-on-demand throughput, using a dual-processor configuration

白皮書在「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」這頁可以用個資交換下載,不過用搜尋引擎找一下可以發現 Intel 那邊有放出 PDF (但不確定兩邊給的是不是同一份):「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」。

單 CPU 的伺服器是四個 100Gbps 界面接出來,雙 CPU 的伺服器是八個 (這邊 SUT 是 system under test 的縮寫):

These client systems were connected to the CDN servers using 100 GbE links through a switch; 4x100 GbE connections for the single-processor SUT, and 8x100 GbE for the dualprocessor SUT. Testing was done using Wrk, a widely recognized open-source HTTP(S) benchmarking tool.

不過如果實際看圖會發現伺服器是兩個 100Gbps (單 CPU) 與四個 100Gbps (雙 CPU),然後 wrk 也吃了兩個或是四個 100Gbps:

在白皮書最後面也有提到測試的配置,都是在 Ubuntu 20.04 上面跑,單 CPU 用的是兩張 Intel 的 100Gbps 網卡,雙 CPU 的用的是四張 Mellanox 的 100Gbps 網卡:

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Single processor SUT configuration was based on the Supermicro SMC 110P-WTR-TNR single socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by two 100 GbE Intel® Ethernet Network Adapters E810. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 8 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80 generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnishplus-6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Dual processor SUT configuration was based on the Supermicro SMC 22OU-TNR dual socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by four 100 GbE Mellanox MCX516A-CDAT adapters. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 12 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80- generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnish-plus6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

不過馬上就會滿頭問號,四張 100Gbps 是怎麼跑到 500Gbps 的頻寬...

這份 PR 馬上就讓人想到 Netflix 先前放出來的投影片 (先前有在「Netflix 在單機服務 400Gbps 的影音流量」這篇提到),在 Netflix 的投影片裡面有提到他們在 Intel 平台上面受限於記憶體的頻寬,整台機器只能跑到 230Gbps。

另外一種猜測是,如果 Intel 與 Varnish 宣稱的 500Gbps 是算 switch 上的總流量 (有這樣算的嗎,你是 Juniper 嗎...),那這邊的 500Gbps 換算回去差不多就是減半 (還很客氣的沒把 cache 沒中需要去 origin server 拉資料的流量扣掉),跟 Netflix 在 FreeBSD 上跑出來的結果差不多啊...

坐等反駁 XDDD

AWS 流量相關的 Free Tier 增加不少...

Jeff Barr 出來公告增加 AWS 流量相關的 free tier:「AWS Free Tier Data Transfer Expansion – 100 GB From Regions and 1 TB From Amazon CloudFront Per Month」。

一般性的 data transfer 從 1GB/month/region 變成 100GB/mo,現在是 21 regions 所以不會有反例,另外大多數的人或是團隊也就固定用一兩個 region,這個 free tier 大概可以省個 $10 到 $20 左右?

Data Transfer from AWS Regions to the Internet is now free for up to 100 GB of data per month (up from 1 GB per region). This includes Amazon EC2, Amazon S3, Elastic Load Balancing, and so forth. The expansion does not apply to the AWS GovCloud or AWS China Regions.

另外是 CloudFront 的部份,本來只有前 12 個月有 free tier,現在是開放到所有帳號都有,另外從 50GB/month 升到 1TB/month,這個部份的 free tier 就不少了,大概是 $100 到 $200?

Data Transfer from Amazon CloudFront is now free for up to 1 TB of data per month (up from 50 GB), and is no longer limited to the first 12 months after signup. We are also raising the number of free HTTP and HTTPS requests from 2,000,000 to 10,000,000, and removing the 12 month limit on the 2,000,000 free CloudFront Function invocations per month. The expansion does not apply to data transfer from CloudFront PoPs in China.

今年十二月才生效,要注意一下不要現在就用爽爽:

This change is effective December 1, 2021 and takes effect with no effort on your part.

這樣好像可以考慮把 blog 與 wiki 都放上去玩玩看,目前這兩個服務都是用 Cloudflare 的 free tier,HiNet 用戶基本上都是連去 Cloudflare 的美西 PoP,偶而離峰時間會用亞洲的點,但都不會是台灣的 PoP...

不過記得之前 WordPress + CloudFront 有些狀況,再研究看看要怎麼弄好了...