AWS 推出 Memory/CPU 比到 16:1 的 x8g 系列主機

看到「Now available: Graviton4-powered memory-optimized Amazon EC2 X8g instances」這篇公告,本來想說 Amazon EC2 的記憶體主機不是有 r8g.* 嗎,對比了一下才發現記憶體比率更高...

在七月的時候 AWS 先推出了 r8g.* 的主機,Memory/CPU 比是 8:1,也就是 8GB RAM 配 1 vCPU:「AWS Graviton4-based Amazon EC2 R8g instances: best price performance in Amazon EC2」。

這次的 x8g.* 則是到 16:1,對於吃記憶體的應用來說更適合?

以美東 us-east-1 的價錢來看,r8g.medium 是 $0.0977/hr (約 $70.344/mo),而 r8g.medium 則是 $0.05891/hr (約 $42.4152/mo),價錢多了約 65.8%,對於很偏記憶體的應用,像是 Memcached 或是 Redis 來說應該還不錯。

另外我查了一下 Reserved Instance (RI) 的價錢,這台最深的折扣 (全預付 + 三年的 RI) 居然是三折 (70% off),就算是最淺的折扣 (月付 + 一年的 RI) 也有六二折 (38% off),換算後分別是 $21.194/mo 與 $43.95/mo。

對比 Vultr 的 16GB RAM 機器,最少也要 $80/mo?雖然這邊有 2 vCPU,而且還送一定的流量,但價差還是頗明顯的。

之前沒有發現這邊的差異,意外的 AWS 在這邊的價碼頗有競爭性啊,尤其是自己用的話,網頁應用搭配 CloudFront 的 always free 方案,Amazon EC2 到 CloudFront 不用錢,然後 CloudFront 到 internet 流量的部分有一大段不用錢:

1 TB of data transfer out to the internet per month
10,000,000 HTTP or HTTPS Requests per month
2,000,000 CloudFront Function invocations per month
2,000,000 CloudFront KeyValueStore reads per month

不過目前沒有太多區域有,但頗意外的是德國法蘭克福居然在第一波,而不是愛爾蘭:

X8g instances are available today in the US East (N. Virginia), US West (Oregon), and Europe (Frankfurt) AWS Regions in On Demand, Spot, Reserved Instance, Savings Plan, Dedicated Instance, and Dedicated Host form.

Scaleway 的 RISC-V 伺服器

看到「Scaleway launches RISC-V servers (scaleway.com)」這篇,Scaleway 推出了 RISC-V 的伺服器:「Elastic Metal RV1」。

先看對消費者比較有感覺的部分,未稅 €15.99/mo 大約是 US$17.34/mo,有 16GB RAM 這點算是蠻有競爭力的,目前常見的 VPS 大約是 1:5 左右 (1GB RAM 大約要 $4/mo),這邊直接接近到 1:1,光是這點在吃 memory 比較重的環境下就蠻吃香的。

另外從 Scaleway 的角度來看,有蠻多特別的特性,像是超省電與超高密度:

EM-RV1 servers are extremely energy-efficient, consuming between 0.96W and 1.9W per 1.8GHz core.

Incredibly dense, a 52U rack holds up to 672 EM-RV1s!

所以一台機器的 4 core 跑滿大約是 7.6W,看功耗與手機用的 ARM CPU 有點像,只是不知道 CPU 效能到底在哪個區間,等後續看看好了?

測 IPv4 NAT VPS,以及架設 HTTPS Proxy

因為 AWS 開始收 Public IPv4 address 費用的關係 (而且頗貴,參考「AWS 將開始收取 IPv4 的 Public IP 費用」),我把其中一台主機改成只有 IPv6 address 後遇到不少問題 (在「把 AWS 上的 EC2 instance 改成 IPv6-only」這邊)。

由於有 proxy 的需求,剛好找機會玩一下 IPv4 NAT VPS... 這種 VPS 最基本的大概就是會給一個 IPv4 address 上 non-standard port 當作 SSH port,讓你可以連進去管理;另外通常會給 port forwarding 的功能,而且是固定不能換的,讓你可以開一些 port 出來用。

我的用途是 IPv6 address 的 proxy,所以要找有給固定的 IPv6 address 的,另外希望跑在日本,這樣其他用途也比較方便。

過年期間翻了一下找到 NAT VPS,有 256MB 跑個 proxy 類的應用應該還 OK,實際上是 256MB RAM + 64MB swap 的 OpenVZ 類環境,kernel 有到 5.2.0 還算堪用,上面可以選 Ubuntu 22.04 安裝。

費用的部分 US$7/year 還行,網路上是有看到 128MB RAM 的 機器,但這樣連裝東西都綁手綁腳的,太容易 OOM。

(剛拿到機器的時候還試著裝 Percona Server for MySQL,結果就 OOM 跑不完 setup 的流程,看起來得自己改設定混過去,但只是想確認 256MB RAM + 64MB swap 可以弄到什麼程度,就反安裝了...)

