Wasabi 與 Storj DCS

WasabiStorj 是在看到「Will Cloudflare R2 Win Customers from Amazon S3?」這篇文章時翻到了三個 Cloud Storage Provider,文章本身我倒是沒什麼吸收...。

第一個是 BackblazeB2,這個產品平常的曝光度就還算夠。

另外是 Wasabi 的部份,其中一個賣點是免費的頻寬,但其實限制意外的多。首先是各地區的價錢:

我找了一下到底是什麼地區,目前只有看到「Wasabi Technologies Inc Status」這邊有編號 (US-East-1、US-East-2、US-Central-1、US-West-1、EU-Central-1、AP-Northeast-1),但也沒找到地區... US 的都在美國沒問題,AP-Northeast-1 應該是日本,但 EU-Central-1 是哪裡就找不到了。

另外是 pay-as-you-go 的方案最小是 1TB,如果是歐美區的話是 US$5.99:

For customers using the Wasabi pay-as-you-go pricing model, Wasabi has a minimum monthly charge associated with 1 TB of active storage. If you store less than 1 TB of active storage in your account, you will still be charged for 1 TB of storage based on the pricing associated with the storage region you are using.

然後也有 90 天的最短計價時間:

Wasabi has a minimum storage duration policy that means if stored objects are deleted before they have been stored with Wasabi for a certain number of days (90 days when using the Wasabi pay-go pricing model), a Timed Deleted Storage charge equal to the storage charge for the remaining days will apply.

另外 Wasabi's free egress policy 這邊也可以看出來他們的設計就是拿來當 storage 用,然後前面需要擋 CDN 之類的服務。

最後一個是 Storj 的 DCS,US$4/TB/month 的空間費用,與 US$7/TB 的流量費用感覺還算便宜?他的做法是把檔案拆成 80 份,然後取 29 份就可以算回來:

How many Nodes are files stored on?

80. We split each file into 80 different encrypted pieces, and each piece is stored on a different Node.

When you retrieve an object, only 29 of its 80 pieces are needed to reconstitute that object. With no central point of failure, your data is always quickly available, all over the world.

這部份是則是透過 Reed-Solomon error correction 實做:

Automate file repair and know that Reed-Solomon erasure coding enables the highest levels of durability for all files uploaded to Storj DCS.

好一陣子沒看到 Reed-Solomon 了,沒想到在這邊看到... 先不管技術的部份,看起來 Storj DCS 的價錢可以玩看看。

Cloudflare 推出 Cloudflare R2 Storage,相容於 S3 API,但沒有傳輸費用

Cloudflare 宣佈了 Cloudflare R2 Storage,相容於 S3 API,但是沒有傳輸費用:「Announcing Cloudflare R2 Storage: Rapid and Reliable Object Storage, minus the egress fees」,Hacker News 上的「Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees (cloudflare.com)」可以看一下討論,裡面有負責 R2 的 PM (帳號是 greg-m) 回答一些東西。

R2 的第一個特點就是剛剛提到的傳輸費用:一般的雲端都是傳進去不用錢,但傳出來會很貴,而 R2 其中一個主打的點就是傳出來不用錢:

R2 builds on Cloudflare’s commitment to the Bandwidth Alliance, providing zero-cost egress for stored objects — no matter your request rate. Egress bandwidth is often the largest charge for developers utilizing object storage and is also the hardest charge to predict. Eliminating it is a huge win for open-access to data stored in the cloud.

另外 storage cost 也算低,S3 目前的費用是 US$0.023/GB/month (拿 us-east-1 相比),而 R2 目前的定價是 US$0.015/GB/month:

That doesn’t mean we are shifting bandwidth costs elsewhere. Cloudflare R2 will be priced at $0.015 per GB of data stored per month — significantly cheaper than major incumbent providers.

在 durability 的部份,與 S3 都是一年 11 個 9:

The core of what makes Object Storage great is reliability — we designed R2 for data durability and resilience at its core. R2 will provide 99.999999999% (eleven 9’s) of annual durability, which describes the likelihood of data loss.

目前還沒有公開,算是先對市場放話:

R2 is currently under development — you can sign up here to join the waitlist for access.

