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 還可以看到這類文章還蠻有趣的...

AWS 的 T4g 系列機器增加服務區域

先前在「AWS 推出了 ARM 平台上 T 系列的機器」這邊提到 Amazon EC2 推出採用 ARM 系列的 t4g.*,當時亞洲區只有東京與孟買可以使用,現在在更多區域都推出上線了:「Announcing new Amazon EC2 T4g instances powered by AWS Graviton2 processors along with a T4g free trial in Asia Pacific (Sydney, Singapore), Europe (London), North Americas (Canada Central, San Francisco), and South Americas (Sao Paulo) regions」。

抓了一下新加坡的價錢:

t4g.nano 2 N/A 0.5 GiB EBS Only $0.0053 per Hour
t3.nano 2 Variable 0.5 GiB EBS Only $0.0066 per Hour
t3a.nano 2 Variable 0.5 GiB EBS Only $0.0059 per Hour

可以來測一些東西看看如何了...

從 EC2 的價格表上發現 AWS 多了好多區...

剛剛翻 Amazon EC2 的價格頁面,發現多了好多有趣的區域,多了不少 ISP-based 的區域,像是 VerizonKDDI 以及 SKT

翻了一下好像沒有講過,但都已經放上價格頁了,應該是晚點就會放消息?

EC2 API 支援 IPv6,以及 Lightsail 支援 IPv6...

看到 AWS 丟出了兩個有點「有趣」的消息:「Amazon EC2 API now supports Internet Protocol Version 6 (IPv6)」、「Amazon Lightsail now supports IPv6」。

先是 EC2 的 API 支援 IPv6 的消息,但也不是全部都支援了 (亞洲區只有印度有支援,新加坡、日本、南韓與香港都沒在上面):

Usage of Amazon EC2’s new dual-stack endpoints are available at no additional charge. The new endpoints are generally available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Mumbai) and South America (São Paulo).

不過畢竟也不是直接面向使用者的部份,不算太意外就是了... 但另外聽到 Lightsail 支援 IPv6 的消息就比較意外了:

Amazon Lightsail now supports Internet Protocol version 6 (IPv6) on Lightsail resources like instances, containers, load balancers and CDN. With this launch, Lightsail resources operate in dual-stack mode, accepting both IPv4 and IPv6 client connections. This helps unlock application scenarios where some end user clients are IPv6 only.

本來以為 EC2CloudFront 有的東西在 Lightsail 上都會有,原來 IPv6 是沒支援的啊,這功能補的好晚...

EC2 的 Monitoring 提供更多關於限流的資訊

AWS 對於 EC2 的網路推出了五個新的監控指標:「Amazon EC2 announces new network performance metrics for EC2 instances」。

看起來都是跟限流有關的指標,看起來是在壓榨機器極限時會用到:

The new metrics inform customers in real time of network traffic impacted when instance allowances for inbound and outbound bandwidth, packets-per-second (PPS), connections tracked and PPS to link-local services are exceeded.

需要有最新的 ENA driver 才會提供 (看了一下現有的機器沒出現這些值 XD):

These metrics are available today in all global commercial AWS regions on instances running the latest version of the Elastic Network Adapter (ENA) driver with support for Linux, Windows ENA driver support will be available soon with version 2.2.2.0.

不另外收費:

They can be accessed from within the instance at no extra cost using simple command line tools.

這個功能在所有 AWS 商業區以及 GovCloud (US) 都已經上線:

Instance Level Network Performance Metrics is available in all AWS Commercial and GovCloud (US) Regions, with the exception of China (Beijing) and China (Ningxia).

先記錄起來就好,一般用法應該都還好...

Amazon EC2 的新機種:R5b、D3 (D3en)、C6gn、M5zn、G4ad

Amazon EC2 除了昨天放出 Mac mini 消息打頭陣以外,其他機種的更新消息也陸陸續續公佈了:

比較有趣的 (對我而言),第一個是 ARM 架構的機器也推出 100Gbps 的 n 版本 c6gn,看起來很適合跑大流量的東西,馬上想到的就是自架的 memcached

另外是 m5zn,使用高頻率的 Intel Xeon,主打需要單核效率的程式,不過這是掛在 m 系列下,而不是 c 系列...

再來是使用 AMD GPU 的 g4ad,官方宣稱跟 NVIDIAg4dn 比起來,將會有 45% 的 C/P 值提昇,是個蘇媽跟老黃的對決:

However, when compared to G4dn the new G4ad instances enable up to 45% better price performance for graphics-intensive workloads, including the aforementioned game streaming, remote graphics workstations, and rendering scenarios. Compared to an equally-sized G4dn instance, G4ad instances offer up to 40% improvement in performance.

看起來 ARM 的消息沒有想像中的多...

AWS 推出了 ARM 平台上 T 系列的機器

前幾天發現在 AWS Web Console 上開 EC2 機器時,選 t3a 後本來可以選的「T2/T3 Unlimited」變成只叫「Unlimited」,心裡猜測有東西要推出,然後這幾天看到消息了...

這次 AWS 推出了 t4g 系列的機器,而這邊的 g 如同慣例,指的是 ARM 的 Graviton2:「New EC2 T4g Instances – Burstable Performance Powered by AWS Graviton2 – Try Them for Free」。

目前公司在用的 ap-southeast-1 沒有在支援的地區,只好去 us-east-1 上玩:

T4g instances are available today in US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Tokyo, Mumbai), Europe (Frankfurt, Ireland).

剛好這兩天把 SOP 文件的安裝方法改成 ansible playbook,就順便拿 t4g 的機器測了一下也沒什麼問題。

