換成 t4g.small 後的一些整理

昨天在這邊提到因為 Amazon EC2t4g.small 提供了 free tier 方案 (到今年年底),blog 主機剛好從 t4g.micro 改成用 t4g.small,到年底前可以看看有沒有 t5g 或是類似的主機出來:「往上升級或是用 Unlimited mode 撐」。

除了換完後 CPU credit 給的量上升減緩了情況以外,我在檢查時才發現 PHPopcache 的 cache 使用量也超過預設值 128MB 了,改成 192MB 後看起來 CPU usage 也有下降一些:

這點算是先前沒注意到的,上面 PHP 跑兩個 WordPress 以及一個 MediaWiki (都掛了各式各樣的 plugin & extension),還有一個自己寫的小東西,這樣會超過 opcache 的 cache 大小...

現在換到 t4g.small 後總算又開始養的起 CPU credit 了:

另外也補上幾個 CloudWatch Alarms (看起來 free tier 是十個) 監控主機的 CPUCreditBalance,然後透過 AWS Chatbot 接到自己的 Slack 上,至少之後有狀況的時候會主動通知。

往上升級或是用 Unlimited mode 撐

這個 blog 跑在 Amazon EC2t4g.micro 上面,以往跑起來 baseline 是 10% CPU credit 也還算夠用,但最近的 loading 特別的大,發現是有 bot 在砍站砍的比較兇 (參考「t4g 的 CPU credit 被吃完了」這邊),雖然擋掉後有降不少,但看起來還是比之前高不少:(這邊是一天的平均,拉三個月資料來看)

以往這種一陣一陣的可以靠 CPU credit 頂過去,但因為先前 CPU credit 被 bot 砍完後沒了,就常常撞到底,只好先開 Unlimited mode 擋著了。

另外一方面,當初買的三年 RI 時間也快到了 (居然),這幾天差不多要處理了:

Start
February 9, 2021, 17:43 (UTC+8:00)

Expires
February 9, 2024, 17:43 (UTC+8:00)

升級到 t4g.small 剛好會符合 AWS 的免費方案,看起來可以先掙扎一陣子:

Until December 31, 2024, all AWS customers will be enrolled automatically in the T4g free trial as detailed in the AWS Free Tier. During the free-trial period, customers who run a t4g.small instance will automatically get 750 free hours per month deducted from their bill during each month.

我記得我算過但沒找到文章,所以這邊還是算一下... 如果 t4g.small 要錢的話,與 Unlimited mode 的消費差異大概是多少。

us-east-1t4g.small 是 $0.0168/hr,用 720 小時換算是 $12.096/mo。

假設 CPU 使用率平均在 15%,那用 t4g.micro 的 $0.0084/hr 會是 $6.408/mo,另外加上 5% * 2vCPU = 10% 的 Unlimited mode 費用 ($0.04/hr/vCPU),會是 $2.88/mo。

假設 CPU 使用率平均在 20% (剛好跟 t4g.small 的 baseline 相同的話),會是 $5.76/mo,所以如果用不到對應的記憶體的話,跑 Unlimited mode 會比較划算。

先開一張票。年底的時候再來看看當時的機種與優惠方案...

t4g 的 CPU credit 被吃完了

這個站 blog.gslin.org 掛了三個多小時:

先連機器 SSH 看起來是正常的,但習慣性的 w 看一下情況發現 CPU load 有 6.x,用 top 看一下就看到幾隻 php82-fpm 跑滿 CPU,心裡大概有底是被砍站了...

先把 nginx 停下來,瞄了一下 /var/log/nginx 下面的 log 就知道是 ClaudeBot 造成的,看起來都是從 AWSus-east-1 機器打過來的。

然後翻一下 log 看看什麼時候開始打的,先看 log 已經被 gzip 起來的這些:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log.{?,??}.gz | xargs -n1 | xargs -n1 -I% sh -c "echo %; zgrep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log.2.gz
  13031  169403 1986719
