Tag: cdn

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。

在 AWS 的 CloudFront 也有類似的架構，叫做 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. 操作起來要很流暢)...

CloudFront 新增泰國節點

看到 Amazon CloudFront 新增了泰國曼谷節點的消息：「Amazon CloudFront launches in Thailand」，原來泰國之前沒開啊...

Amazon CloudFront announces its first two edge locations in Thailand.

另外依照網路架構，先前泰國的流量應該是往新加坡或是香港跑 (我覺得新加坡可能比較像？)，不過也不是那麼確定... 畢竟地理位置比較近的馬來西亞可以透過陸地就拉過去，不需要走海纜，只是不確定馬來西亞的點有沒有買 transit：

These new edge locations in Bangkok will provide viewers as much as a 30% reduction in p90 latency measures.

然後最近都至少是兩個點在開了，對服務穩定性比較好，維修的影響也比較小...

Backblaze 與 Fastly 合作

Twitter 上看到的消息，Backblaze 與 Fastly，免除 Origin 到 CDN 這段的流量費用：

新聞稿是「Set Your Content Free With Fastly and Backblaze B2」這篇：

Our new collaboration with Fastly, a global edge cloud platform and CDN, offers an integrated solution that will let you store and serve rich media files seamlessly, free from the lock-in fees and functionality of closed “goliath” cloud storage platforms, and all with free egress from Backblaze B2 Cloud Storage to Fastly.

不過這不是第一家提供這樣的方案，在 2018 年的時候就有跟 Cloudflare 合作，免除了 Origin 端到 CDN 端這段費用：「Backblaze 與 Cloudflare 合作，免除傳輸費用」。

Cloudflare 也要支援 AVIF

Cloudflare 針對 Image Resizing 增加了 AVIF 的支援：「Introducing support for the AVIF image format」。

We've added support for the new AVIF image format in Image Resizing.

照 comment 的地方看起來是 Business 功能，之後有機會下放到 Pro，但免費版應該不會出現：

Kornel Ian K Homan • 15 hours ago
This is part of the Image Resizing feature, which is currently available for Business plans. It's coming to Polish in the near future, which is a Pro plan feature.

這跟「Chrome 85 支援 AVIF」應該有些關係，加上其他瀏覽器也陸陸續續打算要支援，是個先做不虧的感覺...

Amazon CloudFront 增加墨西哥與紐西蘭的點

Amazon CloudFront 新增加了四個點，兩個在墨西哥，兩個在紐西蘭：「Amazon CloudFront launches in two new countries - Mexico and New Zealand」。

比較特別的是墨西哥的點仍然是被併入北美區的價錢，也就是 CloudFront 裡面最低的那組價錢：

In Mexico, our two new edge locations in Querétaro will provide viewers as much as a 30% reduction in p90 latency measures. These new edge locations are priced within CloudFront’s North America geographic region.

所以這代表在墨西哥當地的網路成本跟美國是一樣低？

CloudFront 宣佈支援 Brotli

CloudFront 宣佈支援 Brotli：「Amazon CloudFront announces support for Brotli compression」。

官方的說明發現 Gzip 可以好 24%：

CloudFront's Brotli edge compression delivers up to 24% smaller file sizes as compared to Gzip.

Akamai 在「Understanding Brotli's Potential」這邊提到的測試數字稍微做了分類，可以看到在 html 下 Brotli 帶來的改善是最多的。

以前在 CloudFront 上還是可以支援 Brotli，主要是透過後端支援 Brotli 的方式傳回不同的資料，再加上 Vary: Accept-Encoding 的設定讓 CloudFront 針對不同的 Accept-Encoding 分開 cache。

這次的支援等於是讓 CloudFront 理解 Brotli，就可以提昇 hit rate 並且降低後端的壓力：

Prior to today, you could enable Brotli compression at the origin by whitelisting the 'Accept-Encoding' header. Now CloudFront includes 'br' in the normalized 'Accept-Encoding' header before forwarding it to your origin. You no longer need to whitelist the 'Accept-Encoding' header to enable Brotli origin compression, improving your overall cache hit ratio. Additionally, if your origin sends uncompressed content to CloudFront, CloudFront can now automatically compress cacheable responses at the edge using Brotli.

算是補產品線...

CloudFront 支援 TLS 1.3