有幾個點還蠻有趣的,第一個是 Cloudflare 自己在推的 Bandwidth Alliance 裡有不少 VPS 跟 Cloudflare 之間的流量是不計頻寬費用的,所以等於是 VPS 到 R2 不計費,而 R2 到 VPS 也不計費,但要注意 VPS 自己也都有在推 object storage。

像是 Vultr 的 US$5 方案包括了 250GB 的空間與 1TB 的頻寬,扣掉頻寬的部份 (可以透過 Cloudflare 處理),相當於是 US$0.02/GB。

Linode 也類似,US$5 的方案包括了 250GB 的空間與 500GB 的頻寬,算出來也是 US$0.02/GB。

Backblaze 也有類似的產品 B2,US$0.005/GB/month 的儲存費用以及 $0.01/GB 的傳輸費用,但頻寬的部份也可以透過 Cloudflare 處理。

這個產品出來以後可以再看看如何,但看起來是蠻有趣的。對目前的雲端商應該還好 (因為資料進 R2 還是有費用),但對這些 VPS 來說應該是有蠻大的衝擊...

Cloudflare Images

Cloudflare Images 開放付費使用了:「Cloudflare Images Now Available to Everyone」。

檔案傳到 Cloudflare 上面,然後另外收處理費用:

You pay $5/month for every 100,000 stored images and $1 per 100,000 delivered images. There are no additional resizing, compute or egress costs.

檔案大小的限制是 10MB,所以 $5/month 的 storage 最多可以提供 1TB 的空間,$0.005/GB 算是很漂亮的數字,如果是小圖的話就會比較虧一些?看起來丟大圖會開心一點...

Cloudflare Images offers multiple ways to upload your images. We accept all the common file formats including JPEG, GIF and WEBP. Each image uploaded to Images can be up to 10 MB.

然後支援的檔案格式有常見的 GIFJPEGPNG 以及 WebP

When a client requests an image, Cloudflare Images will pick the optimal format between WebP, PNG, JPEG and GIF.

另外有計畫要支援 AVIF

We’re just getting started with Cloudflare Images. Here are some of the features we plan to support soon:

AVIF support for even smaller file sizes and faster load times.

沒提到 durability,不知道會有多少...

Amazon RDS 支援 ARM 架構的 t4g 與 x2g

這兩篇剛好一起看,Amazon RDS 支援了 ARM 架構的 t4gx2g:「Amazon RDS now supports X2g instances for MySQL, MariaDB, and PostgreSQL databases.」與「Amazon RDS now supports T4g instances for MySQL, MariaDB, and PostgreSQL databases.」。

目前主要是關注 t4g,因為目前量的關係反而是大量使用 t4g 類的機器,如果上面的 PostgreSQL 可以跑 t4g 的話,看起來只要沒有買 RI 的可以換過去,主要是比 t3 再省一些錢:以新加坡區的 PostgreSQL 來說,db.t4g.micro 目前是 $0.025/hr,而 db.t3.micro 則是 $0.028/hr,差不多是九折。

沒意外的話效能應該也會提昇一些,不過用 t 系列的機器本來就沒有太大的量在上面跑,這點應該是還好...

Amazon EC2 上的一些小常識

Twitter 上看到 Laravel News 轉發了「Mistakes I've Made in AWS」這篇,講 Amazon EC2 上面的一些小常識。

在 EC2 中,T 系列的機器 (目前主要是 t2/t3/t3a/t4g) 對於開發很好用,甚至對於量還不大的 production system 也很好用,加上 Unlimited 模式可以讓你在 CPU credit 用完時付錢繼續 burst。

文章裡面有討論到,使用 T 系列機器時,常常是不怎麼需要大量 CPU 資源的情境,這時候 AMD-based 的 t3a 通常都是個還不錯的選擇,大概會比 Intel-based 的 t3 省 10% 的費用。另外如果可以接受 ARM-based 的話,t4g 也是個選項,價錢會更便宜而且在很多應用下速度會更快。不過同事有遇到 Python 上面跑起來的行為跟 x86-64-based 的不同,這點就得自己琢磨了...

另外就是目前的 EBS 預設還是會使用 gp2,而在 gp3 出來後其實大多數的情況下應該可以換過去,主要就是便宜了 20%,加上固定的 3000 IOPS。

