AWS 推出加速 Lambda 啟動速度的 Lambda SnapStart

今年 AWSre:Invent 又開始了,這一個禮拜會冒出蠻多新功能的,挑自己覺得比較有興趣得來寫。

AWS 針對 Lambda 推出 Lambda SnapStart,改善冷啟動的速度:「New – Accelerate Your Lambda Functions with Lambda SnapStart」。

他拿了一個比較明顯的例子,JavaSpring Boot,範例在「Serverless Spring Boot 2 example」這邊,冷啟動的速度可以從 6 秒降到 200ms:

SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.

方法就是把 initialization 的程式完成後的記憶體打一份 snapshot 存起來,之後的冷啟動第一動變成是 restore 而非再 initialize:

With SnapStart, the initialization phase (represented by the Init duration that I showed you earlier) happens when I publish a new version of the function. When I invoke a function that has SnapStart enabled, Lambda restores the snapshot (represented by the Restore duration) before invoking the function handler. As a result, the total cold invoke with SnapStart is now Restore duration + Duration.

不過不是所有的應用程式都可以直接套用,有些要注意的地方,比較好理解的是連線 (像是對後端資料庫的預連線) 以及暫存檔的部份 (像是預先算好某些資料後寫到暫存檔) 都需要重新建立。

比較特別的是亂數產生器需要重新 initialize,不然會有機率產生出一樣的 random data,這個是一般開發者會忽略掉的:

When using SnapStart, any unique content that used to be generated during the initialization must now be generated after initialization in order to maintain uniqueness.

所以 AWS 有針對 SnapStart 下的 OpenSSL 修正,另外外他們也確認過 Java 的 java.security.SecureRandom 本身就沒問題:

We have updated OpenSSL’s RAND_Bytes to ensure randomness when used in conjunction with SnapStart, and we have verified that java.security.SecureRandom is already snap-resilient.

另外 AWS 也推薦可以直接讀系統的 /dev/random 或是 /dev/urandom,這樣就很自然的不會因為 snapshot 而固定,當然也就沒問題:

Amazon Linux’s /dev/random and /dev/urandom are also snap-resilient.

這個功能說不用另外收費,看起來對 Java 族群還不錯?

網頁大小 14KB 與 15KB 的速度差異

Hacker News 上看到「Why your website should be under 14kB in size」這篇,對應的討論在「A 14kb page can load much faster than a 15kb page (endtimes.dev)」,在講網頁大小 14KB/15KB 的速度差異比 15KB/16KB 大很多的問題:

What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.

原因是 TCP slow start 造成的:

This is because of the TCP slow start algorithm.

而網頁這邊 TCP slow start 目前大多數的實做都是 10 packets 後發動:

Most web servers TCP slow start algorithm starts by sending 10 TCP packets.

然後再組合 1500 bytes/packet 以及 overhead,就差不多是 14KB 了:

The maximum size of a TCP packet is 1500 bytes.

This this maximum is not set by the TCP specification, it comes from the ethernet standard

Each TCP packet uses 40 bytes in its header — 16 bytes for IP and an additional 24 bytes for TCP

That leaves 1460 bytes per TCP packet. 10 x 1460 = 14600 bytes or roughly 14kB!

然後 HTTP/3 也可以看到類似的設計 (出自「QUIC Loss Detection and Congestion Control」:

Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses. Implementations MUST either use pacing or limit such bursts to the initial congestion window, which is recommended to be the minimum of 10 * max_datagram_size and max(2* max_datagram_size, 14720)), where max_datagram_size is the current maximum size of a datagram for the connection, not including UDP or IP overhead.

算是一個小知識... 但對於現在肥滋滋的網頁效果來說就沒辦法了,而且考慮到大一點的網站會在一個 TCP 連線裡面可能會傳很多 request,其實早就超過 TCP slow start 的門檻了。

AWS Lambda 的消息:計費方式 1ms、上限變高、自訂 Image

這次 AWS re:InventAWS Lambda 也更新了不少東西:

首先是計價方式的改變,從本來 100ms 降到 1ms,對於這點 Cliff 有提出來了,cold start 會是成本中很重的一環 (在 https://www.facebook.com/clifflu666/posts/10214677842380050 這邊):

不過從本來的 100ms 變成現在的 1ms 只會變便宜,如果本來 100ms 的價錢就可以接受的話,現在看起來沒有理由變差 (humm,心情例外)。

會改變的是,以前可能不會想要對 cold start 最佳化 (因為做了還是收 100ms 的錢),現在就可以考慮進去讓成本再降了。

第二個是 lambda 的上限會變成 10GB RAM 與 6vCPU,剛好前幾天翻資料的時候,有翻到改版前的限制:「lambda_cpu_cores.md」,之前的上限是約 3GB 的記憶體與 2vCPU,現在拉起來讓你可以跑更大的東西...

第三個是讓你可以自訂 container image,而不需要用 AWS 提供的標準 image 跑,這點對於降低 cold start 成本也蠻有幫助的,另外一方面,總算是可以對環境客製化了...

裡面看起來最重要的應該還是第一個,計價方式讓整個成本評估大幅改變...

Cloudflare 降低 Workers 的 Cold Start 時間的方法...

Cloudflare 改善了 Workers 的 cold start 時間:「Eliminating cold starts with Cloudflare Workers」。

傳統的作法是連線結束後 application 層收到時去拉 worker 起來跑:

他們想到的方法是在收到 TLS 的 ClientHello 封包時就可以拉起來等了:

這點利用了 TLS 啟動時的交換時間,把 cold start 的時間疊起來,不過缺點應該就是同一個 domain 下的所有的 worker 都得拉起來,不過因為只有 cold start 的部份,應該是還好...

各家 Serverless 服務冷啟動 (Cold Start) 的時間

看到「Serverless: Cold Start War」這篇分析了 AWS LambdaAzure FunctionsGoogle Cloud Functions 的冷啟動特性。

裡面分析了多久沒有 request 會需要冷啟動、記憶體的大小對於冷啟動速度的影響、程式語言的影響,以及程式大小的影響。

對於量很少,但是又很在意速度的人來說也許可以研究一下。不過只要有點量 (就算一分鐘只有一次) 應該都不會遇到這塊問題...

ALB 支援 Slow Start 了

這個功能在 ELB Classic 年代時有跟 AWS 提過,到 ALB 支援了 (總算...):「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。

Application Load Balancers now support a slow start mode that allows you to add new targets without overwhelming them with a flood of requests. With the slow start mode, targets warm up before accepting their fair share of requests based on a ramp-up period that you specify.

然後時間可以設定,從 30 秒到 15 分鐘:

Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.

就之前的經驗來說,這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣,可能不會這麼吃這個功能。

主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時,儘量將 CPU 留給 opcache,把常用的頁面 compile 完並且放進 cache,而不是讓大量的連線灌進來,這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久,造成每個連線都很慢才跑完)

AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...

EC2 的 Spot Instance 可以「接關」

Amazon EC2Spot Instance 可以「接關」了:「New – Stop & Resume Workloads on EC2 Spot Instances」。

當 Spot Instance 的競價不足以標到機器時,他會先關起來 (Stop),等到價錢低於競價後就會再打開機器,這時候的狀態就會恢復。另外也提到了必須是使用 EBS 的機器才支援:

Amazon EC2 Spot now allows Amazon EBS-backed instances to be stopped in the event of interruption, instead of being terminated when capacity is no longer available at your preferred price. Spot can then fulfill your request by restarting instances from a stopped state when capacity is available within your price and time requirements.

用法是把 Spot Instance 的關機設定設為 Stop:

To use this new feature, choose “stop” instead of “terminate” as the interruption behavior when submitting a persistent Spot request. When you choose “stop”, Spot will shut down your instance upon interruption.

恢復的時候就會儘量保持一樣地開回來 (連 instance id 都相同):

When capacity is available again within your price and time requirements, Spot will restart your instance. Upon restart, the EBS root device is restored from its prior state, previously attached data volumes are reattached, and the instance retains its instance ID.

是個接關的感覺 XD

在 AWS 上跑 Consul 與 Vault 的介紹

HashiCorp 這邊看到在 AWS 上跑 ConsulVault 的介紹文章:「Consul and Vault on AWS: Quick Start Guides」。

Consul 負責 service discovery 與 health check (還有簡單的 key-value 功能);Vault 則負責管理各種 secret (像是資料庫的帳號密碼之類的資訊)。

這些資料分別可以在「HashiCorp Consul on AWS」與「HashiCorp Vault on AWS」看到,打開 PDF 後可以發現是 AWS 與 HashiCorp 的人合作生出來的文件,要在上面實作的人可以看一看,應該是可以少走冤枉路...

最佳化 nginx 的 TLS Time to First Byte (TTTFB)

在「Optimizing NGINX TLS Time To First Byte (TTTFB)」這篇文章裡在討論要如何讓 nginx 的 TLS Time to First Byte (TTTFB) 盡可能短。

可以看到文章裡面用到兩個方法,一個是修改 nginx 的程式碼縮小 TLS record size。我對是覺得頗危險,尤其是作者的改法不知道有什麼 side-effect... (要注意 nginx 裡面直接拿 NGX_SSL_BUFSIZEBIO_set_write_buffer_size 使用,這代表有可能還有其他的地方也是這樣搞?)

第二個方法是開啟 TLS False Start,目前主流的瀏覽器都陸陸續續支援了。

這是文章作者的測試:

可以看到時間減少的相當多。

現在是期望作者這篇文章的測試可以讓 patch 合併回 mainstream 後再用,這樣有比較多人 audit...