EC2 Spot Instance 價錢的上漲趨勢

在「Farewell to the Era of Cheap EC2 Spot Instances」這邊討論了 Amazon EC2spot instance 最近有上漲的趨勢,像是這張應該是從 web console 拉出來 us-east-1t4g.nano 趨勢:

有不少 region 都有類似的情況,尤其是最常用的 us-east-1us-west-2

上個月 Plurk 的朋友也有聊到類似的情況,在 us-east-1 上愈來愈難找到便宜的 spot instance 機器了,當時還在想是不是有什麼大型活動,但文章出來後才發現大家都有遇到類似的情況。

另外在 Hacker News 上面也有討論:「Farewell to the Era of Cheap EC2 Spot Instances (pauley.me)」,裡面是有提到了一些工具可以再更彈性的調整,用更多邏輯改善成本,像是 AutoSpotting - Community Edition 這個專案用 lambda 幫你調整:

The entire logic described above is implemented in a set of Lambda functions deployed using CloudFormation or Terraform stacks that can be installed and configured in just a few minutes.

回頭來看一下目前的情況 (以及猜測 AWS 的策略),如果 spot instance 的常態價錢維持在牌價的六七成,等於是逼你規劃用 Savings Plans 之類的方案,然後讓 spot instance 慢慢退場。

話說回來,接下來不知道會不會有人去告 90% saving 的廣告宣傳...

另外一則跟 Prime Video 有關的有趣留言

Hacker News 上的「Even Amazon can't make sense of serverless or microservices (world.hey.com)」這邊看到 DHH 抓到機會剛好戳了 AWS 的費用問題,不過讓我注意到的不是 DHH 的文章,而是在 Hacker News 上的留言 35823366,自稱是當時設計這個 serverless 架構的人出來解釋當時的確有壓力測試過,看起來也還 OK:

I actually designed the original serverless system (a few years back when I was still at Prime Video), and yes we did and it did sort of look like it could work until it didn't. Obviously wasn't the right solution for the scale we had in mind (or rather the type of problem we were working on) but it's sad to see the mistake of one team be used to justify shitting on serverless as a general solution.

但這是全新帳號的發言,拿這個 id 去找是可以翻到 TimboKZ 這個 GitHub 帳號,然後一路找也可以看到 Timur KuzhagaliyevLinkedIn 帳號,這個帳號裡面有提到 2019 到 2020 的時候在 Amazon 裡面當 SDE:

Worked on various computer vision projects as a part of Video Quality Analysis team at Prime Video.

是都符合沒錯,但還是不能完全肯定,目前看八卦的心態還是比較多...

Amazon.com CTO 解釋 Prime Video 的那篇文章

先前在「Amazon Prime Video 捨棄 AWS Step Functions 回頭用 EC2 與 ECS 省錢的文章」這篇裡面有提到 Prime Video 團隊寫的文章,有點負面 PR 的感覺。

而讓人意外的是 Amazon.com 的 CTO Werner Vogels 也寫了一篇文章提到這件事情:「Monoliths are not dinosaurs」。

從標題可以看到他是針對 monolith 架構以及其他的架構在討論,而不是在講 AWS 成本問題 (這反而是原本 Prime Video 那篇文章在標題宣傳的),另外也講了一些管理面上的東西,也就是文章裡面的副標題,以及兩段粗體字:

Building evolvable software systems is a strategy, not a religion. And revisiting your architectures with an open mind is a must.

If you hire the best engineers, you should trust them to make the best decisions.

there is not one architectural pattern to rule them all.

至於算不算是提油... 就見仁見智了。

Amazon Prime Video 捨棄 AWS Step Functions 回頭用 EC2 與 ECS 省錢的文章

昨天在 Hacker News 上熱烈討論的文章,是一篇三月就放出來,但昨天被丟上來意外的熱烈討論,在講 Amazon Prime Video 的團隊改寫程式,把 AWS Step Functions 拔掉,並且回頭用 EC2ECS 而省下大量 AWS 費用的文章討論:「Scaling up the Prime Video audio/video monitoring service and reducing costs (primevideotech.com)」,原文在「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」,Internet Archive 的備份Archive Today 的備份

