台灣看 Lbry/Odysee 的速度變快一些

Twitter 上看到 jkgtw 提到 Lbry/Odysee 的速度快很多:

看了一下資料,HiNetcdn.lbryplayer.xyz 的 latency 增加了,但是 packet loss 改善了不少,看起來是把本來導去新加坡的流量改導去美國:

另外走 APOL 的 cable 這邊也有類似的情況,可以看出導去美國了:

測了一下影片觀看速度,1.5x 可以看,2x 還是放不太動,的確是比以前好不少。

OVH 法國機房 SBG2 火災全毀

OVH 算是國際上很大的 Hosting 公司,昨天在法國史特拉斯堡 (Strasbourg) 的 SBG2 機房發生火災,這邊的 Octave Klaba 是 OVH 的創辦人與老闆,另外在 Hacker News 上的「Fire declared in OVH SBG2 datacentre building (ovh.net)」這邊也有討論可以看:

可以在 Threadreader 上面讀整個 thread,Octave Klaba 有一直有在 Twitter 上 update 進度與後續的計畫:「https://threadreaderapp.com/thread/1369478732247932929.html」。

新聞媒體也有一些當時的空拍圖放出來了:

出自「Strasbourg: important incendie chez OVHcloud, de nombreux sites internet indisponibles partout dans le monde」。

另外更重要的是伺服器裡面資料的部份,其中 SBG2 全毀,SBG1 毀了四間 (SBG1 總共 12 間),這些資料看起來都沒辦法救了。而 SBG3 與 SBG4 的機器還在,但目前沒有電力。

接下來的會花時間重建 SBG{1,3,4} 的電力系統與重建對外連線,看起來 20KV 的線路與 240V 的線路都有受損需要重弄。

然後也已經有廠商丟災情出來了,線上遊戲的 Rust 一開始說他們受到影響:

但更慘的是官方後續更新,直接說資料無法恢復,聽起來像是沒有備份資料,或是備份資料也在同一個機房內:

除了重建外,現在應該是等後續看起火原因,理論上機房的消防設備應該要能擋下全毀... 等原因出來後,來看看是不是會改變整個機房產業的消防設計架構。

DigitalOcean 送出 Form S-1

Hacker News Daily 上看到的消息,DigitalOcean 送出 Form S-1:「d898181ds1.htm」,在 Hacker News 上也有不少討論:「DigitalOcean S-1 (sec.gov)」。

這個消息跟 2020 年年初的裁員也可以交叉看一下:「DigitalOcean 裁員」,另外在 TechCrunch 上也有報導:「DigitalOcean’s IPO filing shows a two-class cloud market」。

Hacker News 上蠻多人在抱怨 DO 的產品,像是機器的效能,操作界面的穩定性,還有客服的反應... 不過這些跟 IPO 倒是沒什麼關係,重要的是每年的營業額有做出來:

Per its S-1 filing, DigitalOcean generated $203.1 million in 2018 revenue, $254.8 million in 2019 and $318.4 million in 2020. The company closed 2020 out with a self-calculated $357 million in annual run rate.

自己用的話應該還是偏好 VultrLinode...

Vultr 也推出 Kubernetes 服務 (Beta)

看到 Vultr 也打算要推出 Kubernetes 這個產品線了:「Announcing Vultr Kubernetes Engine!」。

這樣加上之前的 LinodeLinode Kubernetes Engine (LKE)DigitalOceanDigitalOcean Kubernetes (「DigitalOcean 也推出 Kubernetes 的服務」),比較知名的幾家 VPS 都推出 K8S 的產品線了。

對於不是 cloud provider 的 VPS provider 來說,直接拿 K8S 整合可以建了一組 mini-AWS 的架構出來,而且因為軟體還算紅,既有的 ecosystem 也可以直接拉進來,不需要另外重新學。不過因為 K8S 發展很快,還是可以常常看到各種踩雷抱怨文... XD

對於使用者來說,如果有一定的量與技術能力,加上想要省錢的話,用這些 VPS 提供的 K8S 服務看起來是個不錯的選擇。

應該找些時間更新之前自己摸索的那些東西了 (之前整理在「Kubernetes」這邊),理解底層會怎麼弄的對於在分析問題時還是蠻重要的 (i.e. 通靈),記得兩年前如果自己要弄 K8S master HA 還是 beta 功能...

AWS 推出 Amazon Elastic Container Registry Public (公開版的 ECR)

算是延伸產品線,把 Amazon ECR 變成可以公開使用:「Amazon Elastic Container Registry Public: A New Public Container Registry」。

這篇稍微有趣的地方是,文章裡面的上面這張圖有把 path 模糊化,但下面那張沒有遮,後面的文字也直接有提到 path (這是要給使用者玩的...):

ECR Public 會自動同步到兩個 region,但設定的頁面上好像沒寫會怎麼挑... 另外前面會放 CloudFront 加速。

ECR Public automatically replicates container images across two AWS Regions to reduce download times and improve availability. Therefore, using public images directly from ECR Public may simplify your build process if you were previously creating and managing local copies. ECR Public caches image layers in Amazon CloudFront, to improve pull performance for a global audience, especially for popular images.

