AWS 區域間的連線測試

Hacker News 首頁上看到「AWS Latency Monitoring」這個,看起來是常態性在所有的機房都開機器一直測試蒐集資料,就可以直接拉出來看...

有常見的 p50 與 p99 資訊,對於在規劃架構的時候還蠻有用,在「mda590/cloudping.co」這邊可以看到他是用 LambdaDynamoDB 的 endpoint 測試。

好像沒有 packet loss rate 的資訊,這個也蠻重要的...

AWS 大阪區開放

AWS 大阪區開放給大家使用了,而且有標準的三個 AZ 可以用:「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」。

大阪區因為之前就已經有機房 (附加在東京區),所以對應的 routing 看起來不算太差,但也沒有特別好... 剛剛測了一下從 HiNet 光世代過去的 latency,分別是 35.5ms (東京的 ap-northeast-1) 與 34.6ms (大阪的 ap-northeast-3)。

另外測了其他的 ISP,有些上日本的點是以東京為主,反而會多繞了一圈,大阪區的 latency 會比較高。

不過如果放遠來說,東京大阪的直線距離大約是 400km,光纖的傳輸速度大約是光速的 2/3,所以單趟大約差了 2ms,如果有機會最佳化的話應該有機會擠出 4ms 出來?

然後是 EC2Pricing 頁面,上面還是寫 Asia Pacific (Osaka-Local),無法確定是新資料還是舊資料,但以往的慣例應該是更新了...

對照文章裡有提到支援的機器,目前看起來還沒有很齊,像是目前都還沒有 AMDARM 架構的機器,另外也沒有 GPU 類型的機器:

The Asia Pacific (Osaka) Region supports the C5, C5d, D2, I3, I3en, M5, M5d, R5d, and T3 instance types, in On-Demand, Spot, and Reserved Instance form. X1 and X1e instances are available in a single AZ.

就支援的類型隨意挑了幾個 instance type 比較,翻了一下價錢看起來跟東京的一樣。

整體看起來,如果是有考慮到異地的需求是可以考慮,另外如果是新的服務的話也可以考慮看看 (畢竟各 ISP 應該有機會再把 latency 壓出來),但既有的服務應該不需要急著搬...

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. 操作起來要很流暢)...

gp3 (Amazon EBS) 的 latency

昨天把手上所有的 Amazon EBSgp2 換到 gp3 了:「Amazon EBS 的 gp3 可以用在開機磁碟了」,今天早上來看一下狀態,整體看起來是還 OK,不過有些地方值得注意的,像是標題寫到的 latency。

我抓了跑 GitLab 的機器來看,可以很明顯看到讀寫的 latency 都變高了:

AWS 又有提到這些數字資料有經過轉換,看起來是 gp2gp3 的數字意義本來就不一樣,所以他必須想辦法轉換,所以也有可能是因為這個轉換導致的?

This graph has had transformations applied to it and will differ from what is natively found in CloudWatch. Due to this some functionality is reduced.

不過其他的數字倒是沒什麼變化,系統的負荷量其實也還好,就先丟著跑...

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 更高的地區應該也會有大幅改善...

SpaceX Starlink 的延遲與速度

SpaceXStarlink 已經有些人開始在測試了,在 Speedtest.net 上也已經有人挖到資料,可以看出他的延遲與速度了:「SpaceX Starlink speeds revealed as beta users get downloads of 11 to 60Mbps」。

報導的資料主要是從 Reddit 上的拉出來的,如果要看原始的資料,可以參考「List of Confirmed Starlink Speed Tests」這篇列出來的連結。

延遲可以低到 20ms 左右,不過比較常見是 30ms~40ms,高的時候可以看到 90ms 左右,這樣看起來頗有競爭性的,下載速度看起來也還不錯...

目前看起來都是加州地區的測試,查了資料看起來是目前開放的區域有限 (加拿大南部與美國北部),之後可以看開放其他地區的情況。

另外未來如果更多衛星打上去,網路的品質應該會更好,不過對天文學家看起來是場災難,光害的問題看起來很嚴重,像這張曝兩秒的照片就可以看出來這六顆的情況:(出自「File:Starlink 6 satellites.jpg」)

AWS Lambda 的 Provisioned Concurrency

AWS Lambda 推出了 Provisioned Concurrency,降低冷啟動所需要的時間以確保效率:「New – Provisioned Concurrency for Lambda Functions」。

