回顧 Let's Encrypt 將在六月停止 cross-signed chain 的消息

因為收到 Cloudflare 的信,關於 Let's Encrypt 的 cross-signed chain 將在今年九月底過期的計畫,Cloudflare 這邊也有一些配合的措施會進行:

Let’s Encrypt announced that the cross-signed chain is set to expire on September 30th, 2024. As a result, Cloudflare will stop issuing certificates from the cross-signed CA chain on May 15th, 2024.

去年七月的時候 Let's Encrypt 拿的是去年五月底的資料說明 (2023/05/31),這邊會看 Android 7.1+ 的佔比,當時到了 93.9%。

會看 Android 7.1 是因為從這個版本開始預設就有內建 ISRG Root X1,而不需要 IdenTrust 的 cross-sign chain 了:

剛剛開了 Android Studio 來看,最近一次更新 Android 市占率的資料是去年十月初 (2023/10/01),到 95.0% 了:

也許到九月底的時候有 97%+ 甚至 98%+ coverage,但 Android 的基數還是太大,就算到 98%+ coverage,預期到時候的影響應該還是不小,會不會再簽一年...?

Java 21 的 ZGC 在 Netflix 的效果

Hacker News 上看到連結「Bending pause times to your will with Generational ZGC (netflixtechblog.com)」,發現這篇還沒整理:「Bending pause times to your will with Generational ZGC」,裡面講的東西都有圖有數字 (i.e. Y 軸),作者是 Danny Thomas

在這之前他們就已經知道 GC pause 是延遲的重要來源,會導致 timeout & retry:

In both our GRPC and DGS Framework services, GC pauses are a significant source of tail latencies.

That’s particularly true of our GRPC clients and servers, where request cancellations due to timeouts interact with reliability features such as retries, hedging and fallbacks.

第一張圖拉出來的資料是 error rate,白色是上個禮拜的資料,紫色是這個禮拜的資料,而從 G1GC 切到 ZGC 是在 2023/11/16 發生的:

可以看到很明顯的 error rate 改變:尖峰從 2k 下降到大約 0.3k,大約是原來的 1/6 到 1/7 的下降。

第二張圖是 GC 的時間:

可以看到 G1GC 還是偶而會撞到 2 秒,發生時平均值也都還是會 >100ms,切到 ZGC 後直接降到個位數 ms 等級了。

第三張圖是 memory overhead 的部分:

從圖上可以看到上週與本週的對比,導入 ZGC 後記憶體的使用量下降了,不過文裡面倒是沒解釋這點,反而提到 ZGC 比起 G1GC 有個固定的 3% overhead:

ZGC has a fixed overhead 3% of the heap size, requiring more native memory than G1. Except in a couple of cases, there’s been no need to lower the maximum heap size to allow for more headroom, and those were services with greater than average native memory needs.

第四張則是 Huge Pages 的差異,這邊要注意這張圖的 Y 軸不是從 0 計算:

可以看到在開 Huge Pages 後,在 RPS (request per second) 不變的情況下 CPU 使用率是有下降的,大約從 50% 降到 45% 左右,不過這張圖的時間跨度有點少,應該是要拉長一點的圖... 不過既然被提出來了,就假設 Netflix 內看起來應該是有這個趨勢,只是抓圖的時候懶了點?

整體算是大成功?

Cloudflare Zaraz 的新價錢

Cloudflare Zaraz 有點像是 GA4Mixpanel 或是 Amplitude 這種產品:

Cloudflare Zaraz is a solution that developers and marketers use to load third-party tools like Google Analytics 4, Facebook CAPI, TikTok, and others.

剛剛看到 Cloudflare Zaraz 的宣佈的新價錢:「Zaraz launches new pricing」,翻資料的時候發現去年七月的時候也有宣佈過價錢,但當時看起來反彈頗大而暫緩:「Cloudflare Zaraz steps up: general availability and new pricing」。

先看一下去年七月當時宣佈的價錢,這邊用了 Zaraz Loads 這個特別的 term:

If you exceed the free Zaraz Loads allocations, you'll be charged $0.50 for every additional 1,000 Zaraz Loads, but the service will continue to function.

看起來 Zaraz Load 包括了 script loading 以及 pageview event 都各算一次:

A Zaraz Load is counted each time a web page loads the Zaraz script within it, and/or the Pageview trigger is being activated.

這樣的話 1M event 就要 US$500,隔壁棚 Mixpanel 可以在「Pricing - Mixpanel | Product Analytics」這邊試拉,同樣 1M event 只要 $140,難怪當時被幹剿到不行...

這次公佈的價錢則是又用了新的 term,叫做 Zaraz Events,這個看起來就是一般理解的 event:

