Trino Gateway

先前一直有在追蹤 TrinoHA 方案:「High Availability #391」,昨天看到有人更新消息,提到 Trino Gateway 這個專案,以及九月底的時候的公告:「Trino Gateway has arrived」。

主要是從 Presto Gateway 整理出來的:

The release is the result of many, many months of effort to move the legacy Presto Gateway to Trino, start a refactor of the project, and add numerous new features.

原始的 Presto Gateway 專案上面也已經標示後續請大家去看 Trino Gateway:

NOTE: This is a legacy version of Trino Gateway. Please refer to https://github.com/trinodb/trino-gateway for active development and updates moving forward.

然後 Release notes 這邊可以看到前幾天又出一個新版了,看起來是有能量在專案上的。

從「Design」這頁可以看到軟體本身分成 BaseApp、ProxyServer 與 Gateway 三個部分,架構面上可以看得出來是 Proxy 架構。

從「References」這頁可以看到一些組織使用前身 Presto Gateway 的心得:

目前應該會需要一些時間,把積在 backlog 的功能開發出來。之後如果還有遇到 Trino 的話可以拿出來重新研究發展到什麼地方...

Percona XtraDB Cluster (PXC) 的感想

看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇,裡面提到了 Percona 包的 Galera Cluster,叫 Percona XtraDB Cluster

Percona 算是把 Galera Cluster 包的比較好的 distribution,是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本,叫做 MariaDB Galera Cluster

這篇算是很早期使用 PXC 的人的一些感想:(大概是 2012 年導入,當年雲端也還沒流行,在地端上面自己建,對應的 MySQL 底層還是 5.5 的年代)

Percona XtraDB Cluster 建議至少三台

Galera Cluster 的三台可以是兩台有資料的,加上一台沒有資料,這台沒資料的只負責投票組成 quorum,不需要到三台都是大機器,而且這樣的配置也比較單純一點。

另外兩台雖然都可以當 writer 寫入,但實務上會建議都集中在一台寫,這樣可以大幅降低跨機器時產生的 lock contention。

基於上面這個因素,將兩台有資料的機器,一台做 writer,另外一台做 reader 算是常見的架構,然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構,或是後來政治改名為 source-replica 架構),不要直接參與 Galera Cluster 協定。

(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題,現在有 GUID 後會好一些)

除了 Galera Cluster 外,另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD:因為 DRBD 可以在兩台機器的 block 層做 mirror,所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。

DRBD 的老方法架構很單純,維護成本也很低,但缺點就是 recovery 的時間會高一些:在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID),而 Galera Cluster 因為等於是 hot-standby,蠻容易就可以做到小於 30 秒。

另外在切換後 warmup 的時間上,Galera Cluster 也是因為 hot-standby 大勝:DRBD 這邊的情境等於是 cold start,資料庫內還有很多東西還沒進到 InnoDB buffer,對應的 SQL query 還不會快。

相比起來 Galera Cluster 看起來是個好東西,但後面運作的機制複雜不少 (而且需要有人維護),公司如果有專門的 DBOps 會比較好...

不過現在 SSD 變成主流的情況,讀取速度與 random access 的效率都快很多,這使得 DRBD 切換的成本低很多了,很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定,如果這個時間是可以接受的,用 Galera Cluster 的優點可能就沒那麼高了...

Amazon SQS 提高 FIFO throughput 限制

在「Amazon SQS announces increased throughput quota for FIFO High Throughput mode」這邊看到 AWS 提高了 Amazon SQS 中 FIFO throughput 的限制,這本來是個常常有的公告,但讓我意外的是不同區域拉高的數量是不同的:

Amazon Simple Queue Service (SQS) announces an increased quota for a high throughput mode for FIFO queues, allowing you to process up to 9,000 transactions per second, per API action in US East (Ohio), US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt) regions. For Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) regions, the throughput quota has been increased to 4,500 transactions per second, per API action. For all other regions where SQS is generally available today, the quota for high throughput mode quota has been increased to 2,400 transactions per second.

第一梯隊的 (像是 us-east-1us-west-2eu-west-1) 都是 9000 tps,而第二梯隊是 4500 tps,沒列在上面的區域是 2400 tps。

另外一個比較特別的是 Frankfurt 區居然在第一梯隊...

Amazon EC2 的 Trn1 正式開放使用

AWS 自家研發晶片的 trn1.* 上線了:「Amazon EC2 Trn1 Instances for High-Performance Model Training are Now Available」。

先前三家雲端的廠商只有 Google Cloud PlatformTPU 可以 train & evaluate,現在 AWS 推出 AWS Trainium,補上 train 這塊的產品。其中官方宣稱可以比 GPU 架構少 50% 的計算成本:

Trainium-based EC2 Trn1 instances solve this challenge by delivering faster time-to-train while offering up to 50% cost-to-train savings over comparable GPU-based instances.

然後 PyTorchTensorFlow 都有支援:

The Neuron plugin natively integrates with popular ML frameworks, such as PyTorch and TensorFlow.

另外用 neuron-ls 可以看到 Neuron 裝置的資訊,不過沒看懂為什麼要 mask 掉 private ip 的資訊:

大型的 cluster 會使用 Amazon FSx for Lustre 整合提供服務:

For large-scale model training, Trn1 instances integrate with Amazon FSx for Lustre high-performance storage and are deployed in EC2 UltraClusters. EC2 UltraClusters are hyperscale clusters interconnected with a non-blocking petabit-scale network.

但第一波開放的區域有點少,只有萬年美東一區 us-east-1 與美西二區 us-west-2

You can launch Trn1 instances today in the AWS US East (N. Virginia) and US West (Oregon) Regions as On-Demand, Reserved, and Spot Instances or as part of a Savings Plan.

us-east-1trn1.2xlarge 的價錢是 US$1.34375/hr,但沒有實際跑過比較好像沒辦法評估到底行不行...

但總算是擺出個產品對打看看,畢竟要夠大才能去訂製這些東西。

AWS 東京區有 12TB 記憶體的機器了

月初 AWS 宣佈東京區有 u-12tb1.112xlarge 可以用了:「Amazon EC2 High Memory instances with 3, 6, 9, and 12TiB of memory are now available in Asia Pacific (Tokyo) region」。查了一下 on-demend 的價錢是 $131.733/hr,如果一個月以 720 小時來算,要 $94847.76/mo...

沒記錯的話,這種機器應該是要另外申請 limit 才能開,沒辦法說測就測。另外在公告裡面有提到 savings plan ,但沒提到 RI (reserved instance),不確定是不是還沒開 RI 讓使用者買 (不過我記得 savings plan 好像也有類似的折扣結構):

Starting today, Amazon EC2 High Memory instances with 3TiB (u-3tb1.56xlarge), 6TiB (u-6tb1.56xlarge, u-6tb1.112xlarge), 9TiB (u-9tb1.112xlarge), and 12TiB of memory (u-12tb1.112xlarge) are available in Asia Pacific (Tokyo) region. Customers can start using these new High Memory instances with On Demand and Savings Plan purchase options.

這種機器是用暴力解決問題的機器...

EC2 的大記憶體機器又推新規格了...

這次 Amazon EC2 的機器又推出一些新規格了:「Amazon EC2 High Memory Instances now available for on-demand usage」。

然後每次推這些機器的時候都會提到 SAP HANA,都沒有其他的例子可以說... 話說業界就只剩下這套系統是完全都沒在考慮分散式架構嗎 XDDD (完全沒用過)

SAP customers continue to leverage AWS as their platform of choice and innovation. Some are in the early stages of their SAP cloud journeys and are focused on executing their migration. Others have hardened their SAP systems on AWS and are innovating around their core business processes with advanced AWS services.

另外他有提到 24TB 的機器,在 Amazon EC2 Instance Types 這邊可以翻到 u-24tb1.metal

In 2018, we released High Memory Instances in response, which now offer up to 24TB of memory in a single instance.

不過你會發現在 Amazon EC2 On-Demand Pricing 這邊翻不到 24TB 的價錢,先前在「EC2 推出 18TB 與 24TB 的機器...」這邊有過這些機器買三年 RI 才能用,所以這次推出來 12TB 的機器算是隨時租用的機器裡面記憶體最多的了...

u-12tb1.112xlargeus-east-1 的價錢是 USD$109.2/hour,想要玩的人可以測試看看,至少應該玩的動 XD

Google 新推出的 Lyra audio codec

Hacker News Daily 上看到「Lyra audio codec enables high-quality voice calls at 3 kbps bitrate」,講 Google 新推出的 Lyra audio codec:「Lyra: A New Very Low-Bitrate Codec for Speech Compression」,論文在「Generative Speech Coding with Predictive Variance Regularization」這邊可以抓到。

目前 Google 提出來的想法是想辦法在 56kbps 的頻寬下實現還堪用的視訊通話:

Pairing Lyra with new video compression technologies, like AV1, will allow video chats to take place, even for users connecting to the internet via a 56kbps dial-in modem.

這次的突破在於可以使用 3kbps 的頻寬傳輸,但清晰度比 Opus 的 6kbps 效果還好不少。

Google 在文章裡面給了兩個 sample,一個是乾淨背景音,另外一個是吵雜的背景音,跟 Opus 與 Speex 比起來都好很多。

論文是說不需要太高的運算力,但沒翻到 GitHub 之類的 source code,先當作參考:

We provide extensive subjective performance evaluations that show that our system based on generative modeling provides state-of-the-art coding performance at 3 kb/s for real-world speech signals at reasonable computational complexity.

Eventbrite 的 MySQL 升級計畫

在 2021 年看到 EventbiteMySQL 升級計畫:「MySQL High Availability at Eventbrite」。

看起來是 2019 年年初的時候 MySQL 5.1 出問題,後續決定安排升級,在 2019 年年中把系統升級到 MySQL 5.7 (Percona Server 版本):

Our first major hurdle was to get current with our version of MySQL. In July, 2019 we completed the MySQL 5.1 to MySQL 5.7 (v5.7.19-17-log Percona Server to be precise) upgrade across all MySQL instances.

