If you cloud end Covid-19 by sacrificing a JavaScript framework, which one would you choose and why Angular?

— @dabit3 2020.4.19

這裡是 WWW 第拾肆期，Wow Weihang Weekly 是一個毫無章法的個人週刊，出刊週期極不固定，從一週到五年都有可能。初期內容以軟體工程為主，等財富自由後會有更多雜食篇章。

Apple just killed Offline Web Apps while purporting to protect your privacy: why that’s A Bad Thing and why you should care

標題很聳動但無誤，Apple 決定幫 Safari 給所有 storage 加上一個**「七天沒進站就刪掉」**的限制，不負責任猜測是 app 營收不好。

Copyrighting all the melodies to avoid accidental infringement

All the Music LLC 是一間懷抱夢想的公司，他們將旋律視為有限的數學排列組合，而數學是既有事實，所以沒有著作權，然後再利用程式組合不同音高的音符，每秒產生三十萬不同旋律的 midi，放在 public domain，進而保障音樂創作者不會被來路不明的著作權蟑螂吿到死。

該專案認為，音樂是由旋律、節奏、合聲，音色的要素組合，但在節奏差距不大的情況下，聽起來會像同一個旋律，加上美國著作權有「實質相似性」的概念，所以目前窮舉 8 個音高 x 12 個音符組合的旋律即可涵蓋大部分的旋律（之後又加上更多小調，以涵蓋更多種類的音樂）。

這個專案我覺得非常有趣，而且是用 Rust 寫的！不過其實世界上音樂不是只有西方古典音樂的五線譜，印度、中國、日本還有大大小小的部落民族都有各種超越五線譜的音樂，這些著作權要怎麼保障？又要怎樣讓創作者盡情發揮？仍然有難度存在。

更多細節可以看專案的 FAQ，雖然載入超慢…

Why We Started Putting Unpopular Assets in Memory

Image from Cloudflare blog

乍聽之下，標題聳動駭人，依然推薦閱讀此文。抽絲剝繭，層層理出技術決策如何從觀察、實驗、可能問題、現實部署情況，到未來展望的脈絡，值得技術撰文者參考。稍加摘要（根本稱不上是摘要）：

背景

Cloudflare 的 Cache 放在 SSD，客製化的超強 SSD，但仍遭遇一些問題：

  • 問題一： SSD 的 IO 是造成 tail latency 的主因
  • 問題二： 物理 SSD 壞掉替換的維運成本很高（Cloudflare 在兩百座城市的資料中心的運費、人力替換成本）

觀察現況

熱點資源已有作業系統 page cache 將之放在 memory：

  • Linux LRU 等各種演算法早就針對熱點做讀取快取
  • page cache 也會做寫入緩衝（buffer write） 但 Cloudflare 作為 CDN 服務，更新資源次數極少，page cache 沒辦法幫助減少硬碟寫入

非熱點資源似乎可以放進 memory：

  • 動機一： 寫入過多導致 SSD 壽命驟減，寫入需要對 storage 晶片送 P/E operation ，這個 operation 會阻擋 read ops
  • 動機二： 很多資源都是一次性再也不會存取第二次
    • 假說： 減少硬碟寫入可加速硬碟讀取
    • 方法： 只 cache 第二次存取的資源
    • 結果： 減少硬碟寫入次數，P75 cache hit duration 也降低，因為不需要 evict 非熱點資源、cache hit ratio 和 retention 也提高了

如何實作

解法一： 紀錄存取次數，但不要快取

  • 用 bloom filter 等 memory-efficient 資料結構來儲存存取次數
  • 新問題：資源都會 miss 第二次才會被 cache，這對 CDN 供應商或客戶來說都無法接受。

解法二： 多一個 transient cache (in memory cache)。

  • 先將欲快取到 SSD 的資源放在 memory 中，如果存取它太多次，就 promote 到 SSD 中
  • 沒被 promote 的資源最後會被 evict

權衡

這聽起來很合理，全部放到 memory 中，但其實需要在 SSD 壽命、cache tail hit latency 和 memory 使用量之間權衡，而這次影響最大的就是 memory 使用量上升：

  • transient cache memory 究竟要多大： 影響 eviction、cache hit ratio
  • 和 page cache 競爭： page cache 抓熱門資源、但 transient cache 大多為非熱門，有排擠效應
  • 和 process memory 競爭： process 和 page cache 不一樣，對 memory 有剛性需求，而且 edge service 的升級需要 zero downtime，所以會同時有兩個版本的服務（藍綠佈署 🙃），如果記憶體不夠，就會讓 page cache 減少，反而增加 IO。

有段話透露出 Cloudflare 對於客戶太在乎 miss rate 的抱怨，認為只是在博取「眼球效能」😈

From a customer’s perspective, cache retention being too short is unacceptable because it leads to more misses, commensurate higher cost, and worse eyeball performance.

結果與展望

Cloudlfare 採取在新的機器上部署新的 transient cache，並只在部分 asset 使用，不斷尋找 memory size 的甜蜜點，最後結果為

  • 在 SSD 壽命、cache tail hit latency 和 memory 使用量三者間，Cloudflare 選擇前兩者
  • 減少 20%-25% SSD 寫入
  • CDN tail latency 在高峰期間也減少了 20%

而對未來可以做更好的部分則是：

  • 部署更多： 舊機器退役後，新世代機器（更多 memory 的機器）就會上去
  • 更智慧的 promotion 演算法： 現在僅透過資源觸擊數，未來可依據資源的 TTL 決定是否 promote；另一面向則是 demotion，雖然不會減少硬碟寫入，但可增加 cache hit ratio 和 cache retention
  • 用其他儲存裝置做 transient cache： 選擇 memory 是因為損耗花費低，HDD 同樣耐操，可以考慮混合 SSD、HDD、memory 在費用和效能取得平衡