不過也是有些情境下是不應該換的,主要是 gp2 可以 burst 到 250MB/sec,但 gp3 只給了 125MB/sec。雖然 gp3 可以加價買 throughput,但加價的費用不低,這種需求改用 gp2 應該會比較划算。

不過這邊推薦比較技術的作法,可以掛兩個 gp3 (也可以更多) 跑 RAID0 (像是在 Linux 上可以透過 mdadm 操作),這樣 IOPS 與 throughput 都應該可以拉上來...

Docker Desktop 要開始對商用收費了,以及 Open Source 版本的設法

Hacker News Daily 上看到的,Docker Desktop 修改了他的授權條件,對於商用版本要開始收費了:「Docker Desktop no longer free for large companies: New 'Business' subscription is here」,養套殺的過程...

目前看到的條件是 250 人以下的公司,而且年營業額在 10m 美金以下的情況免費,另外個人、教育以及非商業的 open source 專案保持免費:

It remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.

如果不符合的話,第一種方法是花錢繼續用 Docker Desktop,看起來最少要買 Pro 等級的方案,費用是每個人 USD$60/year 或是 USD$7/month。

第二種方法是只安裝 command line 的部份,這個部份可以透過 MacPorts 或是 Homebrew 的方式安裝。

我自己是用 MacPorts 的方法裝,雖然有點麻煩,但因為是一次性的設定,應該還算堪用。

首先是去 VirtualBox 官網上面安裝軟體 (我是連「Oracle VM VirtualBox Extension Pack」都裝了),然後就可以用 MacPorts 裝三包:

sudo port install docker docker-compose docker-machine

接著可以建立要跑 Linux 的虛擬機,docker engine 會跑在裡面:

docker-machine create --driver virtualbox default

然後把虛擬機跑起來:

docker-machine start

可以設定讓虛擬機在整台機器重開機時自動把虛擬機跑起來,但這部份就自己在網路上找文章設定了,因為我用不到... (記憶體不夠,而且平常我也不會在本機上開發)

接著設定需要用到的環境變數:

eval "$(docker-machine env default)"

然後就可以跑 docker ps 之類的指令了,後續就如同以前常見的操作。這個設定環境變數的指令也可以考慮放到 ~/.bashrc 之類的地方讓他在開啟 terminal 時自動設定好。

Homebrew 的話應該也有類似的搞法,就請自己搜了...

MySQL 在不同種類 EBS 上的效能

Percona 的人寫了一篇關於 MySQL 跑在 AWS 上不同種類 EBS 的效能差異:「Performance of Various EBS Storage Types in AWS」,不過這篇的描述部份不是很專業,重點是直接看測試資料建立自己的理解。

他的方法是在 AWS 上建立了相同參數的 gp2gp3io1io2 空間,都是 1TB 與 3000 IOPS,但他提到這應該會一樣:

So, all the volumes are 1TB with 3000 iops, so in theory, they are the same.

但這在「Amazon EBS volume types」文件上其實都有提過了,先不管 durability 的部份,光是與效能有關的規格就不一樣了。

在 gp2 的部份直接有提到只有保證 99% 的時間可以達到宣稱的效能:

AWS designs gp2 volumes to deliver their provisioned performance 99% of the time.

而 gp3 則是只用行銷宣稱「consistent baseline rate」,連 99% 都不保證:

These volumes deliver a consistent baseline rate of 3,000 IOPS and 125 MiB/s, included with the price of storage.

io* 的部份則是保證 99.9%:

Provisioned IOPS SSD volumes use a consistent IOPS rate, which you specify when you create the volume, and Amazon EBS delivers the provisioned performance 99.9 percent of the time.

另外在測試中 gp2gp3 的 throughput 看起來也沒調整成一樣的數字。在 1TB 的 gp2 中會給 250MB/sec 的速度,1TB 的 gp3 則是給 125MB/sec,除非你有加買 throughput。

另外從這句也可以看出來他對 AWS 不熟:

The tests were only run in a single availability zone (eu-west-1a).

在「AZ IDs for your AWS resources」這邊有提過不同帳號之間,同樣代碼的 AZ 不一定是一樣的區域,需要看 AZ ID:

For example, the Availability Zone us-east-1a for your AWS account might not have the same location as us-east-1a for another AWS account.