先看文章的部分,裡面提到了他們用 AWS Step Functions,但意外的貴:

The initial version of our service consisted of distributed components that were orchestrated by AWS Step Functions. The two most expensive operations in terms of cost were the orchestration workflow and when data passed between distributed components.

然後改寫程式把所有東西都放在單一 process 裡面跑就好,用標準的 EC2 或是 ECS 就可以 scale 很好,而且也省錢:

To address this, we moved all components into a single process to keep the data transfer within the process memory, which also simplified the orchestration logic. Because we compiled all the operations into a single process, we could rely on scalable Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Container Service (Amazon ECS) instances for the deployment.

可以看出起因是一開始設計時的 overdesign,把可以簡單處理的東西拆開,另外加上雲端在這塊收費特別貴而導致成本爆增... 這件事情偶而會發生,尤其是比較新的東西會沒注意到成本,通常在上線發現不太對的時候就會安排 refactor 掉。

但如果是 Amazon 自家集團的其他團隊出來抱怨,就有很棒的 PR 效果了,所以 Hacker News 上就看到有人在猜可能過不久後文章就會不見 XD (但文章紅了以後應該就不會不見 XD):

My word. I'm sort of gob smacked this article exists.

I know there are nuances in the article, but my first impression was it's saying "we went back to basics and stopped using needless expensive AWS stuff that caused us to completely over architect our application and the results were much better". Which is good lesson, and a good story, but there's a kind of irony it's come from an internal Amazon team. As another poster commented, I wouldn't be surprised if it's taken down at some point.

很政治不正確的文章 XD

以之前的經驗來說,AWS 上類似的東西還包括了 NAT Gateway,這東西只適合在有強資安需求 (像是法規要求),而且需要連外的流量很少的時候適合。

NAT Gateway 在新加坡 ap-southeast-1 要 $0.059/hr (美金,所以大約是 $42.48/mo),以及 US$0.045/GB 的處理費用,所以假設你每天只有 100GB (平均 10Mbps),就等於是 3TB/mo,要 $135/mo。這樣整包就 $172.48/mo 了。

如果讓 EC2 機器直接連去 internet 抓資料的話,這些費用就是 $0,你只要付無論是有 NAT Gateway 或是沒有 NAT Gateway 的 outbound traffic 費用部分 (大多是各種 TCP/TLS/HTTP header)。

比較省成本的解法是用 security group 對 outbound traffic 開放特定的流量來解。

另外一種方式還是 NAT,但是是自己架設 HA 的 NAT service,像是 2015 年的文章「The Right Way to set up NAT in EC2」提到的方法。

這個方法以現在的機種來說,兩台 t4g.nano 的機器加上 EBS 不到 $10/mo,唯一要注意的應該是網路頻寬雖然可以 burst 到 5Gbps,但他的網路頻寬是 credit 機制,當 credit 用完的時候 t4g.nano 記得是剩下 100Mbps 左右?不過真的有這個量的時候機器也可以往上開大一點...

另外還有很多「好用」的雲端服務,但看到帳單後就變得「不好用」的雲端服務... 在用之前先算一下成本就會發現了。

測試 GitHub 與 AWS 可以多快偵測出外洩的 token

前幾天在 Hacker News 上看到「What happens when you leak AWS credentials and how AWS minimizes the damage (xebia.com)」這篇,原文連結在「What happens when you leak AWS credentials and how AWS minimizes the damage」這邊。原文跟 Hacker News 上的寫到東西都頗有趣的,可以分開來講。

先是原文的部份,他抓了一些時間軸:

12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user test-user by AWS
12:34:32 – Various List and Describe calls are made using the leaked credentials
12:35:08 – Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account 12345678’

可以看到推上 GitHub 後,AWS 在一分七秒後就自動加上 AWSCompromisedKeyQuarantineV2 以減少災害擴大,然後再發信件通知。

這個功能可以參考 GitHub 的文件說明:「About secret scanning - GitHub Docs」。

另外在 Hacker News 上面看到有人直接把 secret scanning 當作 API 串來用 (噗),把在 PyPI 上面掃到的 AWS secret 丟上 GitHub 觸發後續的機制:

I set up a project[1] to automatically leak AWS secrets published to the Python package index, which then triggers the secret scanning process and quarantines the keys[2]

1. https://github.com/pypi-data/pypi-aws-secrets

2. https://github.com/pypi-data/pypi-aws-secrets/blob/main/keys...

MariaDB 以及 Trac 在 arm64 上的安裝

把一台本來跑在 Vultr 上的機器搬到 AWSus-east-1 上面,除了剛好把 Ubuntu 18.04 換成 Ubuntu 22.04 外,也把本來用 x86-64 架構的機器換成用 ARMt4g.micro (都是 1GB RAM)。

就效能上來說,t4g 機器的效能很不錯,這兩年 blog 跑的也都還算順,先前公司用起來感覺也很好,然後價錢更便宜,另外加上 AWS 的三年 RI 折扣大約是 4 折的價錢,算是會想要換的主因。

在確認應用跑得起來後,買三年 RI 是 $87.15/3y,所以機器本身的費用大約是 $29.05/y,就算加上 8GB 的 EBS (gp3) 空間費用,整體比本來在 Vultr 的 $6/mo 低不少。

上面跑的是我自己的 Trac,想搬到 AWS 上一陣子了,但有幾個不確定的因素,所以連假期間才有空多花一些時間確認。

第一個是 MySQL 的部份,我自己習慣用 Percona Server 的版本,但目前還沒有 arm64 的套件可以直接裝,要用的話就得自己編以及升級。

在 2021 年的時候 blog 搬到 AWS 的時候就遇過了,本來以為這次有機會,但看了一下還是沒支援,所以還是得用 MariaDB

第二個是 Trac 1.4 只能跑在 Python 2.7 上 (mailing list 上有在討論轉到 Python 3 的事情,但看起來官方的動力也不大...),這在 18.04 的時代是沒什麼問題,但 22.04 下面不知道會爛掉多少東西。

所以只能繼續用 pyenv 扛著,但已經有預期會遇到問題,加上這次又從 MySQL 轉到 MariaDB,應該也會有些地雷...

所以跳下去後遇到的問題就跟上面提到的類似,分成兩塊。

在 MariaDB 這邊第一個遇到問題是,雖然官方有提供 APT server,但沒有在 HTTPS server 上放新的 public key,所以一定得從 key server 撈。

GnuPG 就是沒有直接從 key server 下載變成檔案的功能,一定要先塞到 keystore 裡面再 export 出來,就覺得很...

所以就冒出利用 mktemp -d/tmp 下產生暫存目錄這樣的寫法,讓 GnuPG 把 keystore 放進去,這樣至少在重開機後就會消失:

export GNUPGHOME=$(mktemp -d); gpg --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x177F4010FE56CA3336300305F1656F24C74CD1D8; gpg --export 0x177F4010FE56CA3336300305F1656F24C74CD1D8 | sudo tee /etc/apt/trusted.gpg.d/mariadb.gpg > /dev/null; unset GNUPGHOME

這邊為了安全性,還得把官方提供的 0xF1656F24C74CD1D8 換成 0x177F4010FE56CA3336300305F1656F24C74CD1D8

另外就是整理 MariaDB 需要的 my.cnf 內容,我是拿 Percona Server 5.7 的設定檔來改,只刪掉了跟 GTID 相關的設定就會動了。

而其他 MariaDB 遇到的問題主要是設計改變的問題,在 wiki 上有提到。

接下來是 Trac 1.4 的問題,本來的安裝是用 libmysqlclient-dev,然後再安裝 mysql-python

sudo apt install -y libmysqlclient-dev
pip install mysql-python PyMySQL Pygments Trac

但單純把 libmysqlclient-dev 換成 libmariadb-dev 後,mysql-python 還是編不動,照著錯誤訊息試著 workaround (像是試著把 /usr/bin/mysql_config 指到 /usr/bin/mariadb_config) 半天還是不過,最後找資料發現要改用 mysqlclient

sudo apt install -y libmariadb-dev
pip install mysqlclient PyMySQL Pygments Trac

搞定後後續就一路看錯誤訊息解就可以了...

AWS ALB 支援 TLS 1.3?

