AT&T 網路的問題

Hacker News Daily 上看到個有趣的 troubleshooting 過程,AT&T 的線路會造成 random bit flipping 的問題,另外在 Hacker News 上的討論野蠻熱鬧的:「AT&T Fiber in the SF Bay Area is flipping bits (twitter.com/catfish_man)」。

有人生了一個 script 出來測試,這隻 script 會抓 www.example.com 的 HTTP 與 HTTPS 結果比較,從下面大家的留言回報,可以看出來有 random bit flipping 的問題:「bmastenbrook/example-test.sh」。

然後總算是解決了:

可惜看不到 AT&T 的回應,大家只能猜測是 memory 相關的問題,也許壞的部份有多個地方,造成 ECC 機制在某些情況下不夠用...

CentOS 將會變成 CentOS Stream

讓不少團隊要炸的消息,CentOS 將會被消滅變成 CentOS Stream:「CentOS Project shifts focus to CentOS Stream」與「CentOS Stream: Building an innovative future for enterprise Linux」。

很多團隊用 CentOS 的主要原因就是因為他基本上就是個 RHEL 重新打包的版本,一來更新速度沒有很快 (所以穩定不少,跑得好好的就不要動他最穩...),二來很多商用軟體都可以在支援 RHEL 時「順便」支援 CentOS。

再來是考慮到他有超級長的支援期,像是 2011 年推出的 CentOS 6 到上個月月底 (2020/11/30) 才終止支援,相較於 Ubuntu LTS 提供的五年來說長很多。

所以兩邊都有選擇的理由 (以及族群),一邊是追求穩定性,一邊是有新技術的需求。

不過 IBM 在 2018 年收購 Red Hat 後看起來對這件事情有很不一樣的看法:決定要收掉 CentOS,然後借屍還魂叫做 CentOS Stream,上面開始會有與 RHEL 不同的東西。

When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases.

所以接下來還有支援的兩個版本,分別是 2014 年出的 CentOS 7,將照原訂的 10 年計畫支援到 2024/06/30,以及 2019 年出的 CentOS 8,就只會支援到 2021/12/31 了。

翻了一下 Hacker News 上的討論,先不講幹聲一片的問題,看起來原來建立 CentOS 的 Gregory Kurtzer 決定出來再幹一次:「Original CentOS founder intends to create new fork of RHEL (rockylinux.org)」。

來看看後續社群會怎麼玩吧...

Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

Load Impact 的 k6 網站壓測軟體

這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式,結合了 Golang 的執行效率與 JavaScript 的操作語法,讓使用者可以很簡單的進行壓力測試,在 Hacker News 上也有蠻正向的反應:「K6: Like unit testing, for performance (github.com/loadimpact)」,我唯一會在意的應該是 AGPLv3 的部份...

先看了一下資訊,看起來「Load Impact」是公司名稱,「LoadImpact」則是產品名稱,然後現在要改名變成「k6」與「k6 Cloud」:

Load Impact is now k6

Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!

k6 裡面設計了 VU (Virtual User) 的概念,如同字面上的意義,VU 是虛擬的使用者,就技術上來說,每個 VU 都是在獨立的 JavaScript runtime 裡跑:

Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.

然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了,所以就不需要一堆 callback & promise 架構,用起來就爽很多:

For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.

翻了一下 Hacker News 上的討論與程式碼,看起來 JavaScript runtime 這部份是用 Golang 寫的 goja

文件裡面給了不少範例,像是在「Running k6」這邊有直接給出怎麼壓測,10 個 VU 跑 30 秒:

k6 run --vus 10 --duration 30s script.js

另外在 repository 裡面,「samples」這個目錄下有不少範例,可以直接先看過一次從裡面學到不少功能,之後再回去翻一次 manual,應該就會更熟悉...

隨便測了一下還蠻容易上手的,加上有 apt repository 可以直接納入系統管理,看起來應該會放著跑,之後找機會用看看,也許打 API 之類的...

gp3 (Amazon EBS) 的 latency

昨天把手上所有的 Amazon EBSgp2 換到 gp3 了:「Amazon EBS 的 gp3 可以用在開機磁碟了」,今天早上來看一下狀態,整體看起來是還 OK,不過有些地方值得注意的,像是標題寫到的 latency。