One of the biggest changes we made was changing the metric we used for pricing Zaraz. One Zaraz Event is an event you’re sending to Zaraz, whether that’s a pageview, a zaraz.track event, or similar.

而價錢直接下殺到 1M event 收 US$5,跟之前的差異巨大:

With the new Zaraz pricing model, every Cloudflare account gets 1,000,000 Zaraz Events per month for free. If your account needs more than that, every additional 1,000,000 Zaraz Events are only $5 USD, with volume discounting available for Enterprise accounts.

只是不知道 Zaraz 可以做到什麼程度,「理論上」會比較陽春,但不知道夠不夠用?

Scaleway 的 RISC-V 伺服器

看到「Scaleway launches RISC-V servers (scaleway.com)」這篇,Scaleway 推出了 RISC-V 的伺服器:「Elastic Metal RV1」。

先看對消費者比較有感覺的部分,未稅 €15.99/mo 大約是 US$17.34/mo,有 16GB RAM 這點算是蠻有競爭力的,目前常見的 VPS 大約是 1:5 左右 (1GB RAM 大約要 $4/mo),這邊直接接近到 1:1,光是這點在吃 memory 比較重的環境下就蠻吃香的。

另外從 Scaleway 的角度來看,有蠻多特別的特性,像是超省電與超高密度:

EM-RV1 servers are extremely energy-efficient, consuming between 0.96W and 1.9W per 1.8GHz core.

Incredibly dense, a 52U rack holds up to 672 EM-RV1s!

所以一台機器的 4 core 跑滿大約是 7.6W,看功耗與手機用的 ARM CPU 有點像,只是不知道 CPU 效能到底在哪個區間,等後續看看好了?

一個害我嗆到的故事... (Netlify 帳單的故事?)

故事本身其實還蠻普通的,只是我的閱讀順序害我嗆到...

首先是在 Hacker Newsbest 頁上看到「Netlify just sent me a $104k bill for a simple static site (reddit.com)」這篇,點進去以後是 Reddit 的「Netlify just sent me a $104K bill for a simple static site」這篇,看了一下作者的敘述,是個用 Netlify 的服務,上面有個 3.44MB 的音檔被針對攻擊,造成 190TB 的流量,以及 $104K 的帳單 (十萬多美金),之後 Netlify 的客服同意這是 DDoS 攻擊,給他 95% discount,也就是還是要付 $5K 左右...

Reddit 下面最高分的回應是:

[–]thankyoufatmember 2262 points 14 hours ago
Don't pay, post the story to Hackernews!

Okay,我想說我就是從 Hacker News 上看到點過來的... 回去看一下好了,結果在 Hacker News 的留言最上方是:

bobfunk 10 hours ago | next [–]

Netlify CEO here.

Our support team has reached out to the user from the thread to let them know they're not getting charged for this.

It's currently our policy to not shut down free sites during traffic spikes that doesn't match attack patterns, but instead forgiving any bills from legitimate mistakes after the fact.

Apologies that this didn't come through in the initial support reply.

然後我剛好在喝茶,就嗆到了...

人家常說 Ptt 的電蝦板 (PC_Shopping) 是全台灣最大的客服中心,遇到各種不公不義的問題貼上去就會解決了... 這點倒是頗像的。

CloudFront 端出 Embedded Points of Presence

看到 CloudFront 的產品新聞稿:「Amazon CloudFront announces availability of Embedded Points of Presence」,AWS 在 CloudFront 上端出了 Embedded Points of Presence 服務,看名字就是更彈性的 CDN PoP,不過想知道更細節的東西得去看 FAQs 的部分...

從這段可以看到應該是 AWS 的 appliance,然後放到實體機房裡面提供服務:

These embedded POPs are owned and operated by Amazon and deployed in the last mile of the ISP/MNO networks to avoid capacity bottlenecks in congested networks that connect end viewers to content sources, improving performance.

比較特別的消息是,這個不會額外收費:

Q. Is there a separate charge for using embedded POPs?
No, there is no additional charge for using CloudFront embedded POPs.

另外這個服務會是 opt-in 選擇加入,但不需要額外設定 distribution,而且 CloudFront 會針對有 opt-in 的 distribution 自動混搭:

Embedded POPs are an opt-in capability intended for the delivery of large scale cacheable traffic. Please contact your AWS sales representative to evaluate if embedded POPs are suitable for your workloads.

No, you do not need to create a new distribution specifically for embedded POPs. If your workload is eligible, CloudFront will enable embedded POPs for your existing distribution upon request.

You don't have to choose between CloudFront embedded POPs or CloudFront POPs for content delivery. Once your CloudFront distribution is enabled for embedded POPs, CloudFront's routing system dynamically utilizes both CloudFront POPs and embedded POPs to deliver content, ensuring optimal performance for end users.

