Fastly 服務掛掉的事件

Hacker News 上看到「Summary of June 8 outage (fastly.com)」這邊的討論,連結是 Fastly 官方先發布的說明:「Summary of June 8 outage」。

其中提到了是因為客戶的某些設定造成的:

10:27 Fastly Engineering identified the customer configuration

另外特別提到了 Fastly 的 WebAssembly 與 Compute@Edge,看起來應該就是這邊炸鍋:

Broadly, this means fully leveraging the isolation capabilities of WebAssembly and Compute@Edge to build greater resiliency from the ground up. We’ll continue to update our community as we make progress toward this goal.

我猜基本的資源保護機制應該有上 (像是在程式裡面自己 call 自己之類的,Fork bomb 之類的),可能是這兩個東西互串的某些部份沒有保護到,就一路把資源吃完炸掉。

看起來後續會有比較完整的報告,到時候再來看看會透露出多少東西...

CloudFront 的印度與亞太區降價

AWS 宣佈 CloudFront 在印度與亞太區降價:「Amazon CloudFront announces price cuts in India and Asia Pacific regions」,回朔至這個月月初生效:

Amazon CloudFront announces price cuts of up to 36% in India and up to 20% in the Asia Pacific region (Hong Kong, Indonesia, Philippines, Singapore, South Korea, Taiwan, & Thailand) for Regional Data Transfer Out to Internet rates. The new CloudFront prices in these regions are effective May 1st, 2021.

比了一下現在的「Amazon CloudFront Pricing」與 Internet Archive 上的「Amazon CloudFront Pricing」,看起來 First 10TB、Next 40TB、Next 100TB 與 Next 350TB 的部份都有降,更多的部份則是維持原價。

對一般簡單用的人來說,主要是落在 First 10TB 這個區間,亞太區的每 GB 單價從 USD$0.14 降到 USD$0.12,不無小補,而有夠大的量的單位應該都去談 commit & discount 了...

CloudFront 把本來的 Lambda@Edge 產品線拆細,推出 CloudFront Functions

Amazon CloudFront 本來的 Lambda@Edge 產品線拆細,多出一個 CloudFront Functions:「Introducing CloudFront Functions – Run Your Code at the Edge with Low Latency at Any Scale」。

就產品面的角度就是限制比 Lambda@Edge 多,但價錢變便宜很多。

先看價錢的部份,CloudFront Functions 的價錢只有 request:

Invocation pricing is $0.10 per 1 million invocations ($0.0000001 per request).

而 Lambda@Edge 則是兩筆費用,光是 request 費用就是六倍:

Request pricing is $0.60 per 1 million requests ($0.0000006 per request).

Duration is calculated from the time your code begins executing until it returns or otherwise terminates. You are charged $0.00005001 for every GB-second used.

當然,CloudFront Functions 便宜帶來的限制也不少,最主要的限制可以從最大執行時間只有 1ms,以及記憶體只能用 2MB 就可以看出來:

但這對於輕量的操作來說已經夠用了,主要就是對 HTTP header 的操作...

另外比較表上看到個有趣的點「JavaScript (ECMAScript 5.1 compliant)」,這樣應該就不會是 Node.js (V8 engine),而是其他的 JS engine?

試用 Cloudflare 的 Argo Tunnel

Cloudflare 宣佈讓大家免費使用 Argo Tunnel 了,也順便改名為 Cloudflare Tunnel 了:「A Boring Announcement: Free Tunnels for Everyone」。

Starting today, we’re excited to announce that any organization can use the secure, outbound-only connection feature of the product at no cost. You can still add the paid Argo Smart Routing feature to accelerate traffic.

As part of that change (and to reduce confusion), we’re also renaming the product to Cloudflare Tunnel. To get started, sign up today.

Cloudflare Tunnel 的功能就像 ngrok,在用戶端的機器上跑一隻 agent 連到 Cloudflare 或是 ngrok 的伺服器,這樣外部連到 Cloudflare 或是 ngrok 的伺服器後就可以透過這組預先建好的連線連上本機的服務了,常見的應用當然就是 HTTP(S) server。

本來是付費功能,一般使用者應該也不會需要這個功能,這次把這個功能免費丟出來的用意不知道是什麼...

不過既然都免費了,還是花了點時間測了一下,可以發現 ngrok 的設定比較簡單,Cloudflare 的 cloudflared 設定起來複雜不少,不過文件還算清楚,照著設就好。

Anyway,有些事情有了 Cloudflare Tunnel 就更方便了,像是有些超小型的 VPS 是共用 IPv4 address 而且沒有 IPv6 address 的,可以透過 cloudflared 反向打進去提供服務,同樣的,在 NAT 後面的機器也可以透過這個方法很簡單的打通。

