AWS 推出 Amazon Elastic Container Registry Public (公開版的 ECR)

算是延伸產品線,把 Amazon ECR 變成可以公開使用:「Amazon Elastic Container Registry Public: A New Public Container Registry」。

這篇稍微有趣的地方是,文章裡面的上面這張圖有把 path 模糊化,但下面那張沒有遮,後面的文字也直接有提到 path (這是要給使用者玩的...):

ECR Public 會自動同步到兩個 region,但設定的頁面上好像沒寫會怎麼挑... 另外前面會放 CloudFront 加速。

ECR Public automatically replicates container images across two AWS Regions to reduce download times and improve availability. Therefore, using public images directly from ECR Public may simplify your build process if you were previously creating and managing local copies. ECR Public caches image layers in Amazon CloudFront, to improve pull performance for a global audience, especially for popular images.

費用的部份,意外的有提供一些免費的空間與頻寬可以用,算是在推廣嗎?

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 成本也蠻有幫助的,另外一方面,總算是可以對環境客製化了...

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

Amazon Lightsail 推出 Container 版本

看到 Amazon Lightsail 推出了 Container 版本的消息:「Announcing Amazon Lightsail Containers, an easy way to run containerized applications on the cloud」,另外在「Lightsail Containers: An Easy Way to Run your Containers in the Cloud」這邊也有介紹。

從官方 blog 上的圖可以看到機器規格與價位,比 Lightsail 貴一些:

另外有提到如果之後要轉到 Amazon ECS 或是 Amazon EKS 的話也都可以直接轉,不過我印象中 ELB 的部份還是要設一下,這點看起來 Lightsail 簡化了不少:

If you plan to later deploy your container to Amazon ECS or Amazon Elastic Kubernetes Service, no changes are required. You can pull the container image from your repository, just like you do with Amazon Lightsail.

不過後面實際上是用什麼架構跑啊?如果考慮到安全性的話應該是直接拿 t3.* 的主機直接 1:1 對應,只是包裝成吃 Docker,而不會共用主機?

Travis CI 支援 Arm64 平台的編譯與測試了

剛剛看到 Travis CI 宣佈支援 Arm64 的編譯與測試環境了:「Announcing General Availability of Graviton2 CPU Support!」。

架構上是利用 AWS 推出的機器來做,其中支援的 OS image 目前看起來是以 Ubuntu 為主,其中 16.04 (xenial) 與 18.04 (bionic) 只有 LXD container 的環境,而 20.04 (focal) 則除了 LXD container 環境外,也有完整的 VM 環境可以跑:

Following Arm64 distributions of Ubuntu are available for you as LXD containers:

Xenial (16.04)
Bionic (18.04)
Focal (20.04)

Following Arm64 distribution of Ubuntu is available for you as a full VM option:

Focal (20.04)

看起來底層是用 Ubuntu 20.04 為主力,然後提供 container 跑其他版本。

在網路流量很大時,Container 的網路對資料庫效能的影響

Percona 的「How Container Networking Affects Database Performance」這篇在討論 Kubernetes 上選擇不同的 CNI 對於資料庫效能的影響。

最重要的是結果的這張圖:

可以看到 TPS 與 throughput 都有影響到,要注意的是這是兩個不同的工具測出來的結果,在 TPS 上是用 sysbench,可以看到最好的 Kube-Router 上也掉了 13% 的 TPS:

Another key thing we found was that even in the best-case with Kube-Router we see an approximate 13% decrease in database performance comparing bare metal to running within Kubernetes. This illustrates that there are still improvements to be made to the performance of container networking in Kubernetes.

throughput 是用 iperf3,只要不是真的掉很多,就沒那麼關心了...

不過這個測試另外一個解讀是,如果你用資料庫不單純是 PK find() 類的處理,那麼效能應該是還好,因為會有不少 CPU 資源 (以及對應的時間) 是用在 join 或是其他處理上,對於 latency 與 throughput 應該就沒有那麼敏感了...

AWS Fargate 推出 Spot

相較於 Amazon EC2 有 Spot Instance (可以利用 Spot Instance 的競價機制省下很多費用),這次 AWS re:InventFargate 也推出了對應的產品線:「AWS Fargate Spot Now Generally Available」。

