搜尋影片的串流平台

Hacker News Daily 上看到「Show HN: API to query catalogs of 20 streaming services across 60 countries (movieofthenight.com)」這個,但這個服務反而不是重點,有許多人發現裡面錯誤率頗高,而且也沒有台灣的資料,反倒是裡面有人提到 JustWatch 這個服務看起來比較好用...

像是「Friends」(這邊用的是中國的翻譯片名) 可以看到在台灣是在 Netflix 上,美國的話則是在 HBO Max (串流) 與 Apple TV (購買) 上可以看到。不過查 MythBusters 在兩個平台上都沒看到資料...

但整體上來說 JustWatch 搜出來的品質還是好不少...

Uber 對 Golang GC 的調整

Hacker News 上看到「How We Saved 70K Cores Across 30 Mission-Critical Services (Large-Scale, Semi-Automated Go GC Tuning @Uber)」這篇,講 Uber 的人怎麼調整 GolangGC,在 Hacker News 上的討論「Large-scale, semi-automated Go GC tuning (uber.com)」也有些東西再講。

一開始的方法是動態一直調整 GOGC 的值:

Our initial approach was to have a ticker to run every second to monitor the heap metrics, and then adjust GOGC value accordingly.

但這個方法的 overhead 太重:

The disadvantage of this approach is that the overhead starts to become considerable, because in order to read heap metrics Go needs to do a STW (ReadMemStats) and it is somewhat inaccurate, because we can have more than one garbage collection per second.

後來的方法是利用 SetFinalizer 來做 (然後這段 code 不知道為什麼是用圖片...):

Luckily we were able to find a good alternative. Go has finalizers (SetFinalizer), which are functions that run when the object is going to be garbage collected. They are mainly useful for cleaning memory in C code or some other resources. We were able to employ a self-referencing finalizer that resets itself on every GC invocation. This allows us to reduce any CPU overhead.

不過 Hacker News 上有些人也很驚訝於 30 個 service 用掉 70K cores 這件事情,以 Uber 的服務來說算是比預想多不少數字,而且這只是跑 Golang,而且這次省下來的部份...

另外在 Hacker News 上也有人提到 Golang 有在思考 soft memory limit 的設計,也值得看一看:「runtime/debug: soft memory limit #48409」、「Proposal: Soft memory limit」。

用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊

整理資料的時候看到以前就看到的資訊,Akamai 有提供工具,可以看 DNS resolver 的資訊:「Introducing a New whoami Tool for DNS Resolver Information」。

這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的,這些對外雖然有一個 IP address 在服務,但後面是一整個 cluster,所以可以利用 Akamai 的這個工具來看分析。

像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個):

$ dig whoami.ds.akahelp.net txt @8.8.8.8

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "172.217.43.194"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.35.0/24/24"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "111.250.35.149"

1.1.1.1 會給假的 ECS 資訊:

$ dig whoami.ds.akahelp.net txt @1.1.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.0.0/24/24"

然後 168.95.1.1 則是連 ECS 都不給 XDDD

$ dig whoami.ds.akahelp.net txt @168.95.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2001:b000:180:8002:0:2:9:114"

之前在找 DNS 類問題的時候還算可以用的工具...

把 Blog 丟到 CloudFront 上

先前在「AWS 流量相關的 Free Tier 增加不少...」這邊有提到一般性的流量從 1GB/month per region 升到 100GB/month,另外 CloudFront 則是大幅增加,從 50GB/month (只有註冊完的前 12 個月) 提升到 1TB/month (不限制 12 個月),另外 CloudFront 到 EC2 中間的流量是不計費的。