看 benchmark 的資料就很清楚,可以避免冷啟動所產生的延遲:

這邊也可以看出來就算是冷啟動,大約也是多個一秒多。如果這個延遲是需要被處理的,就可以考慮用 Provisioned Concurrency 了。

價位上是依照保留的量:

You only pay for the amount of concurrency that you configure and for the period of time that you configure it. Pricing in US East (N. Virginia) is $0.015 per GB-hour for Provisioned Concurrency and $0.035 per GB-hour for Duration. The number of requests is charged at the same rate as normal functions. You can find more information in the Lambda pricing page.

不過如果量再更大,而且考慮成本,應該會考慮改回傳統的架構,用多台 EC2 instance 跑...

Amazon Aurora MySQL 5.7 也可以上 Global Database 了

AWSAmazon Aurora MySQL 5.7 版本推出了 Amazon Aurora Global Database:「Aurora Global Database is Now Supported on Amazon Aurora MySQL 5.7」。

看起來 MySQL 系的 Global Database 就是跨區的 master-slave 架構 (所以標榜降低了 read latency,但沒有提到 write latency):

An Amazon Aurora Global Database is a single database that spans multiple AWS regions, enabling low latency global reads and disaster recovery from region-wide outages.

另外可以看到是 1 秒,所以應該是 async replication:

Aurora Global Database replicates writes in the primary region with typical latency of <1 second to secondary regions, for low latency global reads.

然後可以跨區切換:

In disaster recovery situations, you can promote the secondary region to take full read-write responsibilities in under a minute.

看了一下好像不用多付服務費用,就是各區自己的費用,加上傳輸的費用而已,看起來是個還不錯的服務?

Instagram 改善影片上架速度的方式

不是什麼魔法,其實是改產品面上的規格 (但是發表到 Instagram Engineering 上):「Video Upload Latency Improvements at Instagram」。

最原始的版本是所有的格式都轉完後才可以上架:

然後把規格改成最高畫質的版本轉完後就可以先上架:

The idea is, instead of blocking until all video versions are available, we can publish the video once the highest-quality video version is available.

然後是把影片切段上傳,所以傳一半就可以先處理一半,變成 pipeline 的概念,但增加程式的複雜度,以及被迫要調整影片品質的參數:

Segmented uploads reduce upload latency in many cases but come with a few tradeoffs. For instance, segmented uploads increase the complexity of the pipeline. There are some quality metrics that are only available per segment at transcode time, such as SSIM. These metrics are not helpful to us on a per segment basis. Therefore, we need to do a duration weighted average of the SSIM of all segments to come up with the SSIM of the whole video. Similarly, handling exceptions is more complex since there are more cases to handle.

另外有一種特例是上傳的影片本身就已經符合伺服器的規格,這樣的話可以直接放行 (不過這樣不會有 security concern 嗎...):

Another performance optimization we use to improve the upload latency and save CPU utilization is something we call a “passthrough” upload. In some cases, the media that is uploaded is already ready for playback on most devices.

都是想的出來而且會帶有 tradeoff 的方法,而不是完全正面的改善 :o

Twitter 對 2x 與 3x 的圖片的研究...

所以發現很多時候用 2x 的圖片就夠了?:「Capping image fidelity on ultra-high resolution devices」。

會這樣討論主要是發現螢幕特性:

The most modern screens are OLED. These screens boast some really great features like pure blacks, and are marketed as 3x scale. However, nearly no "3x scale" OLED actually has perfect 3x3 pixels per dot on their screen.

因為螢幕不是真的到 3x 的要求,丟 2x 的圖片出去就好,省頻寬又省下載時間:

This means that most OLED screens that say they are 3x resolution, are actually 3x in the green color, but only 1.5x in the red and blue colors. Showing a 3x resolution image in the app vs a 2x resolution image will be visually the same, though the 3x image takes significantly more data. Even true 3x resolution screens are wasteful as the human eye cannot see that level of detail without something like a magnifying glass.

省下 38% 的資料量,32% 的時間:

There's no difference that the human eye can see, but will save 38% on data and 32% on latency on the capped image load for this particular example which is reflective of most images that load on Twitter.

這也另外帶出了其他的想法,如果沒有太多時間研究的話,可以考慮先提供 2x 的就好,不需要特地做 3x 的版本...