在上面把想測的東西測試完後,實際的 proxy 設定比較簡單... 先設定一個只有 IPv6 address 的 domain 申請 Let's Encrypt 的 SSL certificate,然後掛給 Squid 用。

然後在 IPv6-only 的機器上用 curl -v --proxy https://username:password@proxy-jp.example.com:12345/ https://home.gslin.org/robots.txt 確認沒問題後就可以把服務都掛過去。

有些服務會吃環境變數 HTTP_PROXYHTTPS_PROXY,有些是在設定檔內設定,基本上都是照著文件設就可以了。

我遇到的 application & library 都可以吃 HTTPS Proxy 協定,就沒什麼大問題... 如果有遇到不行的,也可以考慮在 Squid 裡面直接放行特定的 IPv6 address。

雲端的流量費用

在「Cloud Egress Costs (getdeploying.com)」這邊看到的文章,原文在「Cloud Egress Costs」這邊,主要是整理了表格出來可以快速了解不同雲端的流量費用差異,裡面不是單純 VPS 比較,而是各類的服務都拿出來比,像是 storage 類的以及 CDN 類的都有放進來...

Backblaze 的頻寬費用算法頗有趣,每個月給資料量的三倍大小當作免費頻寬,沒記錯的話因為 Cloudflare 是 Backblaze 的 partner,兩邊的傳輸費用不計費,如果資料是可以公開的,可以透過這個方式接出來;如果真的得走一般的流量輸出,收費是 US$0.01/GB (所以換算後是 US$10/TB)。

三家常被擺在一起的 VPS (LinodeDigitalOceanVultr) 的頻寬也都是 US$10/TB。

以前沒注意到的是 OVH CloudScaleway 的頻寬費用居然是免費的?另外 Hetzner 雖然要收費但也很低?有機會好像該玩看看,看一下品質如何?

捷克政府宣布 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),這幾天再來看看怎麼弄...

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

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

Linode 宣佈漲價 20%

兩個禮拜前才宣佈改名:「Linode 改名叫 Akamai Connected Cloud」,現在就宣佈漲價了:「Akamai’s Cloud Computing Services: Pricing Update」。

這次最注目的是這個,VPS 的部份漲 20%,只有最低的機種維持 US$5/mo:

The price of Shared and Dedicated compute plans will increase by 20%. Our shared Nanode plan remains unchanged at US$5 per month.

降 bandwidth overage cost 只是擺在一起好看而已。

Hacker News 上翻一下,也有不少討論:「Linode increases price of compute plans and more (linode.com)」。

先不提 AWS 在後面撐著的 AWS Lightsail,這樣看起來 Vultr 愈來愈有競爭性了?

Linode 改名叫 Akamai Connected Cloud

Linode 改名叫做 Akamai Connected Cloud:「A Bold New Approach to the Cloud」、「Akamai Unveils Akamai Connected Cloud and New Cloud Computing Services」。

所以 Akamai 走的路線是整合品牌,這樣其實有很大的機會是會讓 Linode 本來的速度被大組織架構拖慢。

啊,反正現在已經沒在用 Linode 了,只能跟 HN 裡「Linode rebranded as Akamai’s cloud computing services (linode.com)」討論一樣,RIP Linode...

Vultr 開大阪機房

Vultr 宣布開大阪機房:「New Cloud Data Center Location: Osaka, Japan」。

本來的東京機房從 HiNet 過去會塞,可以看到每天都會有一段時間 latency 會飄起來:

從 HiNet 過去 Vultr 東京機房是走 PCCW 的線路:

從 Vultr 東京機房回來是走 NTT 的線路:

如果是 Vultr 大阪機房的話,先用 mtr 看了一下 latency,狀況似乎是好很多?好像可以考慮把東京的機器搬到大阪看看...

Vultr 更新流量計算方式

一時間沒找到在哪邊看到的,但的確是漏掉這個消息,早上看到去翻才注意到的... Vultr 在去年 11 月底宣佈更新流量的計算方式:「Vultr Announces Reduced Bandwidth Pricing, 2 TB of Free Monthly Egress, Free Ingress, and Global Pooling」。

這波費用的更新算是跟上另外兩家 (LinodeDigitalOcean) 的算法了,先前 Vultr 的算法就很古老 XD

第一個是 inbound traffic 不算錢了 (總算):

Data ingress will now be free.

再來是 traffic pool 的概念,現在每個帳號的流量會統一計算,而非每台機器自己計算:

All customers will receive global account-level pooling of transfer across all instances and locations.

然後是每個帳號都提供 2TB 的 free outbound traffic,這點有點放送的感覺:

Every Vultr customer will now receive two terabytes (2 TB) of free outbound data transfer every month, in addition to the transfer included with each subscription.

最後是超量的部份收費也簡化了,不管什麼地區都是 $0.01/GB:

Vultr will now offer a reduced, single worldwide egress overage rate of only $0.01 per GB.

最後這點有個值得操作的點:依照他的收費標準,超量 1TB 的流量需要付 $10 的費用,但你可以多租一台 $5/mo 的機器,這個方式提供了 1TB 的流量到 traffic pool 裡面。