另外 T 系列機器最重要的 CPU credit 的部份,在官方文件「CPU credits and baseline utilization for burstable performance instances」這邊也已經可以看到 t4g 的相關資料了,基本上跟 t3t3a 是一樣的設計。

而價錢的部份,都以 T 系列裡最大的 2xlarge 來算,Intel 平台的 t3.2xlarge 是 $0.3328/hr,AMD 平台的 t3a.2xlarge 則是 $0.3008/hr,而 t4g.2xlarge 是 $0.2688/hr,大約是 80.7% 與 89.3% 的比率。

另外官方宣稱效能還比 x86 平台上好很多,這點可以打個折看,不過就價位來說是真的不錯:

Using T4g instances you can enjoy a performance benefit of up to 40% at a 20% lower cost in comparison to T3 instances, providing the best price/performance for a broader spectrum of workloads.

不過目前公司的主力還是在新加坡區,而且還有 RI 在跑,等有了 t4g 之後再把一些東西丟上去測看看,然後找時間換過去...

Colin Percival 希望 AWS 有 us-chaos-1 (us-fail-1?)

Daily Hacker News 上看到的東西,這個網站會每天會演算法整理出 Hacker News 上十則消息 (就如同名字),對於還不錯,這次有趣的是這個網站的作者 Colin Percival 自己在 Twitter 上講的東西也被收進去了...

他目前的主力服務應該是 Tarsnap,主打的是只有使用者有 key 能解開的雲端加密備份服務。這個服務放在 AWS 上,所以才會有這則:

希望有個三不五時就壞掉的環境,可以確保平常在設計架構上就會考慮到不穩定性。

這讓我想到 NetflixChaos Monkey,可能還是不夠用?

機器層應該可以用 Chaos Monkey 搞定,網路層應該可以在 PF 或是 iptables 上面模擬出來?雖然每台都得設定就是了... 目前沒有想到好方法的應該是 EBS 與 cloud service 的部份 (像是 RDS),也許前面架個很容易壞掉的 TCP proxy 模擬?

另外馬上就看到下面有幾個人在偷婊其他 cloud service XDDD

PHP 在 Amazon EC2 的 m5 (Intel) 與 m6g (ARM) 的效能差異

先前在「Amazon EC2 的 M6g 系列正式推出了」這邊提到了 AWSAmazon EC2 上推出了以 ARM 為架構的 m6g 系列機器,剛剛看到有人拿 PHP 上的應用丟出測試的差異了:「Improving performance of PHP for Arm64 and impact on Amazon EC2 M6g instances」。

最先要注意的應該是這張:

在 PHP 7.3 的時候 Intel 平台的 m5 跑比較快,但到了 PHP 7.4 就變成 ARM 的 m6g 跑比較快了,不過這兩個版本的差異都不算太大,而到了還在開發的 PHP 8 則是出現了比較大的差距。

作者有提到主要的原因是在 PHP 7.4 之前 ARM 上不會啟用 Zend optimizer,而這個功能對效能的影響差很多,在 PHP 7.4 打開後就反轉了:

Zend optimizer is a component of the PHP runtime system that improves performance by up to 30% on a range of Zend micro-benchmarks. Before PHP 7.4 the Zend optimizer was not enabled for Arm.

而 PHP 8 的差距拉大,則是因為 PHP 有更多針對 ARM 平台的改善,像是這邊提到的 NEON 指令集:

PHP-8 plans to release in 2021 with more improvements for Arm64: an improved toupper/tolower function brings performance up by 16.5x. https://github.com/php/php-src/pull/4439

除此之外,AWS 也對 PCRE2 提供了使用 NEON 指令集的加速的 patch:

AWS has contributed changes to PCRE2 release 10.34. PCRE2 version 10.34 is used in PHP-8 to match regular expressions. PCRE2 accounted for about 8% of execution time in WordPress benchmark. The change contributed by AWS to PCRE2 vectorizes first character match and matching pairs of characters with NEON instructions: performance improves by up to 8x on M6g.

這樣可以看到 ARM 平常應該會愈來愈成熟,而更重要的是 m6g 系列機器比 m5 便宜不少:以作者測試的 {m5,m6g}.4xlarge 來看,分別是 USD$0.768/hr 與 USD$0.616/hr,大約是 20% 的差距,加上效能上的差距,C/P 值看起來是真的有到官方宣稱的 40%,這點在其他 Plurk 也測出了類似的結果

未來除非是 binary-only 的東西,不然應該會朝著往 ARM 上面測過,再決定要怎麼選 instance type...

Amazon EC2 的 M6g 系列正式推出了

先前提到 AWS 要在 EC2 上推出新的 ARM 架構主機 (參考「Amazon EC2 推出了新一代的 ARM 系統」這篇),最近正式推出了:「New – EC2 M6g Instances, powered by AWS Graviton2」。

當時的定價還沒出來,現在正式開賣後可以拉出來看了。

us-east-1 上 2 vCPU + 8GB RAM 這個級距的價錢出來,m5.large 是 USD$0.096/hour,m6g.large 是 USD$0.077/hour,低大約 20%,不過這是兩個不同的平台,只是抓一下感覺知道差距。

不過這個價差其實蠻有吸引力的,對於有支援 ARM 的應用程式,或是手上有 source code 的大型應用,可以測試看看效能有差多少,或是先等一下,這陣子應該就會有人初步測一些數字出來可以參考。

另外 AWS 有打算要出 C6gR6g 的計畫,算是在雲上面補齊 ARM 的戰線:

We are not going to stop at general purposes M6g instances, compute optimized C6g instances and memory optimized R6g instances are coming soon, stay tuned.

目前支援的區域不算多,不過幾個老區域都先上了:

Now it’s your turn to give it a try in one the following AWS Regions : US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), and Asia Pacific (Tokyo).