AWS 也把 Kafka 包出來當服務了...

AWS 發表把 Kafka 包起來當服務賣的 Amazon MSK:「Introducing Amazon Managed Streaming for Kafka (Amazon MSK) in Public Preview」。

另外 Kafka 所需的 ZooKeeper 部份已經被包進去了,不需要另外付費:

You do not pay for Apache Zookeeper nodes that Amazon MSK provisions for you, or data transfer that occurs between brokers and nodes within clusters.

目前看起來只提供 us-east-1 區域使用。

AWS Lambda 支援 Ruby 2.5 以及其他語言

AWS 宣佈 Lambda 支援 Ruby 2.5:「AWS Lambda Supports Ruby」。

另外宣佈可以透過 Layer 的方式讓任何程式語言在上面跑 (前面提到的 Ruby 看起來就是用這個方式支援的):「New for AWS Lambda – Use Any Programming Language and Share Common Components」。

The Runtime API is the future of how we’ll support new languages in Lambda. For example, this is how we built support for the Ruby language.

AWS 新推出的 Amazon Elastic Inference:GPU 出租方案

AWS 推出了 Amazon Elastic Inference,可以讓你選擇 GPU 的量掛進 EC2 instance:「Amazon Elastic Inference – GPU-Powered Deep Learning Inference Acceleration」。

第一眼看到的時候在想這不是之前出過了嗎... 後來搜尋發現應該是針對圖形運算與 machine learning 的應用拆開使用不同的硬體?

所以在前陣子 AWS 公告將 Amazon EC2 Elastic GPUs 改名為 Amazon Elastic Graphics:「Amazon EC2 Elastic GPUs is now Amazon Elastic Graphics」。

舊的 Amazon EC2 Elastic GPUs (Amazon Elastic Graphics) 應該是針對圖形應用設計,而新的 Amazon Elastic Inference 則是針對 machine learning 設計。

Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft,但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響,所以就找了方法讓兩者並存:「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS,可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料,如果裡面有看到想要使用 TLS 1.3 的訊息,就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑:

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼,將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑,就比較不用擔心本來的 stack 會有狀況了。

AWS 推出 TSDB 服務:Amazon Timestream

AWS 推出了 TSDB 服務 Amazon Timestream:「Announcing Amazon Timestream – Fast, Scalable, Fully Managed Time Series Database – Register for the Preview」。

雖然還在 preview 階段,但從 pricing 頁面可以看出目前只有 us-east-2 (也就是 US East (Ohio) 這區) 有提供服務,跟其他服務不太一樣...

費用的部份,寫入、讀取與儲存是分開收費的,比較特別的是有三種不同的媒體可以存 (不同價錢),分別是 Memory、SSD 以及 Magnetic。然後都不怎麼便宜... 如果只是想找一個 TSDB,而且已經有量的人 (目前還沒量的其實在 MySQL 內跑一跑就好了 XD),可能還是得考慮自己用 Cassandra (或是 ScyllaDB) 之類的架構?

另外一篇相關的是「Amazon Forecast – Time Series Forecasting Made Easy」,透過分析 time series data 進行預測的 Amazon Forecast,看起來也還沒跟 Amazon Timestream 整合?

在 MySQL 上遇到 Replication Lag 的解法

看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決:「MySQL High Availability: Stale Reads and How to Fix Them」,另外在留言也有人提到 Booking.com 的解法:「How Booking.com avoids and deals with replication lag」。

在業務成長到單台 MySQL server 不夠用的情況下,最簡單的擴充方式是架設 slave server,然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split),但因為 MySQL 的 replication 是非同步的,所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料,也就是 replication lag。

這就大概有幾種作法,一種是當發現 lag 時就回 master 讀,但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看,但這個方法就不保證讀的到東西,因為有可能所有的 slave 都 lag。

以前遇到的時候是拆情境,預設還是 R/W split,但敏感性的資料處理以及金流相關的資料就全部都走 master。

不過文章裡的解法更一般性,在寫入時多寫一份資料,然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...

同樣的想法,其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊,然後在 slave 等待這組 binlog 或 GTID 被執行。

看起來算是很不錯的解法,不知道各家 framework 對這些方式的支援度如何...