/var/log/nginx/blog.gslin.org_ssl-access.log.3.gz
    459    5967   85350
/var/log/nginx/blog.gslin.org_ssl-access.log.4.gz
  14533  188929 2219819
/var/log/nginx/blog.gslin.org_ssl-access.log.5.gz
   6502   84526 1026178
/var/log/nginx/blog.gslin.org_ssl-access.log.6.gz
  32483  422279 4905919
/var/log/nginx/blog.gslin.org_ssl-access.log.7.gz
  21304  276952 3221877
/var/log/nginx/blog.gslin.org_ssl-access.log.8.gz
   7921  102973 1199356
/var/log/nginx/blog.gslin.org_ssl-access.log.9.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.10.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.11.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.12.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.13.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.14.gz
      0       0       0

看起來是從 blog.gslin.org_ssl-access.log.8.gz 這邊開始的,大概是 1/25 開始 (機器上面是 UTC 時間):

-rw-r----- 1 www-data adm   1894325 Jan 26 00:00 /var/log/nginx/blog.gslin.org_ssl-access.log.8.gz

然後再來看一下最近的 log,看起來是這兩天打的特別重,到五萬多:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log{,.?} | xargs -n1 | xargs -n1 -I% sh -c "echo %; grep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log
  29436  382668 4387703
/var/log/nginx/blog.gslin.org_ssl-access.log.1
  51712  672256 7852345

拉了 AWS 的圖來看跟預期的差不多:

機器是 t4g.micro 而且沒開 burstable,先前差不多都是略低於 10% 的線在跑,剛好利用 CPU credit 的概念,這幾天看起來就是被打而跑上去。

好像該補一下 alarm,丟到我自己的 Slack 以及 Pushover...

把 AWS 上的 EC2 instance 改成 IPv6-only

因為「AWS 將開始收取 IPv4 的 Public IP 費用」的關係,先試著把其中一台 EC2 instance 改成 IPv6-only,結果遇到不少問題...

首先是對外服務的部分,本來想用 CloudFront 擋在前面,但 CloudFront 到現在還是不支援 IPv6-only origin:「CloudFront support for IPv6 origins」,所以這邊的選擇變成是 Cloudflare

第二個是 AWS 自家的 API 還是有些沒有 IPv6 address,像是取得 AWS 擁有的 IP pool 的 https://ip-ranges.amazonaws.com/ip-ranges.json (本來是要取得 CloudFront 的區段,用在 nginx 的設定裡)。

另外就是周邊的問題,很多服務都沒有 IPv6 address,像是 api.slack.com

各種 proxy 與 NAT 架構還是必要的措施...

捷克政府宣布 2032/06/06 政府網站將停用 IPv4 服務

看到「Czech republic sets IPv4 end date (konecipv4.cz)」這篇,捷克政府公告了政府網站將在 2032/06/06 停用 IPv4 服務:「Czech republic sets IPv4 end date」。

On 17 January 2024, the Government of the Czech Republic approved the material "Restarting the implementation of DNSSEC and IPv6 technologies in the state administration". On the basis of this decision, the Czech state administration will stop providing its services over IPv4 on 6 June 2032. Thus, the Czech Republic knows its IPv4 shutdown date.

剛好昨天在試著將手上 AWSEC2 instance 拔掉 IPv4 address (因為 2024/02/01 開始收費,參考先前寫的「AWS 將開始收取 IPv4 的 Public IP 費用」),結果還是遇到相依服務還沒有上 IPv6 endpoint 的問題,如果要轉移的話得開 DNS64NAT64,但因為目前就只有兩台小機器在 AWS 上,在上面租 NAT64 或是自己架 NAT64 的費用反而比付 IPv4 address 的費用還貴,就先暫時丟著了。

我這邊遇到的問題是 api.slack.com 目前只有 IPv4 address,這邊因為是走 HTTPS,也許可以靠其他在有 IPv6 address 的 VPS 上的 proxy server 解決 (我剛好有租一些 VPS instance),這幾天再來看看怎麼弄...

