把 MySQL 的 binlog 功能再拆出來的 mysql-ripple

看到 Percona 的「MySQL Ripple: The First Impression of a MySQL Binlog Server」這篇提到了 Google 放出來的專案 mysql-ripple

這個軟體的情境是針對有很多 replica (slave) 時的情境,要解決每一個 replica 都會對 master server 產生壓力,算是 binlog 的 cache layer。

MySQL Ripple 抓了 binlog 下來後就可以模擬成 mysql server (但是只能提供 binlog 服務) 讓 replica 接,在 replica 很多的情境下就可以橫向擴充,而且因為軟體只支援 GTID 模式,所以比較好做 HA 架構 (相對於 filename + position 模式)。

大概可以歸納出是 write 很多 (所以 binlog 量很大),但又有大量 replica 需求的情境... 目前好像想不出來有什麼情境可以拿出來用 :o

從 StartPage 換回 DuckDuckGo...

把過程記錄下來而已...

前陣子在測試 StartPage (一個後端還是 Google 的搜尋引擎),想看看在沒有個人資訊的前提下是不是能提供夠好的搜尋品質。為了方便切換確認,還寫了 startpage-shortcuts 這個套件,讓我能用快速鍵將同樣的關鍵字傳進 Google。

用了幾個禮拜下來,發現搜尋品質其實很差,有時候甚至跳不出搜尋結果來?(可能是被 Google 擋下?) 先換回 DuckDuckGo 好了...

Algolia 從 Heroku 搬到 GKE 的故事

Algolia 是一個搜尋引擎服務,他可以幫你 index 資料後,你直接 query 他取得結果。

在這篇文章裡 Algolia 決定從 Heroku 搬到 GKE:「The Challenging Migration from Heroku to Google Kubernetes Engine」。

在文章只單純就產品與技術面上的需求在討論,像是一開始討論 IP 白名單的問題:

A good example of this complexity is with IP Whitelisting. One of our customers wanted us to crawl from a fixed IP address so that they could whitelist that IP for high-rate crawling without being throttled by their load balancer. Only two engineers were developing the crawler, so we asked other colleagues to set up an HTTP proxy with a fixed IP address. Yet, as the number of customers grew, many more started asking for the same thing, and our infrastructure team told us it was time for us to take care of it ourselves.

不過我更想知道搬過去後的各類成本差異... 省了多少平台費用,以及多少維護人力的差異,不過看起來沒提到 XD

Chrome 對各種 JavaScript 的優先順序

前陣子看到「JavaScript Loading Priorities in Chrome」這篇,在分析 Google Chrome 對各種 JavaScript 的優先順序。

優先順序分成讀取的「Loading priority (network/Blink)」與執行的「Execution priority」,另外文章裡也有整理建議「Where should this be used?」。

看起來 <script defer> at the end of <body> 是全部裡面最低的,建議是給 Load "Related articles" 或是 "Give feedback" 這類功能,不過應該沒什麼人真的這樣用...

然後要注意的是,這邊分析的對象是 Google Chrome,實際在設計時應該要先考慮一般性的定義,再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)

用環境辨識改善 Google Maps 的定位

Google 透過環境辨識的方式改善 Google Maps 使用 GPS 定位時的精確度問題 (另外也試著解決方位不準的問題):「Using Global Localization to Improve Navigation」。

GPS 因為是衛星訊號,會有反射訊號而導致定位漂移的問題,像是這樣:

另外也會有指北針不準的問題,Google 的解法是利用相機傳輸現在的畫面,判斷可能的地點,後面的資料庫應該就是街景圖:

這代表後面的系統已經有能力處力不同天氣的情境...

不過看了一下 YouTube 上的 keynote,是去年 Google I/O 上提到的事情了,最近出現文章應該是開始提供給一般人用?在 Facebook 上有看到一些人提到...

用在室外的隱私性應該還在可以被接受的範圍?不是很確定...

Cloudflare 發表 Logpush,把 log 傳出來

Cloudflare 推出了 Logpush,可以把 log 傳到 Amazon S3 或是 Google Cloud Storage 上 (目前就支援這兩個):「Logpush: the Easy Way to Get Your Logs to Your Cloud Storage」,目前是 enterprise 方案可以用:

Today, we’re excited to announce a new way to get your logs: Logpush, a tool for uploading your logs to your cloud storage provider, such as Amazon S3 or Google Cloud Storage. It’s now available in Early Access for Enterprise domains.

Logpush currently works with Amazon S3 and Google Cloud Storage, two of the most popular cloud storage providers.

以往是自己拉,需要考慮 HA 問題 (兩台小機器就可以了,機器成本是還好,但維護成本頗高),現在則是可以讓 Cloudflare 主動推上來...

我大多數的建議是 log 儘量留 (包括各種系統的 log 與 http access log)。主要是因為儲存成本一直下降 (S3 的 1TB 才 USD$23/month,如果使用 Glacier 會低到 USD$4/month),而且 log 在壓縮後會變小很多 (經常會有重複的字)。

最傳統的 AWStats 就可以看到不少資訊,如果是透過 IP address 與 User-agent,交叉配合其他 event data 就可以讓很多 machine learning 演算法取得的資訊更豐富。

JPMorgan Chase 的 WePay 用的 MySQL 架構

看到「Highly Available MySQL Clusters at WePay」這篇講 WePayMySQL 的設計,本來以為是 WeChat 的服務,仔細看查了之後發現原來是 JPMorgan Chase 的服務...

架構在 GCP 上面,本來的 MySQL 是使用 MHA + HAProxy (patch 過的版本,允許動態改變 pool),然後用 Routes 處理 HAProxy 的 failover。

他們遇到的問題是 crash failover 需要至少 30 分鐘的切換時間,另外就是在 GCP 上面跨區時會有的 network partition 問題...

後續架構變得更複雜,讓人懷疑真的有解決問題嗎 XDDD

改用 GitHub 推出的 Orchestrator 架構,然後用兩層 HAProxy 導流 (一層放在 client side,另外一層是原來架構裡面的 load balancer),在加上用 Consul 更新 HAProxy 的資訊?

思考為什麼會有這樣設計 (考慮到金融體系的背景),其實還蠻有趣的...

Google Hangouts 將會使用固定 IP 位置

Google 宣佈 Hangouts 將會使用固定 IP 位置,讓系統管理員更方便管理:「Dedicated Hangouts Meet IP addresses」。

We’re adding a range of official, fixed IP addresses to be used exclusively for classic Hangouts and Hangouts Meet in G Suite domains.

目前看到的資訊是:

IPv4: 74.125.250.0/24
IPv6: 2001:4860:4864:5::0/64

然後文章裡的說明是二月 14 日會變更:

Hangouts Meet and classic Hangouts will stop using the old IP address on February 14, 2019.

管理者可以調整關於這段 IP 的流量,通常是調高優先權?不過要調低也是可以...