順便說一下,現在的 blog.gslin.org 就是跑在 cloudflared 上面了,官方提供的 ARM64 binary 跑在 EC2t4g 上面目前看起來沒有什麼問題,而且比起本來 nginx 都是抓到 Cloudflare 本身的 IP,現在加上這兩行後反而就可以抓到真的使用者 IP address 了:

    set_real_ip_from 127.0.0.1;
    real_ip_header X-Forwarded-For;

跑一陣子看看效果如何...

利用 Cloudflare Workers 繞過 Cloudflare 自家的阻擋機制

Hacker News 首頁上看到「How to bypass Cloudflare bot protection (jychp.medium.com)」這則,裡面的文章是「How to bypass CloudFlare bot protection ?」這篇,利用 Cloudflare Workers 繞過 Cloudflare 自家的 CAPTCHA 機制。

這個漏洞有先被送給 Cloudflare,但被認為不是問題,所以作者就決定公開:

Several months ago I submitted what appeared to be a security flaw to CloudFalre’s bugbounty program. According to them, this is not a problem, it’s up to you to make up your own mind.

技術上就是透過 Cloudflare Workers 當作 proxy server,只是看起來 Cloudflare 對自家 IP 有特別處理,在設定妥當後,用 Cloudflare Workers 的 IP address 去連 Cloudflare 的站台,幾乎不會觸發 Cloudflare 的阻擋機制。

不過 free tier 還是有限制,主要就是數量:

The first 100,000 requests each day are free and paid plans start at just $5/10 million requests, making Workers as much as ten-times less expensive than other serverless platforms.

作者也有提到這點:

So let’s enjoy the 100 000 request/day for your free Cloudflare account and go scrape the world !

但這是個有趣的方法,加上信用卡盜刷之類的方式,這整包看起來就很有威力...

Cloudflare 再次嘗試 ARM 伺服器

2018 年的時候寫過一篇 Cloudflare 在嘗試 ARM 伺服器的進展:「Cloudflare 用 ARM 當伺服器的進展...」,後來就沒有太多公開的消息,直到這幾天看到「ARMs Race: Ampere Altra takes on the AWS Graviton2」才看到原因:

By the time we completed porting our software stack to be compatible with ARM, Qualcomm decided to exit the server business.

所以是都測差不多,也都把 Cloudflare 自家的軟體搬上去了,但 Qualcomm 也決定收手,沒機器可以用...

這次再次踏入 ARM 領域讓人想到前陣子 AppleM1,讓大家看到 ARM 踏入桌機與筆電領域可以是什麼樣貌...

這次 Cloudflare 選擇了 Ampere Altra,這是基於 Neoverse N1 的平台,而這個平台的另外一個知名公司就是 AWSGraviton2,所以就拿來比較:

可以看到 Ampere Altra 的核心數多了 25% (64 vs. 80),運作頻率多了 20% (2.5Ghz vs. 3.0Ghz)。測試的結果也都有高有低,落在 10%~40% 都有。

不過其中比較特別的是 Brotli - 9 的測試特別差 (而且是 8 與 10 都正常的情況下):

依照 Cloudflare 的說法,他們其實不會用到 Brotli - 7 以及更高的等級,不過畢竟有測出來,還是花了時間找一下根本原因:

Although we do not use Brotli level 7 and above when performing dynamic compression, we decided to investigate further.

反追問題後發現跟 Page Faults 以及 Pipeline Backend Stalls 有關,不過是可以改寫避開,在避開後可以達到跟 Graviton2 類似的水準:

By analyzing our dataset further, we found the common underlying cause appeared to be the high number of page faults incurred at level 9. Ampere has demonstrated that by increasing the page size from 4K to 64K bytes, we can alleviate the bottleneck and bring the Ampere Altra at parity with the AWS Graviton2. We plan to experiment with large page sizes in the future as we continue to evaluate Altra.

但目前看起來應該都還算正向,看起來供貨如果穩定的話,應該有機會換過去?畢竟 ARM 平台可以省下來的電力太多了,現在因為 M1 對 ARM 的公關效果太驚人的關係,解釋起來會更輕鬆...

台灣看 Lbry/Odysee 的速度變快一些

Twitter 上看到 jkgtw 提到 Lbry/Odysee 的速度快很多:

看了一下資料,HiNetcdn.lbryplayer.xyz 的 latency 增加了,但是 packet loss 改善了不少,看起來是把本來導去新加坡的流量改導去美國:

另外走 APOL 的 cable 這邊也有類似的情況,可以看出導去美國了:

測了一下影片觀看速度,1.5x 可以看,2x 還是放不太動,的確是比以前好不少。

Akamai 也推出了 Key-Value 服務 EdgeKV

沒介紹過 Akamai 的一些架構,先講到 Akamai 的 Edge 端 Serverless 架構是 EdgeWorkers,跑的是 JavaScript:

EdgeWorkers lets developers just code — integrating into existing CI/CD workflows and enabling multiple teams to work in parallel using JavaScript. EdgeWorkers eliminates the hassle of managing compute resources and building for scale.

然後這次推出的是 EdgeKV,目前還在 Beta 版:「Serverless Storage at the Edge (EdgeKV Beta)」。

如同名字所說的,架構上 Key-Value 架構,放棄了 CAP theorem 裡面的 C,改走 Eventual Consistency:

EdgeKV uses what is known in distributing computing as an eventual consistency model to perform writes and updates. This model achieves high availability with low read latency by propagating data writes globally. The period of time it takes the system to distribute data globally is called the “inconsistency window”.

隔壁 Cloudflare Workers KV 也是 Eventual Consistency (出自「How KV works」這邊):

KV achieves this performance by being eventually-consistent. Changes are immediately visible in the edge location at which they're made, but may take up to 60 seconds to propagate to all other edge locations.

看起來算是補上競爭對手的產品線...

Cloudflare 在 Argo 架構上推出 Tiered Cache Smart Topology

Cloudflare 在 Argo 架構上 (付費功能) 推出了 Tiered Cache Smart Topology:「Tiered Cache Smart Topology」、「Introducing: Smarter Tiered Cache Topology Generation」。

這邊提到的 Argo 是 Cloudflare 在 2017 年時提出來想要降低 Internet 的 routing (像是 BGP) 未必會走到最佳路徑上的問題,透過 Cloudflare 自家的骨幹網路,最佳化 latency & bandwidth & packet loss 產生的問題:「Introducing Argo — A faster, more reliable, more secure Internet for everyone」。

而 Tiered Cache 算是 CDN 行業裡面很常見的技術了,主要是要解決不同 data center 的 edge server 都去跟 origin server 要資料,而造成 origin server 的流量太大。

緩解的方式是在 edge server 與 origin server 中間疊一層 cache server,就可以大幅緩解 origin server 的流量。

origin server 流量問題在一般的應用來說還好:就算是 Windows Update 或是 iOS 更新這種基數超大的量,一開始也許會慢一點,但當 edge server 有 cache 後就不會再吃到 origin server 的頻寬。

另外也可以在公開上線前先 pre-warm,讓 edge server 都有 cache 後再上線,這樣 origin server 就不需要準備太多頻寬。

但在大型影音直播的時候就不一樣了,因為會一直產出新的內容 (之前玩的是走 HLS,所以會一直有新的 .ts 檔生出來),沒辦法先 pre-warm,這時候 origin server 就會需要大量的頻寬才有辦法支撐整個服務,所以需要 CDN 系統在中間疊一層 cache server,這個功能在各家 CDN 業者都有,只是名稱不太一樣。

記得當時用 Akamai 預設的 CDN 走直播時只有 95% 左右的 hit rate,這代表對外服務 20Gbps 就會對 origin server 產生 1Gbps 的量 (20:1),而打開 Tiered Distribution 後可以拉到 98% 甚至 99%+,相對於後端的壓力可以降到 50:1 到 100+:1。

AWSCloudFront 也有類似的架構,叫做 Regional Edge Caches:

不過這兩種架構都有一些缺點,像 Akamai 需要自己指定 cache server 的節點,這樣就不容易動態調整,或是使用者沒有設好導致 latency 偏高。

而像 AWS 這種已經已經先分好群的,就會遇到像是 origin server 與 edge server 都在台灣,但在 Regional Edge Caches 架構下必須先繞到日本 (或是新加坡),產生 latency 與 packet loss 偏高的問題。

這次 Cloudflare 在 Argo 架構推出的 Tiered Cache Smart Topology 的賣點 (Argo 本來就有提供 Tiered Cache),看起來是希望由系統自動選擇最佳的一個 data center 來當作 cache tier,不需要使用者額外設定。

不過一般網站應該還好,主力應該在電商網站與互動性很高的娛樂產業 (i.e. 操作起來要很流暢)...

Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello

Cloudflare 本來在推的 ESNI 現在變成 ECH 了:「Good-bye ESNI, hello ECH!」。

上面這張圖是 ESNI,下面這張是 ECH:

可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了,伺服器會先試著解內層的 ClientHelloInner,失敗的時候會用外層的 ClientHelloOuter:

The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.

看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣,這樣就能順便解掉 censorship 的問題...

其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI:

In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.

In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.

不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis),目前看起來只處理了 ClientHello 本身,現在還是有機會分析 handshake 過程來擋,必須繼續改善 ECH 的協定,讓整個流程看起來都跟一般的 TLS 一樣...

可以等著看,到時候在中國的效果如何了,會不會讓國外的各大服務直接打進去呢...