Amazon API Gateway 可以獨立運作了...

Amazon API Gateway 先前一定要跟 Amazon CloudFront 綁在一起 (而且還是很奇怪的 distribution,不是 Price Class 裡面任何一種分類),現在總算可以獨立自己運作了:「Amazon API Gateway Supports Regional API Endpoints」。

A regional API endpoint is a new type of endpoint that is accessed from the same AWS region in which your REST API is deployed. This helps you reduce request latency when API requests originate from the same region as your REST API.

而且這樣一來,如果還是要用 Amazon CloudFront 擋在前面的話,可以自己選擇 Price Class:

Additionally, you can now choose to associate your own Amazon CloudFront distribution with the regional API endpoint.

以前用起來頗莫名其妙的 XDDD

CloudFront 的 Regional Edge Caches

Amazon CloudFront 前陣子宣佈了 two-tier 架構:「Announcing Regional Edge Caches for Amazon CloudFront」。

一般的 CDN 是 edge 收到後就打到 origin,這會使得 origin 的量比較大。而 two-tier 架構則是在中間疊一層降低對 origin 的量。這種架構對於直播時的 pattern 幫助很大:由於量很大,會需要用大量的 edge server 支撐,而 edge server 一多就對 origin 產生巨大的壓力。

一般直播 95% 的 hitrate 表示外面 20Gbps 的流量就會造成 origin 1Gbps 的流量,通常用 two-tier 可以拉到 98%+ (CDN vendor 有調整過可以到 99%+)。

這種技術在 Akamai 叫 Tiered Distribution,在 EdgeCast 叫 SuperPoP,而現在 CloudFront 也推出了,叫做 Regional Edge Cache:

The nine new Regional Edge Cache locations are in Northern Virginia, Oregon, São Paulo, Frankfurt, Singapore, Seoul, Tokyo, Mumbai, and Sydney.

edge 會先到這幾個 regional edge 再到 origin:

These locations sit between your origin webserver and the 68 global edge locations that serve traffic directly to your viewers.

然後預設都開啟了,沒有額外費用:

Regional Edge Caches are turned on by default for your CloudFront distributions; you do not need to make any changes to your distributions to take advantage of this feature. There are also no additional charges to use this feature.

不過這個架構對於 latency 應該不會太好,沒得關閉有點奇怪...

LinkedIn 的工程師分析 TCP Anycast 技術的穩定性與效能

LinkedIn 的工程師測試了 TCP Anycast 技術的穩定性以及效能:「TCP over IP Anycast - Pipe dream or Reality?」。

由於 stateless 再加上一個封包就傳的完的情況下,Anycast 技術被用在 DNS 上已經很長一段時間了,目前大多數 CDN 業者也都有用 Anycast 技術加快 CDN 的回應速度。

但 TCP 因為 stateful,如果 router 上採用的方式有問題,那麼就會導致封包可能會送到不同節點,這會是個嚴重的問題。不過很早之前,幾乎所有的骨幹 router 都已經支援 flow-based load balancing policy:

Most routers now do a per-flow load balancing, meaning packets on a TCP connection are always sent over the same path, but even a small percentage of routers with per-packet load balancing can cause the website to be unreachable for users behind that router.

所以 LinkedIn 的人試著測試 TCP Anycast 技術的穩定性:

So, to validate the assumption that TCP over anycast in the modern internet is no longer a problem, we ran a few synthetic tests.

測試的方式是設定 web server,讓下載速度不快,然後設了好幾個點並且放出對應的 routing,用 Catchpoint 服務監控,如果不穩定的話,應該就會收到 RST 中斷連線:

We configured our U.S. PoPs to announce an anycast IP address and then configured multiple agents in Catchpoint, a synthetic monitoring service, to download an object from that IP address. Our web servers were configured to deliberately send the response back slowly, taking over a minute for the complete data transfer. If the internet was unstable for TCP over anycast, we would observe continuous or intermittent failures when downloading the object. We would also observe TCP RSTs at the PoPs.

而好消息是,測試起來相當穩定:

But even after running these tests for a week, we did not notice any substantial instability problems! This gave us confidence to proceed further.

所以也因此可以看到 CacheFlyCloudFlare 兩家採用 TCP Anycast 技術:

[S]ome popular CDNs have also started using anycast for HTTP traffic.

由於穩定性的部份沒問題,所以接下來就是討論效率。

Anycast 是基於 routing 而決定要怎麼走,目標是希望可以透過 routing 取得 latency 最低的點。但實務上會把成本考慮進去,有可能會走到比較遠的點。在測試中可以發現北美的部份 Anycast 表現的比 GeoIP 好,但離開北美就掉很多:

所以 LinkedIn 決定用「Regional Anycast」,先用 GeoIP 決定要丟到哪個洲,而每個洲共用一個 Anycast 位置,這個方法讓效能提昇不少,全球在分配時 sub-optimal 的比率從 31% 降到 10% (i.e. 沒有分配到最好的點的比率):

上面主要是讀 LinkedIn 文章的心得,後面就是感想了。

TCP Anycast 用 CDN 上其實是相當吃虧的技術,由於 routing 的掌控權不再自己手上,有很多重要的手段是沒辦法做到的。

首先是當對外流量已經滿載時,不能切換到其他機房的機器,這邊講的「對外流量」不是 CDN 本身而已,而是中途任何的線路滿載都算,像是 HiNet 對 CloudFlare 香港機房的情況就很明顯。

另外在被 DDoS 時,由於沒辦法導流,在被攻擊時幾乎只剩下 clean pipe 類的解法,而同時間其他用戶會因為流量大量流入機房而一起被波及到。GeoIP 的方式彈性就大很多。

當然,還是有可以列出來的好處。主要是對於需要有固定 IP 應用來說 (像是 firewall 設定需求),TCP Anycast 滿足了這點。

只能說不同市場有不同的產品線在供應啦,不同的情境下有不同的需求...