SoundCloud 推出的錯誤蒐集工具 Periskop

SoundCloud 推出的錯誤蒐集工具 Periskop,應該是取自捷克文的 Periskop (潛望鏡):「Periskop: Exception Monitoring Service」。

Sentry 這類工具最大的差異在於是走 pull-based 架構,也就是跟 Prometheus 的設計相同 (Prometheus 也是 SoundCloud 發明的專案)。

就資源上來說,當 instance 上的錯誤滿天飛,而超過 log buffer 時,如果是以巨觀的角度來看,其實掉一些東西也沒關係:

另外也有提到一些缺點:

  • If a fatal exception occurs and the process dies, the exception won’t be collected. However, this can be mitigated by the reporting capabilities of orchestration services like Kubernetes or other forms of logging.
  • The pull model is not well suited for short-lived processes like scheduled jobs. This could be solved by the use of a push-based event gateway, although we haven’t yet had the need at SoundCloud, as it is usually more convenient to use logs to inspect failed jobs.

雖然 web (js) 與 mobile devices 的部份沒辦法被這個服務涵蓋,但一般來說會把面向使用者的服務另外拆開,所以不算是缺點... (像 Sentry 那樣通包,主要還是為了商業上的規劃)

目前看起來還缺一些東西 (就我想用的需求),可以先觀察一下會怎麼發展,另外一邊 Sentry 也在朝 Python 3 進行,也可以嘗試看看...

MVP.css

看到「MVP.css — Minimalist stylesheet for HTML elements」這個,目標是只需要寫 semantic html,剩下的就交給 css 處理:

No class names, no frameworks, just semantic HTML and you're done.

這種專案主要是看樣式喜不喜歡,畢竟選這種方案主要目的就是「懶」而不是要做太多效果,之後有機會來用看看...

AWS Global Accelerator 的 TCP 協定

AWS Global Accelerator 是讓使用者先連到最近的 AWS 節點,再透過 AWS 的骨幹網路連到服務上 (可以參考之前寫的「AWS 推出 Global Accelerator,用 AWS 的網路加速」這篇),當時就有說支援 TCP 與 UDP,但剛剛看到「AWS Global Accelerator launches TCP Termination at the Edge」這篇的時候才注意到,本來的產品是把 TCP 封包當作 UDP 在處理,也就是 TCP 3-way handshake 還是要到服務節點本身處理。

現在這個 TCP Termination 的功能則是先在最近的節點上建立 TCP 連線,然後同時往後端的建立連線接起來:

Typically, a TCP connection is established by using a three-way handshake (that is, three messages) between the client on the internet and the application endpoint in the AWS Region. So the farther away the client is from the endpoint, the longer the initial connection setup takes. With TCP termination at the edge, Global Accelerator reduces initial setup time by establishing a TCP connection between the client and the AWS edge location closest to the client. At nearly the same time, Global Accelerator creates a second TCP connection between the edge location and the application endpoint in the AWS Region. With this process, the client gets a faster response from the Global Accelerator edge location, and the connection from the edge location to the application endpoint in the Region is optimized to run over the AWS global network.

這樣連線的速度就會更快,但有可能會有前面建起來但後面建不起來的情況需要處理,一般的應用程式應該還好,畢竟地球上有個 GFW 也常幹這種事情...

Facebook 提供 Public NTP Service

在「Building a more accurate time service at Facebook scale」這邊 Facebook 講了不少跟 NTP 有關的東西,不過重點在他們提供 Public NTP service:

Having five independent geographically distributed endpoints helps us provide better service — even in the event of a network path failure. So we provide five endpoints:

  • time1.facebook.com
  • time2.facebook.com
  • time3.facebook.com
  • time4.facebook.com
  • time5.facebook.com

Each of these endpoints terminates in a different geographic location, which has a positive effect on both reliability and time precision.

看起來是混了 anycast 進去,從台灣 (HiNet) 走的話,time1.facebook.com 會到東京,time2.facebook.com 到大阪 (難得在 traceroute 上看到 ITM 這個代碼,代表 伊丹機場),time3.facebook.com 則是台灣,time4.facebook.com 到香港,time5.facebook.com 好像是馬來西亞?看 latency 與 maa 這個詞... (Update:應該是清奈國際機場)

可以考慮看看,另外 Google Public NTP 也是個選項。

Chrome 與 Chrome OS 最近不會更新新功能

