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

Akamai 併購 Linode

目前在 Hacker News 首頁第一名,Akamai 併購 Linode:「Akamai To Acquire Linode to Provide Businesses with a Developer-friendly and Massively-distributed Platform to Build, Run and Secure Applications」,Linode 的新聞稿則是在「Linode and Akamai」,Hacker News 上的討論在「Akamai to Acquire Linode (akamai.com)」這邊。

併購金額與預期的時間表:

Under terms of the agreement, Akamai has agreed to acquire all of the outstanding equity of Linode Limited Liability Company for approximately $900 million, after customary purchase price adjustments. As a result of structuring the transaction as an asset purchase, Akamai expects to achieve cash income tax savings over the next 15 years that have an estimated net present value of approximately $120 million. The transaction is expected to close in the first quarter of 2022 and is subject to customary closing conditions.

好像會有記者會... 應該會有更多說明。

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

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

圖資放在 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 了,有暴力的感覺...

用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊

整理資料的時候看到以前就看到的資訊,Akamai 有提供工具,可以看 DNS resolver 的資訊:「Introducing a New whoami Tool for DNS Resolver Information」。

這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的,這些對外雖然有一個 IP address 在服務,但後面是一整個 cluster,所以可以利用 Akamai 的這個工具來看分析。

像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個):

$ dig whoami.ds.akahelp.net txt @8.8.8.8

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "172.217.43.194"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.35.0/24/24"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "111.250.35.149"

1.1.1.1 會給假的 ECS 資訊:

$ dig whoami.ds.akahelp.net txt @1.1.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.0.0/24/24"

然後 168.95.1.1 則是連 ECS 都不給 XDDD

$ dig whoami.ds.akahelp.net txt @168.95.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2001:b000:180:8002:0:2:9:114"

之前在找 DNS 類問題的時候還算可以用的工具...

把 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 上,理論上應該是會快一些...