AWSALB 宣佈支援 TLS 1.3:「Application Load Balancer now supports TLS 1.3」。

本來以為早就支援了,翻了一下發現應該是太多產品線的關係搞混了:

ALB 則是到了 2023 才支援 TLS 1.3...

AWS 官方推出了自己的 Amazon S3 FUSE 套件

看到「Mountpoint for Amazon S3」這個專案,AWS 自己推出了自己的 Amazon S3 FUSE 套件。Hacker News 上也有一些討論:「Mountpoint – file client for S3 written in Rust, from AWS (github.com/awslabs)」。

Amazon S3 的價錢比其他 AWS 提供的 storage 都便宜不少。以美東第一區 us-east-1 來說,S3 是 $0.023/GB,而 EBS (gp3) 要 $0.08/GB,即使是 EBS (st1) 也要 $0.045/GB。

S3 相較於 EBS 來說,多了 API call 的費用,所以對於不會產生大量 API call 的應用來說 (像是常常會寫很大包的資料到檔案裡),透過 FUSE 操作 Amazon S3 可以讓現有的套裝軟體或是程式直接跑上去。

另外一個常見的應用是讓套裝軟體或是現成的程式可以讀取 S3 的資料。

之前這類應用馬上會想到的專案是 s3fs-fuse,這個專案很久了,大家也都知道多人寫入的部份會是痛點。

這次 AWS 自己出來做的事情有點重工,看起來他想做的事情 s3fs-fuse 都解的差不多了,目前看起來唯一的賣點應該只有 Rust-based,但 s3fs-fuse 主要是 C++,其實也沒差到哪裡:

Mountpoint for Amazon S3 is optimized for read-heavy workloads that need high throughput. It intentionally does not implement the full POSIX specification for file systems.

目前專案還是 alpha release,不確定專案的方向到底是什麼...

Amazon DocumentDB 支援 MongoDB 5.0 協定

看到「Amazon DocumentDB (with MongoDB compatibility) adds support for MongoDB 5.0 wire protocol and client-side field level encryption」這篇,Amazon DocumentDB 推出了 MongoDB 5.0 的支援。

MongoDB 5.0 是 2021 年七月的版本,對使用者端比較重要的看起來是 PII 處理與 TSDB 的支援。

比較感興趣的是,TSDB 的部份是繼續用 PostgreSQL 魔改嗎...?

AWS 推出了 Graviton3 的機種

Amazon EC2 推出了 Graviton3 的機種:「New Graviton3-Based General Purpose (m7g) and Memory-Optimized (r7g) Amazon EC2 Instances」。

第一波只有一般的 m7g 與記憶體型的 r7g,而計算型的 c7g 大家在 Twitter 上猜應該晚點會放出消息。在去年五月就推出了:「AWS 推出 c7g 機種」。

目前只在歐美的 us-east-1us-east-2us-west-2eu-west-1 區提供,亞洲目前都還沒有這些機種可以用:

M7g and R7g instances are available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland) AWS Regions in On-Demand, Spot, Reserved Instance, and Savings Plan form.

官方宣稱比 Graviton2 的 m6g & r6g 多了 25% 的效能,不過我另外查了一下 us-east-1 上的價錢,也貴了 6% 左右,如果依照官方宣稱的數字計算,大約是 18% 左右的 CP 值提昇,對於有實際上跑滿的 CPU 的人是個不錯的效能提昇:

Today I am happy to tell you about the newest Amazon EC2 instance types, the M7g and the R7g. Both types are powered by the latest generation AWS Graviton3 processors, and are designed to deliver up to 25% better performance than the equivalent sixth-generation (M6g and R6g) instances, making them the best performers in EC2.

裡面有提到在 Graviton3 的一個架構上的大改變是記憶體從 DDR4 變到 DDR5,這使得記憶體的傳輸頻寬提昇了 50%:

Both types of instances are equipped with DDR5 memory, which provides up to 50% higher memory bandwidth than the DDR4 memory used in previous generations.

接下來是看有沒有下放到 t 系列的計畫,像是 t5g 之類的,有的話再用看看好了,不過 blog 這台已經買了三年 RI,等到期間滿了之後說不定都有 Graviton4 或是 Graviton5 了...