跟 EC2 的相同,你在上面跑的應用程式必須可以接受隨時中斷服務 (i.e. 必須是 crash-safe),常見的情境是 worker 類的程式。

價錢上大約在三折 (寫這篇時 us-east-1 目前的價錢),考慮到啟動的速度比 EC2 快很多,這樣好像是個可以考慮的方案...

Ubuntu 改變放掉 i386 的計畫

先前在「Ubuntu 19.10 要放掉 i386 架構」這邊提到 Ubuntu 要放掉 i386 的計畫,因為造成的迴響很大,現在官方決定修改本來的結論:「Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS」。

在本來的計畫裡,是完全放生 i386 架構 (完全不管):

While this means we will not provide 32-bit builds of new upstream versions of libraries, there are a number of ways that 32-bit applications can continue to be made available to users of later Ubuntu releases, as detailed in [4]. We will be working to polish the 32-bit support story over the course of the 19.10 development cycle. To follow the evolution of this support, you can participate in the discourse thread at [5].

現在則是打算透過 container 技術支援 32-bit library & binary,算是某種緩衝方式:

We will also work with the WINE, Ubuntu Studio and gaming communities to use container technology to address the ultimate end of life of 32-bit libraries; it should stay possible to run old applications on newer versions of Ubuntu. Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries, to solve these issues in the long term.

但應該還是會有程式沒辦法在 container 環境裡跑,看起來官方決定放掉了...

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上:「Kubernetes Failure Stories」,裡面有文章也有演講影片,然後也有重複的公司在不同時間點說明。

先來講 K8S 好了,如果要粗略的解釋 K8S 是什麼東西,我會說就像是架一組 AWS 服務起來,但是是基於 container 而非 VM。

拿 AWS 的詞彙來說,他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI),然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻,這邊就拿 AMI + EC2 來對比),還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念,在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS,而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識,加上 K8S 一直在發展,很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪),然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房,或是用便宜的 VPS (像是 LinodeDigitalOceanVultr),那麼我覺得在上面堆 K8S cluster 還算合理,畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面,然後還想在上面跑 K8S cluster,我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話,可能過一個月後你家就淹水了 XD

另外講一些題外話,因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」),才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage,算是後知後覺...

AWS 宣佈 Fargate 大幅降價

AWS Fargate 大幅降價:「Announcing AWS Fargate Price Reduction By Up To 50%」、「AWS Fargate Price Reduction – Up to 50%」。

先前 Fargate 的定價超級高,基本上是不會有正常應用會丟上去的情境... 如果可以接受 Fargate 的價錢,平常就用 ECS 或是 EKS 開三到五倍的機器在旁邊待機就好了,container scale 的速度還比 Fargate 快。

這次降價幅度很大,vCPU 降 20% 其實不算小,但相較於 Memory 降的 65% 就感覺好像沒降很多 (...):

Effective Jan 07, 2019, we are reducing the price for AWS Fargate by 20% for vCPU and 65% for memory across all regions where Fargate is currently available.

us-east-1m5.24xlarge 的價錢來看是 USD$4.608/hr。以他的 96 vCPU + 384 GiB RAM 對應到 Fargate 來算是 USD$5.59296/hr,大約多 21% 的價錢。

這樣的產品價位看起來才有對應的空間...

AWS 的 Firecracker 技術 (安全的 Container?)

AWS 放出來的 open source 專案 Firecracker,也就是在 AWS 內打造安裝的 container 環境所使用的技術:「Firecracker – Lightweight Virtualization for Serverless Computing」。

依照說明,看起來是利用 crosvm (KVM-based) 但讓他更輕,啟動 image 的時間更快,達到跟 container 類似的效果:

High Performance – You can launch a microVM in as little as 125 ms today (and even faster in 2019), making it ideal for many types of workloads, including those that are transient or short-lived.

Low Overhead – Firecracker consumes about 5 MiB of memory per microVM. You can run thousands of secure VMs with widely varying vCPU and memory configurations on the same instance.

看起來有機會在自己機器上跑看看 (i.e. 非虛擬環境)?跑之前要注意目前只支援 Intel 的硬體:

Firecracker currently supports Intel CPUs, with planned AMD and Arm support. Firecracker will also be integrated with popular container runtimes.