剛剛花了點功夫把 blog 從 Cloudflare 搬到 CloudFront 上,另外先對預設的 /* 調整成 no cache,然後針對 /wp-content/* 另外加上 cache 處理,跑一陣子看看有沒有問題再說...

目前比較明顯的改善就是 latency,從 HiNet 連到免費版的 Cloudflare 會導去美國,用 CloudFront 的話就會是台灣了:

另外一方面,這樣國際頻寬的部份就會走進 AWS 的骨幹,比起透過 HiNet 自己連到美國的 PoP 上,理論上應該是會快一些...

Flickr 的八卦故事

Hacker News 上的討論「Whatever happened to Flickr? (techspot.com)」出現了不少相關的人,比原文章寫的東西更精彩一些...

可以看一下「1024core」這串,另外「simonw」這串也頗有趣的 (Simon Willison 之前也在 Yahoo! 待過),「petilon」這串也有不少討論... 但要記得這些都是八卦 XD

這幾年 Microsoft 在併購後的策略就軟多了,從 LinkedInGitHub 可以看出來...

用 Tailscale 取代個人的 VPN

Tailscale 是個基於 WireGuard 的 VPN 服務,基本的邏輯是所有的機器都連上 VPN,然後 Tailscale 建立一組 CGNAT 網段的內部網路讓你可以互連,另外也可以透過這些 VPN 設定 exit node 連外:

另外的一個特點是他把 Hole punching 的方式包好了,可以打通兩個都在 NAT 後面的機器 (大多數的狀態都可以成功),不需要透過 VPN hub 代轉流量,於是 latency 會低很多 (因為大多數在台灣都沒有 VPN hub)。

也因為不太需要 VPN hub,對 Tailscale 來說營運的成本就沒那麼高,所以 Tailscale 有提供個人可以用的免費版本,提供 20 個 devices 連上同一個內部網段。

以前在外面的咖啡廳用網路會習慣透過 VPN server 稍微保護一下連線,現在看起來可以用 Tailscale 取代掉... 家裡的 HiNet 桌機或是 VPS 的機器都可以拿來當 exit node。

另外還有 open source 的 headscale 專案可以看,如果想要完全更高的安全性,完全自己 host 的話...

AWS 印尼雅加達區開放使用

AWS 宣布印尼雅加達區開放使用,代碼 ap-southeast-3:「Now Open – AWS Asia Pacific (Jakarta) Region」。

要注意雅加達區需要另外 enable 才能用:

As is the case with all of the newer AWS Regions, you need to explicitly enable this one in order to be able to create and manage resources within it.

另外也同時宣布了雅加達的 AWS Direct Connect 接點:「AWS Direct Connect announces two new locations in Indonesia」。

公司主力目前用新加坡 (ap-southeast-1),好像有不少事情得做... (至少要先規劃)

AWS 的 us-west-1 與 us-west-2 炸掉

AWS 又炸了,不過這次不是死在 us-east-1,在 Hacker News 上的討論「AWS appears to be down again」可以看一看...

話說回來,前幾天在「前幾天 AWS 的 us-east-1 出事報告」才提到可以放到 us-west-2,怎麼就炸了...

手上的 SmokePing 也可以看到一些資訊,像是 HiNet 到 dynamodb.us-west-1.amazonaws.com:

HiNet 到 dynamodb.us-west-2.amazonaws.com 的:

第四台 (APOL 線路) 到 dynamodb.us-west-1.amazonaws.com 的:

第四台 (APOL 線路) 到 dynamodb.us-west-2.amazonaws.com 的:

可以看出來從網路層就了出問題,再等幾天看 AWS 出報告吧...

前幾天 AWS 的 us-east-1 出事報告

AWS 放出前幾天 us-east-1 出事的報告了:「Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region」,Hacker News 上的討論「Summary of the AWS Service Event in the Northern Virginia (US-East-1) Region (amazon.com)」也可以看一下,裡面也有人提到儘量閃開 us-east-1

而爆炸當天的討論「AWS us-east-1 outage (amazon.com)」也可以看一看,裡面還有聊到企業文化的問題...

AWS 的 us-east-1 除了是 AWS 最早的區域以外,也是目前 AWS 內功能最多的區域 (大多數新功能在第一波都會開放 us-east-1 使用),然後也是最便宜的區域,所以會有很多人都用這個區域提更服務。

也因為這樣,這個區域也是 AWS 內最大的區域,加上 AWS 是目前最大的公有雲,導致了這個區域的很多東西會遇到以前的人都沒遇過的問題,大概每年 (或是每兩年) 就會有一次比較嚴重的 outage,算是為了價錢而選擇 us-east-1 的人要注意的。

說到價錢,如果是為了找價錢比較低的區域,另外一個可以考慮選擇是 us-west-2,出新功能與新產品時也常常會被放進第一波,目前看起來的歷史記錄應該是比 us-east-1 好不少...

這次出問題的主要是內部控制用的網路 (被稱為 internal network) 擁塞,而非客戶在用的網路 (被稱為 main network):

To explain this event, we need to share a little about the internals of the AWS network. While the majority of AWS services and all customer applications run within the main AWS network, AWS makes use of an internal network to host foundational services including monitoring, internal DNS, authorization services, and parts of the EC2 control plane.

後面也有提到因為壅塞而導致 monitoring 系統受到影響,只能就手上的 log 去分析猜測,然後逐步排除問題,而 deployment 系統也使用內部網路,所以更新的速度也快不起來...

不過基本上可以預期明年或是後年應該還是會再來一波...

Alexa.com 宣佈將在 2022 年五月退役

Hacker News 上看到的消息,Alexa.com 將在 2022 年五月退役:「We will be retiring Alexa.com on May 1, 2022」,對應的討論在「We will be retiring Alexa.com (alexa.com)」這邊。

討論裡面有提到一些替代方案,大概只有 similarweb 堪用,另外也有提到「Tranco」這個:

A Research-Oriented Top Sites Ranking Hardened Against Manipulation

歷史啊...