這邊看到的消息,ChromeChrome OS 會避免在最近推出新功能,以維持軟體的穩定性,最近更新的主力會放在安全性上:「Google halts upcoming releases of Chrome and Chrome OS to keep things stable for everyone working from home」。

報導引用自 Twitter 上的宣佈:

呃,突然想到 Windows 的更新情況...

Pale Moon 呼籲不要使用 Google 主導的 WebComponents

Pale Moon 官方論壇的公告區「An Open Letter to Web Developers」這邊。

While, as a software developer ourselves, we understand very well that new features are exciting to use and integrate into your work, we ask that you please consider not adopting Google WebComponents in your designs.

話說回來,Pale Moon 用起來有種懷念感,而且比起現在的 Firefox 好用不少,只是上面套件有點少...

AWS Elemental MediaConvert 支援 AV1

在「2020/03/17 - AWS Elemental MediaConvert - 11 updated api methods」這邊看到的:

AWS Elemental MediaConvert SDK has added support for: AV1 encoding in File Group MP4, DASH and CMAF DASH outputs; PCM/WAV audio output in MPEG2-TS containers; and Opus audio in Webm inputs.

翻了一下同個站台的總表「AWS Elemental MediaConvert」這頁,看起來是第一次支援 AV1 輸出,這對於很在意頻寬的應用方便不少,另外翻了一下 Can I Use 這邊的資料「AV1 video format」,看起來也已經有不少環境可以用 AV1 了 (又看到 Safari,真不愧是 2020 年的 IE6):

另外可以參考「Netflix Now Streaming AV1 on Android」這篇,Netflix 在今年稍早的時候也決定在 Android 平台上採用 AV1。

AWS 上的 Redis 服務支援 Global Replication

AWS 上的 Redis 服務 (Amazon ElastiCache) 推出了 Global Datastore,也就是跨區同步的功能:「Now Available: Amazon ElastiCache Global Datastore for Redis」。

技術上會分成 read endpoint 與 write endpoint (在最後面的操作可以看到 $US_WEST_1_CLUSTER_READWRITE$US_WEST_2_CLUSTER_READONLY),所以算是蠻常見的 primary-secondary 架構。

不過我基本上不太愛 Redis,能用 Memcached 解決的偏好用 Memcached 解。不過如果把 Redis 當作是一種雲端服務的話,倒是還可以接受...

Brave 出手檢舉 Google 沒有遵守 GDPR

Brave (從 Chromium 分支出來的瀏覽器) 檢舉 Google 沒有遵守 GDPR 的規定:「Formal GDPR complaint against Google’s internal data free-for-all」。

主要是「purpose limitation」這個部份,出自「REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016」:

1. Personal data shall be:

(b)

collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

比較重要的是 specified 與 explicit 這兩個詞,GDPR 規定必須明確指明用途,而可以從整理出來的文件「Inside the black box」裡的「Purported processing purpose」看到大量的極為廣泛的說明。

Google 應該會就這塊反擊認為這樣的描述就夠用,就看歐盟決定要怎麼做了...

Kafka 拔掉 ZooKeeper 的計畫

目前 Kafka cluster 還是會需要透過 ZooKeeper 處理不少資料,但眾所皆知的,ZooKeeper 實在是不好維護,所以 Kafka 官方從好幾年前就一直在想辦法移除對 ZooKeeper 的相依性。

這篇算是其中一塊:「Kafka Needs No Keeper」。

真的自己架過 Kafka cluster 就會知道其中的 ZooKeeper 很不好維護,尤其是 Apache 官方版本的軟體與文件常常脫勾,設定起來就很痛苦。所以一般都會用 Confluent 出的包裝,裡面的 ZooKeeper 軟體與 Confluent 自己寫的文件至少都被測過,不太會遇到官方文件與軟體之間搭不上的問題。

另外一個常見的痛點是,因為 Kafka 推動拔掉 ZooKeeper 的計畫推很久了 (好幾年了),但進展不快,所以有時候會發現在 command line 下,有些指令會把 API endpoint 指到 ZooKeeper 伺服器上,但有些指令卻又指到 Kafka broker 上,這點一直在邏輯上困擾很久,直到看到官方的拔除計畫 (但又不快) 才理解為什麼這麼不一致...

給需要的人參考,當初在架設 Kafka cluster 時寫下來的筆記:「Confluent」。