然後看起來是直接在 EC2 上跑,不過這邊提到的空間問題就不太確定了,是真的把 EBS 的空間上限用完嗎?比較常使用的 gp2gp3 上限都是 16TB,不確定是不是真的用到接近爆掉了:

Not only was support for MySQL 5.1 at End-of-Life (more than 5 years ago) but our MySQL 5.1 instances on EC2/AWS had limited storage and we were scheduled to run out of space at the end of July. Our backs were up against the wall and we had to deliver!

另外在升級到 5.7 的時候,順便把本來是 INT 的 primary key 都換成 BIGINT

As part of the cut-over to MySQL 5.7, we also took the opportunity to bake in a number of improvements. We converted all primary key columns from INT to BIGINT to prevent hitting MAX value.

然後系統因為舊版的 Django 沒辦法配合 MySQL 5.7,得升級到 Django 1.6 (要注意 Django 1 系列的最新版是 1.11,看起來光是升級到 1.6 勉強會動就升不上去了?):

In parallel with the MySQL 5.7 upgrade we also Upgraded Django to 1.6 due a behavioral change in MySQL 5.7 related to how transactions/commits were handled for SELECT statements. This behavior change was resulting in errors with older version of Python/Django running on MySQL 5.7

然後採用了 GitHub 家研發的 gh-ost 當作改變 schema 的工具:

In December 2019, the Eventbrite DBRE successfully implemented a table ALTER via gh-ost on one of our larger MySQL tables.

看起來主要的原因是有遇到 pt-online-schema-change 的限制 (在「GitHub 發展出來的 ALTER TABLE 方式」這邊有提到):

Eventbrite had traditionally used pt-online-schema-change (pt-osc) to ALTER MySQL tables in production. pt-osc uses MySQL triggers to move data from the original to the “duplicate” table which is a very expensive operation and can cause replication lag. Matter of fact, it had directly resulted in several outages in H1 of 2019 due to replication lag or breakage.

另外一個引入的技術是 Orchestrator,看起來是先跟 HAProxy 搭配,不過他們打算要再換到 ProxySQL

Next on the list was implementing improvements to MySQL high availability and automatic failover using Orchestrator. In February of 2020 we implemented a new HAProxy layer in front of all DB clusters and we released Orchestrator to production!

Orchestrator can successfully detect the primary failure and promote a new primary. The goal was to implement Orchestrator with HAProxy first and then eventually move to Orchestrator with ProxySQL.

然後最後題到了 Square 研發的 Shift,把 gh-ost 包裝起來變成有個 web UI 可以操作:

2021 還可以看到這類文章還蠻有趣的...

EBS io1 推出可以同時掛到多台的選項

EBS 的 io1 推出了可以同時掛到 16 台 EC2 instance 的選項:「New – Multi-Attach for Provisioned IOPS (io1) Amazon EBS Volumes」。

先看支援的區域,傳統主力區域 (us-east-1 與 eu-west-1) 都支援了,而亞洲區這邊反倒是南韓先支援了:

Multi-Attach for Provisioned IOPS (io1) volumes on Amazon Elastic Block Store (EBS) is available today at no extra charge to customers in the US East (N. Virginia & Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Seoul) regions.

其中常用的目的是 HA:

Multi-Attach capability makes it easier to achieve higher availability for applications that provide write ordering to maintain storage consistency.

Heartbeat 類的應用應該可以用上這個東西,不過本來就可以透過 command line API 做到 detach & attach,用這個只是少了一個動作...

第二個想到的是,在實體機房的環境下,有些 filesystem (在「Shared-disk file systems」裡面可以翻到一些) 可以同時掛同一個 block storage (通常是透過 SAN),現在在 AWS 上面也可以這樣搞了。

不過 io1 記得不便宜啊...

Amazon RDS 推出了 Connection Pool 的產品

Amazon RDS 推出了 Connection Pool 的產品,叫做 Amazon RDS Proxy:「Introducing Amazon RDS Proxy (Preview)」。

目前支援 MySQL (包括了傳統的與 Aurora 版本的):

Amazon RDS Proxy supports Amazon RDS for MySQL and Amazon Aurora with MySQL compatibility, with support for additional RDS database engines coming soon.

定價策略看起來是依照後端資料庫的 vCPU 計算:

Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.

翻了一下價錢頁是 USD$0.015/vCPU (用 us-east-1 的資料),而如果是 t2 系列的機器,最低是以 2 vCPUs 計算,不是照使用比例算:

RDS Proxy pricing correlates to the number of vCPUs of the database instance for which it is enabled, with a minimum charge for 2 vCPUs.

這樣一個 vCPU 一個月大約要 USD$21.6,算起來頗貴的... 如果 SLA 允許的話,用基本的方式 failover 也許就 ok 了...

如果 SLA 真的要追求到這麼高的話,可以在這些區域測試:

Amazon RDS Proxy is available in preview for RDS MySQL and Aurora MySQL in US East (N. Virginia), US East (Ohio), US West (Oregon), EU West (Ireland), and Asia Pacific (Tokyo) regions. Support for RDS PostgreSQL and Aurora PostgreSQL is coming soon.