看到 AWS 的公告，宣佈 CloudFront 支援 TLS 1.3：「Amazon CloudFront announces support for TLSv1.3 for viewer connections」。

預設會自動啟用：

TLSv1.3 is available today and enabled by default across all Amazon CloudFront security policies options. No additional changes are required to your CloudFront configuration to benefit from the security and performance improvements of TLSv1.3 for your viewer connections.

對使用者最大的差異應該還是改善 first byte 的時間 (主要是因為 handshake 時間縮短)，這點 AWS 的人也有提到在內部測試時，美國區的改善情況：

In our own internal tests in the US region as an example, first byte latency for new negotiated connections saw reductions of up to 33% for TLSv1.3 compared to previous versions of TLS.

在 latency 更高的地區應該也會有大幅改善...

Cloudflare 推出了 BYOIP 的服務

Cloudflare 推出了 BYOIP 的服務，用客戶的 IP address 放 routing 出去：「Bringing Your Own IPs to Cloudflare (BYOIP)」。

照敘述上看起來應該是 anycast，不過這邊沒明講：

When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.

裡面沒有提到 IPv4 或是 IPv6，在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到，以 Cloudflare 的技術架構，應該是都支援？

用自己的 IP 的好處，一個明顯的方向就是 firewall 會好設不少，另外如果需要服務中國或是其他管制地區，比較不會因為 IP space 混用誤殺受到影響？

Amazon Lightsail 也推出 CDN 服務了...

Amazon Lightsail 也推出 CDN 服務了：「Amazon Lightsail now offers CDN distributions to accelerate content delivery」。

這個服務是用 CloudFront 為底：

This native service, called Lightsail CDN, is backed by Amazon CloudFront, Amazon Web Services’ CDN platform that uses a global network of servers in over 200 locations across 42 countries to store and deliver your content throughout the world. Lightsail CDN distributions can be created and configured with just a few clicks for a low, predictable monthly price, and you can get started for free.

看了一下價錢，免費方案可以有 50GB/month，一般自己架個 WordPress 之類的 blog 應該是可以涵蓋在內。

付費方案中，USD$10/month 可以給 200GB，但 USD$35/month 只能給 500GB？這邊是用愈多愈貴，沒看懂這個定價方式啊...

但看起來是有不少機會比 CloudFront 便宜 (如果非歐美的流量不少的話)，再來就是 Lightsail CDN 這邊沒有列出每個 request 的費用，所以應該是不算這塊？這樣小檔案很多的話應該也是個選擇？

Amazon Lightsail 一直拿 AWS 自家東西出來市場上打架，現有的 VPS 不知道會怎麼提供類似的方案，搭 Cloudflare 嗎？或是找 Fastly 這些服務搭？(不過話說回來，Fastly 的牌價好貴 XD)

拿 Cloudflare Workers 跑 Geolocation API

在 Hacker News Daily 上看到拿 Cloudflare Workers 跑 Geolocation API：「How to make simple Geolocation service」。

作者想要做一個很簡單的 Geolocation API，一開始的想法是在 AWS Lambda 上用 MaxMind 的資料，但 latency 偏高：

However, I quickly realized that the response time isn't what I've expected - on average the response took somewhere between from 200ms to 500ms. So I started looking for other options.

所以作者就想到是不是有有機會丟到 Cloudflare Workers 上，但發現 license 看起來是個問題，另外因為把 MaxMind 的資料庫丟進去，會超過 worker 的時間限制：

And for this case MaxMind offers GeoLite2 database, however you'll be in charge of hosting this database on your server and making regular updates of the database. You also need to make sure your project is compliant with MaxMind's License.

However, this solution had one really big caveat - MaxMind GeoLite2 database does not work on Cloudflare Workers due to some runtime limitations.

結果作者後來發現 Cloudflare Workers 上本身就會帶 Geoloation 資訊了，不需要另外拉 MaxMind 的資料查：

And after exploring their documentation, I realized that the Request object in function have an access to cf object, which contains some useful information about the visitor, including visitor's country!

另外我翻了一下價錢，主要是算次數的，看起來 Free Plan 就可以 100K/day (執行時間限制是 10ms)，而如果是付費方案的話則是 USD$0.5/M (50ms)，這樣對一些小專案來說，Free Plan 似乎是夠用了...