幹壞事是進步最大的原動力
在 Hacker News 上面看到「Cloud GPU Resources and Pricing (fullstackdeeplearning.com)」這篇，原網頁是「Cloud GPUs - The Full Stack」，裡面有些有用的資源可以拉出來獨立看。
雲端的選擇上，因為 H100 看起來還沒普及，所以用上一代的 A100 (80GB) 來看，可以看到大的雲端跟其他家的差異還是蠻大的：
不過這邊好像沒把 vast.ai 放進來。
地端的資訊主要是直接購買顯示卡時的選擇，可以看到如果除了各系列的旗艦卡外 (4090 & 3090 & 2080)，3060 是一張會在考慮到「便宜」而上榜的卡，應該是因為他是一張入門價位的顯卡，卻有 12GB VRAM 的關係：
在接下來七月要推出的 4060 會出 16GB VRAM 版本，應該會取代現在 3060 12GB VRAM 的地位...
在「Farewell to the Era of Cheap EC2 Spot Instances」這邊討論了 Amazon EC2 的 spot instance 最近有上漲的趨勢，像是這張應該是從 web console 拉出來 us-east-1 的 t4g.nano 趨勢：
有不少 region 都有類似的情況，尤其是最常用的 us-east-1 與 us-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 的廣告宣傳...
在 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 Kuzhagaliyev 的 LinkedIn 帳號，這個帳號裡面有提到 2019 到 2020 的時候在 Amazon 裡面當 SDE：
Worked on various computer vision projects as a part of Video Quality Analysis team at 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.
至於算不算是提油... 就見仁見智了。
昨天在 Hacker News 上熱烈討論的文章，是一篇三月就放出來，但昨天被丟上來意外的熱烈討論，在講 Amazon Prime Video 的團隊改寫程式，把 AWS Step Functions 拔掉，並且回頭用 EC2 與 ECS 而省下大量 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 左右？不過真的有這個量的時候機器也可以往上開大一點...
另外還有很多「好用」的雲端服務，但看到帳單後就變得「不好用」的雲端服務... 在用之前先算一下成本就會發現了。
因為 37signals 陸陸續續把所有的服務從雲端搬回地端，DHH 從去年開始寫了一系列相關的文章，開頭應該是這篇：「Why we're leaving the cloud」。
最近的「Cloud exit pays off in performance too」這篇看到個有趣的東西，提到現在的硬體可以很大台，大到可以直接吃整個 Basecamp 服務：
In fact, given that each of our new Dell R7625s have 196 vCPUs, we could actually run the entire Basecamp Classic application, including databases and Redis, on a single such machine! That's just astounding.
其實這也提到了另外一個問題，就是他們的東西一直沒做大，然後也沒有遇到超大的 peak XD
雲端比地端貴是大家都知道的前提 (把網路設備以及 storage 也考慮進來，整體硬體攤提成本來說大概是 1/3～1/4，而頻寬成本會差更多)，但即使團隊會管機房，還是會採用雲端的原因 (優點)：
前者是大家都比較清楚的，在地端如果臨時要一批資料庫等級的機器，通常機房不會有這種等級的機器，需要跟廠商借機器來用，而且裝機再怎麼快也是半天的時機，而雲端上面直接 console 點一點就解決了。
後者是突然爆紅的狀態，幾乎不會發生 (i.e. 做夢)，但是會是跟老闆推銷雲端的重要說詞之一；而且就算發生了，常常還是會遇到程式寫的不夠好，無法 scale out 解決問題，甚至是無法 scale up 解決問題。
所以 37signals 把服務都搬回地端是個正確的決定沒錯，但他提到單機就可以解決所有問題，代表量沒大到需要把 sharding 拿出來，其實有點悲傷... XD
前幾天提到了 Google Authenticator 總算是支援備份功能了：「Google Authenticator 支援備份到 Google Account 的功能」，當初操作的時候沒看到自訂密碼之類的功能，就有在猜應該不是 E2EE，直接攔傳輸內容也被證實沒有 E2EE 了，TOTP 的 secret token 都是直接傳輸的：「PSA: Google Authenticator's Cloud-Synced 2FA Codes Aren't End-to-End Encrypted」。
Google has just updated its 2FA Authenticator app and added a much-needed feature: the ability to sync secrets across devices.
TL;DR: Don't turn it on.
The new update allows users to sign in with their Google Account and sync 2FA secrets across their iOS and Android devices.… pic.twitter.com/a8hhelupZR
— Mysk 🇨🇦🇩🇪 (@mysk_co) April 26, 2023
Google 的發言人回應 CNET 的詢問時只說會有計畫做，但沒有給更細的資料：
To ensure that we're offering a full set of options for users, we have also begun rolling out optional E2EE in some of our products, and we plan to offer E2EE for Google Authenticator in the future.
在意的人就還是先不要開...
前幾天在 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...
把一台本來跑在 Vultr 上的機器搬到 AWS 的 us-east-1 上面，除了剛好把 Ubuntu 18.04 換成 Ubuntu 22.04 外，也把本來用 x86-64 架構的機器換成用 ARM 的 t4g.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：「Application Load Balancer now supports TLS 1.3」。
本來以為早就支援了，翻了一下發現應該是太多產品線的關係搞混了：
ALB 則是到了 2023 才支援 TLS 1.3...