GitHub 的 MySQL 架構與數字

前幾天 GitHub 有寫一篇文章提到他們的 MySQL 是怎麼 scale 的,另外裡面也有一些數字可以看:「Partitioning GitHub’s relational databases to handle scale」。

他們最主要的 database cluster 叫做 mysql1,裡面有提到 2019 年的時候這個 cluster 是 950K qps,其中 primary 有 50K qps:

In 2019, mysql1 answered 950,000 queries/s on average, 900,000 queries/s on replicas, and 50,000 queries/s on the primary.

在 2021 年的時候變成 1.125M qps,其中 75K qps 在 primary 上:

Today, in 2021, the same database tables are spread across several clusters. In two years, they saw continued growth, accelerating year-over-year. All hosts of these clusters combined answer 1,200,000 queries/s on average (1,125,000 queries/s on replicas, 75,000 queries/s on the primaries). At the same time, the average load on each host halved.

另外這幾年比較成熟的方案都拿出來用了,包括用 ProxySQL 降低連線數的壓力 (connection pool 的概念):

[W]e started using ProxySQL to reduce the number of connections opened against our primary MySQL instances.

ProxySQL is used for multiplexing client connections to MySQL primaries.

另外用 Vitess 協助 sharding 之間的轉移:

Vitess is a scaling layer on top of MySQL that helps with sharding needs. We use its vertical sharding feature to move sets of tables together in production without downtime.

這兩套應該是已經蠻成熟的了... 另外也可以發現老方法還是很好用,就算在 GitHub 這種量還是可以暴力解決很多事情。

DST Root CA X3 將在今天 22:01:15 過期

先前提到 Let's Encrypt 發出的憑證在 9/30 會產生問題,主因是 IdenTrustDST Root CA X3 會在 9/30 過期,交叉簽名加上 OpenSSL 1.0.2 的判斷條件太嚴格導致的:「OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題」。

本來以為是 UTC 的 2021/09/30 23:59:59 之類的時間,結果因為要面對這個問題,需要確認正確的時間,結果發現不是 UTC 的 2021/09/30 23:59:59,而是一個奇怪的時間:

Validity
    Not Before: Sep 30 21:12:19 2000 GMT
    Not After : Sep 30 14:01:15 2021 GMT

所以是 2021/09/30 22:01:15 (台灣時間) 會過期,今天晚上可以看一下情況...

NLB 接 ALB?

AWS API Changes 上看到這個修改:「2021/09/27 - Elastic Load Balancing - 3 updated api methods」。

說明是這樣:

Adds new ALB-type target group to facilitate forwarding traffic from NLB to ALB

所以是 NLB 可以接到 ALB 嗎,這看起來讓彈性變大不少...

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 來說應該是有蠻大的衝擊...

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式,早在前一個月前就先預錄好,但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到:「AWS實作紀錄 #2:高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看,或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault,但又不希望自己搞一堆 High Availability 的架構,最好是雲端服務本身就有提供... 而既然是在 AWS 的場子,主要都還是以 AWS 的服務來搭建。

在這次的設計裡,Vault 的資料是放在 DynamoDB 上,然後透過 KMS 管理加密用的,這兩個服務本身都有 High Availability,所以直接用就可以了。

接下來是跑 Vault 程式的部份,這部份得自己處理 High Availability 的架構,我是用兩台很小台的 EC2 instance (t4g.nano) 在跑,這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務:在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務,另外這邊即使是內部用,也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的,因為兩台機器之間是 active-standby 架構,同時間只會有一台機器在運作,而 lock 的機制是 Vault 透過 DynamoDB 實做的,不需要另外處理。

其實裡面大多數的元件都可以抽換,像是 DynamoDB 也可以用其他的服務來當儲存層,馬上可以想到的是 RDSMySQL 或是 PostgreSQL

概念上不算困難,所以投影片上主要就是給設定檔,這樣方便大家抄,不用在自己摸指令摸半天...

Imgur 被 MediaLab 併購

Hacker News 首頁上看到 ImgurMediaLab 併購的消息:「Imgur Acquired by Medialab (imgur.com)」,Imgur 的 PR 稿是在「Celebrating Imgur's Next Chapter」。

看了一下官方的聲明,沒有提到會維持免費或是要收費的事情,另外也沒有提到不會改變之類的事情,我猜應該是會改變商業模式... 之後有遇到再把本來在 blog 上的連結改成 self-hosting。

分析 Hacker News 上的討論所給出的書單

看到「HackerNews Readings」這個站,上面說他分析了 Hacker News 上的討論,然後給出書單:

40,000 HackerNews book recommendations identified using NLP and deep learning

點進去目前的預設 category (All Categories) 第一名是 Thinking, Fast and Slow (快思慢想),左邊有拉出 Amazon.com 上的評分,右邊可以看到對這本書的評論。

想要拉一些書來看可以從這邊翻翻看...

GitHub Actions 可以跑在自家機器上了

GitHub 宣佈可以在自家機器上跑 runner 了:「GitHub Actions: Ephemeral self-hosted runners & new webhooks for auto-scaling」,Hacker News 上的討論可以看看:「GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling (github.blog)」。

另外一個重要的功能是提供 webhook,讓你可以 auto scaling,我猜之後應該會有人寫一些工具讓你在雲端上跑:「Autoscaling with self-hosted runners」。

不過目前我自己大多數的東西都沒在 GitHub Actions 上跑...

在箱型車上安裝六個 Internet 服務 (Remote Work?)

看到「There are six internet links on my office on wheels. Seven when Starlink arrives. Is this the best internet in Australia?」這篇,作者在箱型車上接了六個 Internet 服務,在 Hacker News 上的討論可以翻一下:「There are six internet links on my office on wheels—seven when Starlink arrives (ghuntley.com)」。

作者畫的架構圖:

然後有車子外部的圖片:

另外在這張截圖可以看到其中四個 ISP:

然後作者提到了 Speedify 這個付費軟體 (月費),可以把多個 ISP 的頻寬綁起來,不過我想要看看自己怎麼在 Ubuntu 桌機上搞,畢竟我家裡也有兩條固網 (HiNet北都),能夠自動 failover 就算符合我的用途了...

Netflix 在單機服務 400Gbps 的影音流量

Hacker News 首頁上看到 NetflixEuroBSDCon 2021 上發表的投影片:「Serving Netflix Video at 400Gb/s on FreeBSD」,對應的討論則是在「Serving Netflix Video at 400Gb/s [pdf] (freebsd.org)」這邊可以翻到,投影片的作者有在上面回答一些問題。

投影片在講的應該就是 Netflix 的 Open Connect

主要是因為 Open Connect 的伺服器是放到各家 ISP 機房,在單一 IP 且單一伺服器的限制下,要想辦法壓榨出最高的效能。

硬體是 AMDEPYC,在先前的版本可以達到 240Gbps,經過分析與嘗試解決了一堆問題後,最後是在原來的 AMD 機器上跑到了 380Gbps (另外有測 ARM 以及 Intel 的數字),然後之後機房有可能會有 800Gbps 的標準,他們又要繼續煩惱...

有看到 Mellanox ConnectX-6 Dx (CX6-DX) 這個東西,看起來很有趣啊,有 200Gbps 的能力,而且可以把 TLS 的事情推到卡上面處理... 然後這家公司被 Nvidia 買走了。

另外當然也會有人問為什麼不用 Linux,作者在討論串裡面也有回答一些,有興趣的可以自己去搜一下。