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 左右?不過真的有這個量的時候機器也可以往上開大一點...

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

Imgur 改變使用條款,把 Imgur 的圖片都搬回本機上

Hacker News 上看到 Imgur 的使用者條款改變的消息:「Imgur will ban explicit images on its platform this month」,在 TechCrunch 文章標題提到的東西對 blog 影響不大,反倒是公告裡面另外提到的事情比較傷。

Imgur 在「Imgur Terms of Service Update [April 19, 2023]」這邊提到了:

Our new Terms of Service will go into effect on May 15, 2023. We will be focused on removing old, unused, and inactive content that is not tied to a user account from our platform as well as nudity, pornography, & sexually explicit content.

所以很少被存取的內容也會有機會被移除掉,這導致一堆小的 blog 或是 forum 用到的內容也會爛掉。

所以決定先搬出來,掃了一下 WordPress 資料庫裡面的內容,把檔案先拉下來,弄個 CloudFront 擋在前面 (有 free quota 的關係),然後把資料庫裡面的連結整批換掉。

另外是新的內容要丟哪裡,所以用 PHP 寫了一個很簡單的 self-hosted image server,程式碼在 GitHub 上面可以翻到:「i.gslin.com」。

裡面除了 PHP 以外,也練了一下 javascript,收 paste 事件把 image/png 的資料用 fetch() 傳到 server 端處理。

現在功能還很陽春,但至少能開始用,之後再逐步加功能上去。等功能變多變複雜之後,可能會用 Composor 掛套件上去... 但現在還算簡單,一個 upload.php 處理所有事情就好。

用 RSS-Bridge 接服務

查資料的時候發現 RSS-Bridge 這個用 PHP 寫的專案,直接找個 PHP hosting 架起來就可以用了,沒有什麼其他的需求。

簡單架起來測了一輪,看起來不賴啊,如果一般人要用的話可以考慮就用這個專案就好,量很少的人可以用官方列出來的 Public instances 玩一下,量多的人可以自己架,PHP hosting 還蠻好找的,官方要求要 7.4+,注意一下 PHP hosting 提供的版本應該不會有太多問題。

自己寫的 feedgen 比較偏順便練 Python,不過當時的確是還不知道有這樣的專案,看了一下 GitHub 上的 tag 記錄,2013 就有的專案...

測試 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...

OpenSSH 與 Dropbear 對 Ed25519 的支援

查了一下這兩個 server 端的軟體支援 Ed25519 的時間點。

OpenSSH 是在 2014/01/30 的 6.5 就支援了:

* ssh(1), sshd(8): Add support for Ed25519 as a public key type. Ed25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys.

算是相當久以前就支援了。對應到第一個支援的 Debian 版本是 Jessie 使用的 OpenSSH 6.7:「sshd(8) — openssh-server — Debian jessie — Debian Manpages」;第一個支援的 Ubuntu (LTS) 版本是 Trusty (14.04) 用的 OpenSSH 6.6:「openssh source package in Trusty」。

Dropbear 這邊就晚不少,在 2020/06/15 的 2020.79 版本才支援:

- Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav Grishenko. This also replaces curve25519 with a TweetNaCl implementation that reduces code size.

所以對應到第一個支援的 Debian 版本是 Bullseye 的 2020.81:「Debian -- Details of package dropbear in bullseye」;第一個支援 Ubuntu (LTS) 的版本是 Jammy (22.04) 的 2020.81:「Ubuntu – Details of package dropbear in jammy」。

這樣看起來如果就是想要用 Ed25519 的話,變成 server 端的軟體得配合:預設裝的 sshd 應該都是 OpenSSH,如果想要換 Dropbear 的話要看 distribution 內給的版本夠不夠新,或是透過 PPA 之類的方法裝新版。

但大多數採用 BusyBox 的機器應該沒有採用新版 Dropbear (像是 AP 刷機),這邊還是得使用其他 key format,如果要避開 NIST 有介入的格式,就還是得用 ssh-rsa 了。

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

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

Tailscale Funnel 公開測試

去年 11 月的時候寫過 Tailscale Funnel 的消息:「Tailscale 也推出類似 Cloudflare Tunnel 的產品,Tailscale Funnel」,剛剛則是宣佈公開測試:「Tailscale Funnel now available in beta」。

測了一下,設定不算太難,但有些步驟要做:

  • 在網頁上先允許 Access Controls 內的 Funnel。
  • 然後允許 DNS 內的 HTTPS Certificates。
  • 剩下就是照著文件跑,在本地跑對應的指令。

他的想法是把 *.ts.net 這個網域拿出來 internet 上面用,但他希望 Let's Encrypt 簽的 SSL key 應該要放在本地端,而不是讓 Tailscale 看到內容。

但同樣也考慮到使用者的體驗,Tailscale 不需要使用者自己處理 SSL certificate 一堆事情,而是實做在 tailscaled 這隻程式裡面,讓本地端的程式還是走 HTTP 而非 HTTPS。

對應的,使用者如果想要取得對應的 key 與 cert,也可以透過 tailscale cert 指令取得。

測了一下位置,HiNet 的使用者會透過東京的節點轉進來,拿來跑測試開發機應該是夠用。

以他的用法來說,跟 Cloudflare Funnel 的定位不太一樣,反倒是擠壓 ngrok 這類服務。