費用的部份,意外的有提供一些免費的空間與頻寬可以用,算是在推廣嗎?

即使你不開營利,YouTube 也開始會顯示廣告了...

在「YouTube Will Now Show Ads On All Videos Even If Creators Don’t Want Them」這邊看到的消息,YouTube 現在會針對非營利的影片也開始放廣告了,而且不會分潤給創作者:

看到新聞當下馬上想到的是「NiceChord 好和弦」這個完全不開平台廣告的頻道,然後剛剛就看到他貼出來:(出自 https://www.facebook.com/nicechord/posts/2800689726883136 這邊,Facebook 的 embed 太麻煩了...)

他挑的是 LBRY 這個架構的平台,不過記得 LBRY 平台的頻寬部份需要自己打理,這點 lbry.tv 是有弄一組出來 (cdn.lbryplayer.xyz),但對於台灣這邊的連線品質就不太行... 不過這讓我想把 cdn.lbryplayer.xyz 放進 SmokePing 裡面監控看看。

不過就算自己要處理頻寬成本應該也還好,馬上想的到的方法是 Backblaze + Cloudflare 這種方式,不過我記得 Cloudflare 很明顯很不歡迎這種用法,量大的 YouTuber 切過去的瞬間大概就會被處理 XD

如果考慮自己付錢,像是 EGI Hosting 的美國頻寬對台港區還算堪用,Bare Metal Server Plans 這邊有看到 USD$60/month 提供 20TB/month 的頻寬,大約是 USD$0.003/GB。

更低的像是 OVH 的「Dedicated server prices - Discover our solutions | OVHcloud」,500Mbps 也差不多是 USD$60/month,只算 1/3 使用率的話大約是 50TB,成本會降到 USD$0.0012/GB

不過 LBRY 更大的問題是他還搞了 blockchain 出來,這滿滿 (逼~) 的味道,到底做不做的起來就不曉得了 XDDD

Amazon Lightsail 推出 Container 版本

看到 Amazon Lightsail 推出了 Container 版本的消息:「Announcing Amazon Lightsail Containers, an easy way to run containerized applications on the cloud」,另外在「Lightsail Containers: An Easy Way to Run your Containers in the Cloud」這邊也有介紹。

從官方 blog 上的圖可以看到機器規格與價位,比 Lightsail 貴一些:

另外有提到如果之後要轉到 Amazon ECS 或是 Amazon EKS 的話也都可以直接轉,不過我印象中 ELB 的部份還是要設一下,這點看起來 Lightsail 簡化了不少:

If you plan to later deploy your container to Amazon ECS or Amazon Elastic Kubernetes Service, no changes are required. You can pull the container image from your repository, just like you do with Amazon Lightsail.

不過後面實際上是用什麼架構跑啊?如果考慮到安全性的話應該是直接拿 t3.* 的主機直接 1:1 對應,只是包裝成吃 Docker,而不會共用主機?

Debian 資助 PeerTube 發展

看到「Debian donation for Peertube development」這則消息,Debian 決定資助 10K 歐元提供給 PeerTube 發展。

不過更大的幫助應該是 PR 上的部份,這帶出來的曝光度以及「認可」的部份比 10K 歐元重要的多。

回到 Debian 決定資助的原因,是因為 DebConf20 需要一個非封閉式平台的直播架構,而 PeerTube 看起來很適合這個情境:

This year's iteration of the Debian annual conference, DebConf20, had to be held online, and while being a resounding success, it made clear to the project our need to have a permanent live streaming infrastructure for small events held by local Debian groups. As such, Peertube, a FLOSS video hosting platform, seems to be the perfect solution for us.

前幾天在「有風聲說司法部會把 Chrome 拆出 Google」這邊有提到 YouTube 很難取代的問題,這個算是其中的一個方向,試著在解決平台壟斷的問題...

Google Fonts 的加速方式

這邊講的是透過 css (以及 js) 使用的 Google Fonts,作者想要改善這塊,加速網頁的速度:「Should you self-host Google Fonts?」。

作者第一個提到的技巧是個懶人技巧,只要加上 preconnect 預先把 HTTPS 連線建好,就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異:

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect,但從前後比較可以看出,整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的):

另外一個技巧是增加 swap,讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖,然後突然字都冒出來的情況,也就是把一般在用的:

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

加上 &display=swap

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

最後一招就是把字型放在自己家,差異就更大了:

另外一個好處是改善 privacy,不過好像沒特別提到...

DigitalOcean 裁員

上個禮拜的消息了,DigitalOcean 決定裁員:「DigitalOcean is laying off staff, sources say 30-50 affected」。

推出新產品與新服務的速度不算快,不知道是不是因為組織龐大造成的... 如果是的話,這次的裁員未必是壞事,以 TechCrunch 拿到的內部消息知道是 30~50 人,大約是全體的 10%。

另外一個問題是 DigitalOcean 提供的 CPU 一向都是三家裡面最慢的 (另外常被拿出來比較的兩家是 LinodeVultr),在大家都是一樣的服務下,這個缺點就蠻明顯的...