下一章「Compliance」的部分有提到 embedded POPs 是不包括在 PCI DSSHIPAA 以及 SOC 這些 compliance 的,所以也可以回頭看到在提到推薦掛上來的內容,有避開掉敏感服務,主要是以大家都會看到一樣的內容的東西為主:

Embedded POPs are custom built to deliver large scale live-streaming events, video-on-demand (VOD), and game downloads.

看起來有點像是 NetflixOpen Connect 或是 GoogleGGC,讓 ISP 或是 MNO 可以放 cache service 降低對外消耗的流量。

這應該會回到老問題,ISP/MNO 當然是希望 CloudFront 花錢放機器進來,不會是 ISP/MNO 自己申請放,這不是技術問題而是商業問題...

Google Groups 脫離 Usenet 系統

先前在「Google Groups 將在 2024/02/22 斷開與 Usenet 的連接」這邊提到的,Google Groups 在 2024/02/22 會斷開與 Usenet 的 NNTP peering,日子到了...

在 Google Groups 上官方更新 banner 訊息了:

從我自己架的 News Server 上也可以從 innreport 中 incoming feed 的各個指標看到差異了:

可以再觀察幾個月看看後續的量,原先使用 Google Groups 的人會跑來 Usenet 上面嗎?或是 Usenet 就繼續萎縮下去...?

從 Backblaze 的年度報告裡看 HGST 的 4K 盤的問題

Backblaze 照慣例放出了年度報告,這次是 2023 年整年的回顧:「Backblaze Drive Stats for 2023」。

樣本數量少的跳過,這次比較特別的是可以發現 HGST 這邊 HUH721212ALN604 這顆樣本數破萬,而且 AFR 高到 3.69% 了:

他上面那顆 HUH721212ALE604 只差了一個字母 (N -> E),AFR 只有 0.95%,這個差距有點大。

拉了 datasheet 來確認:「Data Sheet: Ultrastar DC HC520 (He12)」,可以看到兩顆的規格幾乎一模一樣,唯一的差別是:

Format: Sector size (bytes)
4Kn: 4096
512e: 512

另外可以從「How to Read the Ultrastar Model Number」這邊看到 4Kn 與 512e 的說明:

E6 = 512e SATA 6Gb/s,
N6 = 4Kn SATA 6Gb/s

文章裡面沒有看到討論到這點,但好像很值得研究一下...?

測 IPv4 NAT VPS,以及架設 HTTPS Proxy

因為 AWS 開始收 Public IPv4 address 費用的關係 (而且頗貴,參考「AWS 將開始收取 IPv4 的 Public IP 費用」),我把其中一台主機改成只有 IPv6 address 後遇到不少問題 (在「把 AWS 上的 EC2 instance 改成 IPv6-only」這邊)。

由於有 proxy 的需求,剛好找機會玩一下 IPv4 NAT VPS... 這種 VPS 最基本的大概就是會給一個 IPv4 address 上 non-standard port 當作 SSH port,讓你可以連進去管理;另外通常會給 port forwarding 的功能,而且是固定不能換的,讓你可以開一些 port 出來用。

我的用途是 IPv6 address 的 proxy,所以要找有給固定的 IPv6 address 的,另外希望跑在日本,這樣其他用途也比較方便。

過年期間翻了一下找到 NAT VPS,有 256MB 跑個 proxy 類的應用應該還 OK,實際上是 256MB RAM + 64MB swap 的 OpenVZ 類環境,kernel 有到 5.2.0 還算堪用,上面可以選 Ubuntu 22.04 安裝。

費用的部分 US$7/year 還行,網路上是有看到 128MB RAM 的 機器,但這樣連裝東西都綁手綁腳的,太容易 OOM。

(剛拿到機器的時候還試著裝 Percona Server for MySQL,結果就 OOM 跑不完 setup 的流程,看起來得自己改設定混過去,但只是想確認 256MB RAM + 64MB swap 可以弄到什麼程度,就反安裝了...)

在上面把想測的東西測試完後,實際的 proxy 設定比較簡單... 先設定一個只有 IPv6 address 的 domain 申請 Let's Encrypt 的 SSL certificate,然後掛給 Squid 用。

然後在 IPv6-only 的機器上用 curl -v --proxy https://username:password@proxy-jp.example.com:12345/ https://home.gslin.org/robots.txt 確認沒問題後就可以把服務都掛過去。

有些服務會吃環境變數 HTTP_PROXYHTTPS_PROXY,有些是在設定檔內設定,基本上都是照著文件設就可以了。

我遇到的 application & library 都可以吃 HTTPS Proxy 協定,就沒什麼大問題... 如果有遇到不行的,也可以考慮在 Squid 裡面直接放行特定的 IPv6 address。