CloudFront 支援 4096-bit RSA 的 SSL/TLS certificate 了

CloudFront 總算支援 4096-bit 的 RSA SSL/TLS certificate 了:「Amazon CloudFront now supports 4096-bit RSA TLS certificates」。

翻了一下 AWS ACM,看起來是 2020 年以前就支援 4096-bit RSA SSL/TLS certificate 了,CloudFront 晚蠻多的...

另外查了一下目前的強度,NSA 給出 2048-bit RSA 對到 112-bit strength,而 3072-bit RSA 對到 128-bit strength;至於 4096-bit RSA,目前是估算大約在 140-bit strength,有點微妙的數字。

看起來主要應該是給 compliance 需求使用的,有些舊的 library 未必支援 ECC 類的演算法,還是得透過拉高 RSA key size 來增加安全性。

AWS 延長 t4g.small 的 free trial

Plurk 上看到朋友貼的「Announcing Amazon EC2 T4g Free Trial Extension」。

t4g.small 的 free trial 延長到明年年底了:

The Amazon Elastic Compute Cloud (Amazon EC2) T4g instance Free Trial is extended to December 31, 2024. All new and existing AWS customers can utilize the free trial to automatically deduct up to 750 hours per month with the t4g.small instances through December 31, 2024. You can start building on Graviton-based instances for no charge with the T4g free trial, though charges may apply for surplus CPU credits. Refer to Amazon EC2 FAQs for more details on the free-trial.

這台算是還蠻好用的 ARM-based 主機,t4g.small 是 2 vCPU + 2GB RAM 的規格,如果是自己會 tune 的話已經可以做不少事情了,再加上 EC2 在前 12 個月的 t3.micro (2 vCPU + 1GB RAM) 免費,就已經可以玩不少東西了:

750 hours per month of Linux, RHEL, or SLES t2.micro or t3.micro instance dependent on region

Amazon RDS 推出 RDS Extended Support

AWSAmazon RDS 推出了 MySQL 5.7 與 PostgreSQL 11 的 RDS Extended Support 服務:「Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support」。

直接看官方整理的這張表格比較清楚:

基本上都到 2027Q1 左右,差不多再多支援三年。

另外表上的時間有些接不起來的地方,則是在 Note 的地方說明。

其中 MySQL 5.7 的部分分成兩塊,其中 RDS for MySQL 5.7 的部分是比較清楚的:原來的 RDS standard support 到 2024/02/29,後續從 2024/03/01 馬上接付費的 RDS Extended Support。

Aurora MySQL 2 的 RDS standard support 則是直接一路到 2024/10/31,然後 2024/11/01~2024/11/30 的 RDS Extended Support 不收費,從 2024/12/01 開始收費:

RDS Extended Support for Aurora MySQL 2 starts on November 1, 2024, but will not be charged until December 1, 2024. Between November 1 and November 30, all Aurora MySQL 2 clusters are covered under RDS Extended Support.

而 PostgreSQL 11 的部分都一樣 (RDS for PostgreSQL 11 與 Aurora PostgreSQL 11),原來的 RDS standard support 到 2024/02/29,而 2024/03/01~2024/03/31 的 RDS Extended Support 則是免費的,從 2024/04/01 開始收費:

RDS Extended Support for PostgreSQL 11 starts on March 1, 2024, but will not be charged until April 1, 2024. Between March 1 and March 31, all PostgreSQL 11 instances on Aurora and RDS are covered under RDS Extended Support.

然後費用的部分也查的到了,是用 vCPU-hour 計算的,四條產品線的價位在 us-east-1 的計價是相同的,前面兩年是 $0.1/vCPU/hr,而第三年是 $0.2/vCPU/hr。

由於 RDS 的機器最少是 2 vCPU,所以一台機器至少要多付 $0.2/hr 的費用,這個費用基本上會比 RDS 費用還貴。

