Brendan Gregg 加入 Intel

先前有提到 Brendan Gregg 離開了 Netflix 的事情:「Brendan Gregg 離開 Netflix」,剛剛看到他發表他去 Intel 的消息:「Brendan@Intel.com」。

看起來是任何跟 performance 有關的都可以碰,但主力會放在跟 cloud 相關的產品線上:

I'm thrilled to be joining Intel to work on the performance of everything, apps to metal, with a focus on cloud computing.

不知道起頭會碰什麼東西,也許先花幾個月熟悉?

Brendan Gregg 離開 Netflix

Brendan Gregg 宣佈離開 Netflix:「Netflix End of Series 1」,Hacker News 上他也有跳出來回答一些問題:「Netflix End of Series 1 (brendangregg.com)」。

看到有些問題還蠻有趣的,像是被問到桌子的大小:

Off topic: I’m a bit surprised about Gregg’s desk (pre-pandemic). I imagine he’s getting a top level salary at Netflix but yet he’s got a small desk in what it looks to me a shared small office (or perhaps is that a mini open space office? Can’t tell).

大概是在文章裡面有圖,所以被問:

他的回答:

A number of times people have asked about my desk over the years, and I'm curious as to why! I've visited other tech companies in the bay area, and the desks I see (including for 7-figure salary engineers) are the same as everyone else, in open office layouts. At Netflix it's been open office desks, and all engineers have the same desk.

Does some companies give bigger desks for certain staff, or offices, or is it a country thing (Europe?).

目前還沒有提到下一份工作是什麼:

I'll still be posting here in my next job. More on that soon...

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,作者在討論串裡面也有回答一些,有興趣的可以自己去搜一下。

Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

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

Cloudflare 也推出自己的 Speed Test 服務

Cloudflare 推出了自己的 Speed Test 服務:「Test your home network performance」。

這個服務跟 Netflix 推出的 fast.com 類似,測試的是使用者端到 Netflix (或是 Cloudflare) 中間的速度,主要的目的還是公關 (PR),所以看看就好,實際上用 Speedtest 測出來會比較有參考價值,而且可以選擇不同的點測試...

不過這讓我想到之前有人測出來遠傳會對偵測使用者要使用 Speedtest 測試時開放速限的情況 (像是「遠傳吃到飽只有 Speedtest 沒限速」這篇),然後就有各種定時去打 Speedtest 觸發開放速限的方法...

目前好像只剩下這篇活著,內文提到的是 Android 上的方法,另外推文有人提到 iOS 下的方法:「[心得] 在Android破解遠X限速」,如果有遇到的可以用看看...

Netflix 找到的 TCP 實做安全性問題...

這幾天的 Linux 主機都有收到 kernel 的更新,起因於 Netflix 發現並與社群一起修正了一系列 LinuxFreeBSD 上 TCP 實做 MSSSACK 的安全性問題:「https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md」。

其中最嚴重的應該是 CVE-2019-11477 這組,可以導致 Linux kernel panic,影響範圍從 2.6.29 開始的所有 kernel 版本。能夠升級的主機可以直接修正,無法升級的主機可以參考提出來的兩個 workaround:

Workaround #1: Block connections with a low MSS using one of the supplied filters. (The values in the filters are examples. You can apply a higher or lower limit, as appropriate for your environment.) Note that these filters may break legitimate connections which rely on a low MSS. Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).

Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to 0).

第一個 workaround 是擋掉 MSS 過小的封包,但不保證就不會 kernel panic (文章裡面用語是 mitigation)。

第二個 workaround 是直接關掉 SACK,這組 workaround 在有 packet loss 的情況下效能會掉的比較明顯,但看起來可以避免直接 kernel panic...

Netflix 的 FrameScope,將效能資料轉成 2D 圖片

Netflix 丟出了 FlameScope,另外一種顯示效能的工具,將效能資料轉成 2D 圖片:「Netflix FlameScope」。

We’re excited to release FlameScope: a new performance visualization tool for analyzing variance, perturbations, single-threaded execution, application startup, and other time-based issues.

然後這個工具同樣是發明火焰圖的 Brendan Gregg 與他的同事 Martin Spier 的作品:

FlameScope was developed by Martin Spier and Brendan Gregg, Netflix cloud performance engineering team. Blog post by Brendan Gregg.

火焰圖 (flame graph) 就是這個:

這次推出的是這樣的圖:

其實是每秒切一次 offset 做出來的圖:

就可以很簡單的看出來哪些區塊以及 pattern 是熱點:

Netflix 在 Time Series Data Storage 上的努力...

在「Scaling Time Series Data Storage — Part I」這篇看到 Netflix 在 Time Series Data Storage 上所做的努力...

因為應用在寫多讀少的場景,所以選擇使用 Cassandra,遇到瓶頸後把常寫入的與不太會改變的拆開儲存,並且用不同方式最佳化。包括了 cache 與 compression 都拿出來用了...

不知道他們內部有沒有評估 ScyllaDB 的想法...

Netflix 在 EC2 上調整的參數

Brendan GreggNetflixEC2 上調整的參數整理了出來:「AWS re:Invent 2017: How Netflix Tunes EC2」。

這些參數在 2017 的 AWS re:Invent 時有講到,他整理出來讓大家更方便參考:

My last talk for 2017 was at AWS re:Invent, on "How Netflix Tunes EC2 Instances for Performance," an updated version of my 2014 talk.

裡面有提到這是針對 Ubuntu 16.04 的調整 (而且是在 2017 年的版本,應該是 16.04.3?),用之前請理解每個參數:

WARNING: These tunables were developed in late 2017, for Ubuntu Xenial instances on EC2.