我抓了跑 GitLab 的機器來看,可以很明顯看到讀寫的 latency 都變高了:

AWS 又有提到這些數字資料有經過轉換,看起來是 gp2gp3 的數字意義本來就不一樣,所以他必須想辦法轉換,所以也有可能是因為這個轉換導致的?

This graph has had transformations applied to it and will differ from what is natively found in CloudWatch. Due to this some functionality is reduced.

不過其他的數字倒是沒什麼變化,系統的負荷量其實也還好,就先丟著跑...

Amazon EBS 的 gp3 可以用在開機磁碟了

可以先參考「Amazon EBS 推出了 gp3」這篇,但剛出來的時候大家都有發現無論是透過 web console 還是透過 awscli,boot disk 都沒辦法改成 gp3,可是在官方的文件上又說可以用 gp3,所以就有人在 AWS 的 forum 上發問了:「EBS GP3 Boot Volume Issues」。

直到剛剛發現已經可以改成 gp3 了... 一個一個手動改當然也是 OK,但對於有一卡車 EBS 要換的人來說鐵定得弄指令來換,這邊搭配了 jq 一起改:

aws ec2 describe-volumes | jq '.Volumes[] | select(.VolumeType == "gp2") | .VolumeId' | xargs -n1 -P4 env aws ec2 modify-volume --volume-type gp3 --volume-id

這邊是把 gp2 都改成 gp3,沒有考慮到空間大小的問題 (因為超過 1TB 時 gp2 給的 IOPS 會比較多),另外 -P4 是平行四個 process 跑,改起來會快一些...

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.

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

Amazon S3 現在變成 Strong Read-After-Write Consistency 啦...

看到 Amazon S3 宣佈 Strong Read-After-Write Consistency 了:「Amazon S3 Update – Strong Read-After-Write Consistency」。

這個問題從很久前就被討論過:

所以到這次更新之前,只有新增的 object 會保證馬上出現。現在則是 update 也會:

Effective immediately, all S3 GET, PUT, and LIST operations, as well as operations that change object tags, ACLs, or metadata, are now strongly consistent. What you write is what you will read, and the results of a LIST will be an accurate reflection of what’s in the bucket. This applies to all existing and new S3 objects, works in all regions, and is available to you at no extra charge! There’s no impact on performance, you can update an object hundreds of times per second if you’d like, and there are no global dependencies.

要注意這邊沒有提到 DELETE,所以有可能 DELETE + GET 的操作還是沒有到 strong consistency,不過句子本身意思不是很清晰,也許這幾天會有人在 forum 上面問然後有答案...

另外從公告裡面提到 Amazon EMR 團隊,看起來是 Amazon EMR 團隊一直在內部戳 Amazon S3 的團隊改善:

We’ve been working with the Amazon EMR team and developers in the open-source community to ensure that customers can take advantage of this update with their big data workloads. As a result of that you no longer need to use EMRFS Consistent View or S3Guard, further reducing the cost to run big data workloads in AWS.

AWS Lambda 的消息:計費方式 1ms、上限變高、自訂 Image

這次 AWS re:InventAWS Lambda 也更新了不少東西:

首先是計價方式的改變,從本來 100ms 降到 1ms,對於這點 Cliff 有提出來了,cold start 會是成本中很重的一環 (在 https://www.facebook.com/clifflu666/posts/10214677842380050 這邊):

不過從本來的 100ms 變成現在的 1ms 只會變便宜,如果本來 100ms 的價錢就可以接受的話,現在看起來沒有理由變差 (humm,心情例外)。

會改變的是,以前可能不會想要對 cold start 最佳化 (因為做了還是收 100ms 的錢),現在就可以考慮進去讓成本再降了。

第二個是 lambda 的上限會變成 10GB RAM 與 6vCPU,剛好前幾天翻資料的時候,有翻到改版前的限制:「lambda_cpu_cores.md」,之前的上限是約 3GB 的記憶體與 2vCPU,現在拉起來讓你可以跑更大的東西...

第三個是讓你可以自訂 container image,而不需要用 AWS 提供的標準 image 跑,這點對於降低 cold start 成本也蠻有幫助的,另外一方面,總算是可以對環境客製化了...

裡面看起來最重要的應該還是第一個,計價方式讓整個成本評估大幅改變...