To identify the location of your resources relative to your accounts, you must use the AZ ID, which is a unique and consistent identifier for an Availability Zone. For example, use1-az1 is an AZ ID for the us-east-1 Region and it is the same location in every AWS account.

在考慮到只有設定大小與 IOPS 的情況下,剩下的測試結果其實跟預期的差不多:io2 貴但是可以得到最好的效能,io1 的品質會差一些,gp3 在大多數的情況下其實很夠用,但要注意預設的 throughput 沒有 gp2 高。

Amazon EC2 推出 m6i 的機器

AWS 給了公告,在 Amazon EC2 上面推出了 m6iIntel-based 新機種:「New – Amazon EC2 M6i Instances Powered by the Latest-Generation Intel Xeon Scalable Processors」。

這好像是第一次看到 Intel-based 機種加上了 i 的 suffix...

這次比較大的兩個差異,與 m5 相比,多出了 m6i.32xlarge

A larger instance size (m6i.32xlarge) with 128 vCPUs and 512 GiB of memory that makes it easier and more cost-efficient to consolidate workloads and scale up applications.

另外看了一下 us-east-1 上的單價,看起來與 m5 系列的機器價錢一樣,但是效能提昇了 15% (然後很假掰的寫了 price/performance?):

Up to 15% improvement in compute price/performance.

單以數字看起來的話還是 m6g 系列會比較香?當然如果只有 x86-64 binary 的話看起來還是可以考慮換到 m6i 上跑...

Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能,畢竟是公司要用的,還是實際測一下數字,之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWSap-southeast-1 (Singapore) 的 EC2 測試,直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令,其他的是出自我自己 wiki 上的 Ubuntu 這頁),然後再重開機:

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s,另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上,這樣可以捲回去看每一秒的傳輸速度,就可以看出來變化了,不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline):

EC2 instance Baseline Burstable vCPU RAM Pricing (USD$)
c6g.medium 500Mbps 10Gbps 1 2GB 0.0392
c6g.large 750Mbps 5Gbps (claimed 10Gbps) 2 4GB 0.0784
c6g.xlarge 1.25Gbps 10Gbps 4 8GB 0.1568
t4g.small 125Mbps 5Gbps 2 2GB 0.0212
t4g.medium 255Mbps 5Gbps 2 4GB 0.0424
t4g.large 510Mbps 5Gbps 2 8GB 0.0848
t4g.xlarge 1Gbps 5Gbps 4 16GB 0.1696

這邊沒列出來的是 burstable 可以持續的時間,但這跟你機器吃的網路資源有關,我就決定只用 baseline 來做決策了,這樣可能會多花一點錢,但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead,所以就順便查了一下資料:

  • OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候):「OpenVPN performance」。
  • SSH 也有些 overhead,大約是 6% (把來回的封包都算進去):「What is the overhead of SSH compared to telnet?」。
  • rsync 的部份鐵定也有 overhead,但這邊就沒找到現成的文章有統計過了。
  • 另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的,會有 10% packet loss,改用預設的 CUBIC 會好很多,大約 1% 到 2% 左右。

綜合這些測試,我自己抓了 35% 的 overhead 來推估,最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量,大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠,有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多,應該是不需要降...

IPv4 的價錢

Hacker News 首頁上看到「IPv4 pricing (hetzner.com)」這篇,裡面的連結「IPv4 pricing」是 Hetzner 這個 hosting 通知 IPv4 將在八月漲價的資料...

可以看到「/24 IP subnet (254 usable IPs)」這組的價錢從「€ 215.13 / € 0 setup」漲到「€ 435.20 / € 4864.00 setup」,看起來是趁機漲了不少 setup fee 來綁使用者。

Hacker News 的討論裡面有提到 e-mail 的應用上還是得用 IPv4,至少 Microsoft 還是不愛 IPv6:

I remember while trying to figure out why Microsoft was blocking emails that IPv6 SMTP source addresses had a much higher risk of being blocked despite having done all the required stuff like PTR, SPF, DKIM. Microsoft's form to submit delisting an IP address does not even accept an IPv6 address: https://sender.office.com/

Stuff like this really hinders adoption.

hmmm,e-mail 的確是痛點 (尤其是 reputation 問題),但其他大多數的應用好像還好?