這邊給個比較的數字,同樣在 us-east-1 上,2 vCPU + 8GB RAM 的 db.t4g.large 要 $0.129/hr,而一樣 2 vCPU + 8GB RAM 如果是 db.m7g.large 則是 $0.168/hr,都還沒有 RDS Extended Support 貴;要到 r7g.large 這種以記憶體導向的 $0.1071/hr 才差不多跟上一樣的價錢。

另外一個方法應該就是改成自己在 EC2 上架設?這樣成本會因為 RDS 轉 EC2 的下降,整體大約會降到 1/4...

不過應該也會有公司就是用下去,在上面跑的好好而且很賺錢的東西就不想亂動...

聊了一下 Amazon S3 Express One Zone 的用途...

昨天寫了「AWS 推出 Amazon S3 Express One Zone」這篇,剛好跟朋友聊了一下 Amazon S3 Express One Zone 的用途...

首先 Amazon S3 Express One Zone 這個產品的定位會是有多台機器需要存取同一包資料:如果是同一台機器要存取的話,放到 Amazon EBS 甚至是 local disk 上就好了。

另外可以知道 Amazon S3 Express One Zone 主要的服務對象不會是靜態資料:靜態資料可以先把所有的資料打包成一大包,丟到標準的 Amazon S3 上面跑,讓每一台機器下載下來,這樣 latency 的影響也會小很多。

所以可以抓到產品的定位:會是有很多機器需要存取同一包資料,而且這包資料會不斷更新。

但畢竟 Amazon S3 Express One Zone 還是要走 HTTPS 去跟 server 要資料,如果你在本地端使用 EBS 或是 local disk,latency 一定還是比較低;而且就程式的開發來說,比較直覺的方法還是在本地端直接弄一個 ext4 filesystem,然後跑很多 process 處理。

(而且這樣還有使用記憶體做的 filesystem cache,加上 EBS 的儲存費用還比 Amazon S3 Express One Zone 便宜)

所以 Amazon S3 Express One Zone 的定位又再被縮小到一台 EC2 instance 沒辦法完成上一段提到的情境。

如果再把前幾天新推出的機器拿來看:「AWS 推出 32TB RAM 的機種 u7in-32tb.224xlarge」,這台新機器是 896 vCPU + 32TB RAM,代表你每跑 896 個 process (假設程式還沒用 threading 打散),而每個 process 可以吃 36GB RAM...

算過以後就會發現,這是個 scale up 可以暴力解很多問題的年代,只要你的演算法不是 n^2 這類的 case...

但回到這個產品的定位,從上面的推敲可以找出還是有對應的需求方,而且知道這是一個比較小眾的產品線,但遇到這種問題的人都會是大型客戶,這樣去思考為什麼會推出 Amazon S3 Express One Zone 就合理多了。

Amazon Q (來猜名字的由來...)

AWS 推出了 Amazon Q,目前還在 preview 階段:「Amazon Q brings generative AI-powered assistance to IT pros and developers (preview)」。

產品本身主要就是 LLM 的應用,以現在來說沒有太特別,主要是 Hacker News 上大家在猜這個 Q 到底是取自哪裡:「Amazon Q (Preview) (amazon.com)」。

看到有猜 Q (Star Trek)Q-learning 以及 Q (James Bond)

id=38448900 這邊有人提到 Q 是 question:

from the NYTimes article: The name Q is a play on the word “question,” given the chatbot’s conversational nature, Mr. Selipsky said. It is also a play on the character Q in the James Bond novels, who makes stealthy, helpful tools, and on a powerful “Star Trek” figure, he added.

找了一下應該是「Amazon Introduces Q, an A.I. Chatbot for Companies」這篇文章,因為 paywall 的關係可能看不到全文,可以看 archive.today 這邊的 archive:「Amazon Introduces Q, an A.I. Chatbot for Companies」。

反正牽扯的到的都提一下...