Intel 的 X86S 計畫

清一些連結時看到的,Intel 在 2023 年提出來的 X86S 計畫在進行,在 Linux kernel 裡面可以看到 commit 消息:「Intel continues prepping the Linux kernel for X86S」,引用的消息是「Intel Continues Prepping The Linux Kernel For X86S」。

從 Intel 的文件「Envisioning a Simplified Intel Architecture」這邊可以看到一些想法,看起來開機的部分沒有 real mode 了,直接進入 protected & 64-bit 環境,而對於舊架構的需求上會是透過 CPU exception 讓 OS 或是 VMM 處理,但不知道這樣做效能會損失多少...

再來就是微軟這邊的配合度,然後是定價,以及隔壁 AMD 要不要跟,這些綜合影響到最後面市場買不買單?(除了散戶以外,還包括像 AWS 這些雲端商...)

AWS Lambda 的 cache 架構

Lobsters 上看到的老文章:「[Cache Architecture for] Container Loading in AWS Lambda」,原文從 url 看起來是去年五月發表的資訊了:「Container Loading in AWS Lambda」。

主要是在講 container 怎麼 load 才會儘快執行,首先是提到了大家常用的 layer cache,在 AWS Lambda 上則是改用了 block level cache:

Most of the existing systems do this at the layer or file level, but we chose to do it at the block level.

然後每一塊 512KB:

We unpack a snapshot (deterministically, which turns out to be tricky) into a single flat filesystem, then break that filesystem up into 512KiB chunks.

接著是提到 lazy load 的方式:「Slacker: Fast Distribution with Lazy Docker Containers」:

Our analysis shows that pulling packages accounts for 76% of container start time, but only 6.4% of that data is read.

Slacker speeds up the median container development cycle by 20x and deployment cycle by 5x.

而這個技巧也被用在 AWS Lambda 上,而且是透過 FUSE 實作:

In Lambda, we did this by taking advantage of the layer of abstraction that Firecracker provides us. Linux has a useful feature called FUSE provides an interface that allows writing filesystems in userspace (instead of kernel space, which is harder to work in).

另外一個 AWS Lambda 有實作的是 tiered caching,分成三層,包括了 worker 的 local cache (L1)、同一個 AZ 上的 cache (L2) 以及 S3 上的資料 (L3):

Despite our local on-worker (L1) cache being several orders of magnitude smaller than the AZ-level cache (L2) and that being much smaller than the full data set in S3 (L3), we still get 67% of chunks from the local cache, 32% from the AZ level, and less than 0.1% from S3.

也因為 L3 cache 是 S3 的關係,他們在 L1 與 L2 上就不用擔心 durability 的問題 (反正不見了就往後面找):

The whole set of chunks are stored in S3, meaning the cache doesn’t need to provide durability, just low latency.

但還是用了 Erasure code,儘量維持每個 cache tier 在自己 tier 裡面就可以找到資料的機率,這樣可以盡量降低 peak latency (於是造成 99.9%/99.95%/99.99% 的 SLO 不好看?):

Think about what happens in a classic consistent hashed cache with 20 nodes when a node failure happens. Five percent of the data is lost. The hit rate drops to a maximum of 95%, which is a more than 5x increase in misses given that our normal hit rate is over 99%. At large scale machines fail all the time, and we don’t want big changes in behavior when that happens.

So we use a technique called erasure coding to completely avoid the impact. In erasure coding, we break each chunk up into M parts in a way that it can be recreated from any k. As long as M - k >= 1 we can survive the failure of any node with zero hit rate impact (because the other k nodes will pick up the slack).

大概是本來比較簡單的三層架構在 benchmark 後發現無法達成對應的 SLO,所以就「補上」erasure code 拉高 SLO,從這邊就可以感覺到老闆的要求對於架構設計上的影響...


Slack 自己幹的 Cron System

在 HN 上看到「Executing Cron Scripts Reliably at Scale (」,發現是去年九月的文章:「Executing Cron Scripts Reliably At Scale」(話說 Slack 的 engineering blog 可讀性變差好多,不過這又是另外一回事了...)。

夠大的組織的 cron job system 都會自己幹一套出來用,因為檯面上的都不好用 XD

Slack 的搞法是組合三個內部系統:

  • 一個 container-based 管理實際執行資源的系統,基於 Bedrock,而 Bedrock 則是基於 k8s 上的系統。
  • 一個 job queue 子系統,後面是 Kafka + Redis 組成的。
  • 一組在 Vitess 上的表格,所以後面是 MySQL

這樣的系統也注定這是 Slack-only 的系統了,看一下知道用什麼就好了...

另外一則跟 Prime Video 有關的有趣留言

Hacker News 上的「Even Amazon can't make sense of serverless or microservices (」這邊看到 DHH 抓到機會剛好戳了 AWS 的費用問題,不過讓我注意到的不是 DHH 的文章,而是在 Hacker News 上的留言 35823366,自稱是當時設計這個 serverless 架構的人出來解釋當時的確有壓力測試過,看起來也還 OK:

I actually designed the original serverless system (a few years back when I was still at Prime Video), and yes we did and it did sort of look like it could work until it didn't. Obviously wasn't the right solution for the scale we had in mind (or rather the type of problem we were working on) but it's sad to see the mistake of one team be used to justify shitting on serverless as a general solution.

但這是全新帳號的發言,拿這個 id 去找是可以翻到 TimboKZ 這個 GitHub 帳號,然後一路找也可以看到 Timur KuzhagaliyevLinkedIn 帳號,這個帳號裡面有提到 2019 到 2020 的時候在 Amazon 裡面當 SDE:

Worked on various computer vision projects as a part of Video Quality Analysis team at Prime Video.

是都符合沒錯,但還是不能完全肯定,目前看八卦的心態還是比較多... CTO 解釋 Prime Video 的那篇文章

先前在「Amazon Prime Video 捨棄 AWS Step Functions 回頭用 EC2 與 ECS 省錢的文章」這篇裡面有提到 Prime Video 團隊寫的文章,有點負面 PR 的感覺。

而讓人意外的是 的 CTO Werner Vogels 也寫了一篇文章提到這件事情:「Monoliths are not dinosaurs」。

從標題可以看到他是針對 monolith 架構以及其他的架構在討論,而不是在講 AWS 成本問題 (這反而是原本 Prime Video 那篇文章在標題宣傳的),另外也講了一些管理面上的東西,也就是文章裡面的副標題,以及兩段粗體字:

Building evolvable software systems is a strategy, not a religion. And revisiting your architectures with an open mind is a must.

If you hire the best engineers, you should trust them to make the best decisions.

there is not one architectural pattern to rule them all.

至於算不算是提油... 就見仁見智了。

Amazon Prime Video 捨棄 AWS Step Functions 回頭用 EC2 與 ECS 省錢的文章

昨天在 Hacker News 上熱烈討論的文章,是一篇三月就放出來,但昨天被丟上來意外的熱烈討論,在講 Amazon Prime Video 的團隊改寫程式,把 AWS Step Functions 拔掉,並且回頭用 EC2ECS 而省下大量 AWS 費用的文章討論:「Scaling up the Prime Video audio/video monitoring service and reducing costs (」,原文在「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」,Internet Archive 的備份Archive Today 的備份

先看文章的部分,裡面提到了他們用 AWS Step Functions,但意外的貴:

The initial version of our service consisted of distributed components that were orchestrated by AWS Step Functions. The two most expensive operations in terms of cost were the orchestration workflow and when data passed between distributed components.

然後改寫程式把所有東西都放在單一 process 裡面跑就好,用標準的 EC2 或是 ECS 就可以 scale 很好,而且也省錢:

To address this, we moved all components into a single process to keep the data transfer within the process memory, which also simplified the orchestration logic. Because we compiled all the operations into a single process, we could rely on scalable Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Container Service (Amazon ECS) instances for the deployment.

可以看出起因是一開始設計時的 overdesign,把可以簡單處理的東西拆開,另外加上雲端在這塊收費特別貴而導致成本爆增... 這件事情偶而會發生,尤其是比較新的東西會沒注意到成本,通常在上線發現不太對的時候就會安排 refactor 掉。

但如果是 Amazon 自家集團的其他團隊出來抱怨,就有很棒的 PR 效果了,所以 Hacker News 上就看到有人在猜可能過不久後文章就會不見 XD (但文章紅了以後應該就不會不見 XD):

My word. I'm sort of gob smacked this article exists.

I know there are nuances in the article, but my first impression was it's saying "we went back to basics and stopped using needless expensive AWS stuff that caused us to completely over architect our application and the results were much better". Which is good lesson, and a good story, but there's a kind of irony it's come from an internal Amazon team. As another poster commented, I wouldn't be surprised if it's taken down at some point.

很政治不正確的文章 XD

以之前的經驗來說,AWS 上類似的東西還包括了 NAT Gateway,這東西只適合在有強資安需求 (像是法規要求),而且需要連外的流量很少的時候適合。

NAT Gateway 在新加坡 ap-southeast-1 要 $0.059/hr (美金,所以大約是 $42.48/mo),以及 US$0.045/GB 的處理費用,所以假設你每天只有 100GB (平均 10Mbps),就等於是 3TB/mo,要 $135/mo。這樣整包就 $172.48/mo 了。

如果讓 EC2 機器直接連去 internet 抓資料的話,這些費用就是 $0,你只要付無論是有 NAT Gateway 或是沒有 NAT Gateway 的 outbound traffic 費用部分 (大多是各種 TCP/TLS/HTTP header)。

比較省成本的解法是用 security group 對 outbound traffic 開放特定的流量來解。

另外一種方式還是 NAT,但是是自己架設 HA 的 NAT service,像是 2015 年的文章「The Right Way to set up NAT in EC2」提到的方法。

這個方法以現在的機種來說,兩台 t4g.nano 的機器加上 EBS 不到 $10/mo,唯一要注意的應該是網路頻寬雖然可以 burst 到 5Gbps,但他的網路頻寬是 credit 機制,當 credit 用完的時候 t4g.nano 記得是剩下 100Mbps 左右?不過真的有這個量的時候機器也可以往上開大一點...

另外還有很多「好用」的雲端服務,但看到帳單後就變得「不好用」的雲端服務... 在用之前先算一下成本就會發現了。

Twitter 的 2022 年架構 (?)

Elon Musk 自己貼了以後,有人把白板圖整理成數位圖後好讀一些:


先把圖拉出來看原圖大小 (可以自己點),比較清楚一點:

從最前端往後看,可以看到 TLS-API 被標成淘汰中,照圖上寫的剩下 Android 版本在用,後續應該是往 GraphQL 靠;另外內部有使用到 Thrift,但沒有標 gRPC,我猜是這邊的主線上沒有 gRPC 而已,其他系統可能還是會有。

另外是有些東西有標 next-gen system,應該就是正在做而還沒上線的東西。

Slack 在 2022/02/22 發生的 downtime 說明

Slack 針對今年年初的爆炸提出了說明:「Slack’s Incident on 2-22-22」,但真正的重點都在 Hacker News 的討論串上:「Slack’s Incident on 2-22-22 (」。

大概有三件事情可以講,第一個是掛掉的原因,第二個是剛發出來的時候,一堆人對於標題用的「2-22-22」很感冒,第三個是剛剛 (一個小時前),Cal Henderson (Slack 的 CTO) 跑到 Hacker News 的討論串上回應...

Downtime 的部份

這次的 downtime 主要是發生在 Group Direct Message (GDM) 的部份:

A significant element of the datastore load appeared to be from a query that listed Group Direct Message (GDM) conversations by user. This operation is fronted by our cache tier, so the high query load seemed to indicate something was wrong with our caches.

這個 GDM 的查訊效率不高,而是靠 cache layer 撐住的,加上二月 22 日那天他們在更新 Consul 的 agent,導致 hit rate 的下降,以及遇到一個比較大的 peak time,接著就壓垮了資料庫。

oh,這中間還有 Vitess 一起進來打架,原文講的比較清楚,但需要花一些時間看。


剛發表出來的時候,其實大多數的討論反而是在討論「2-22-22」這件事情,這的確是很差的表示方法,尤其對於一份公告來說,不過這個問題本來就是個 flame war 等級的話題...

Slack CTO (Cal Henderson) 的回應

在重刷頁面的時候發現 iamcal 這個帳號的回應,而 Cal Henderson (Slack CTO) 的個人網站是,雖然不確定這是不是本人帳號,但看起來之前在 2011 註冊後都沒動...

這個帳號回了兩個訊息,一個是提到 AWS 上其實很常看到 failure,需要靠本身架構的穩定性來撐:

Our underlying hardware (AWS) is nothing like this reliable. We see regular (several times a year) failure of racks of machines or whole DCs.

Across the whole fleet (all services), we lose 1-10 servers per day as a baseline. Major events are then on top of that and can impact thousand of hosts at once.


> Even the largest Slack instance probably has under 100,000 users and less than 1000 peak messages per second.

This is not true, by an order of magnitude.


Martin Fowler 在 2015 年寫的 MonolithFirst,以及 Microservice 的問題

Hacker News Daily 上看到「MonolithFirst」這篇,是 Martin Fowler 在 2015 年寫的文章,對應在 Hacker News 上的討論「Monolith First (2015) (」也頗有趣的,可以一起翻。

tl;dr:他的文章就是在講新專案用 monolith,不要去碰 microservice。

文章開頭提到了就他觀察到的情況:第一點是,幾乎所有成功的 microservice 案例都是從 monolith 起頭,再轉到 microservice 環境;第二點是,幾乎所有一開始用 microservice 的案例,在後來都遇到嚴重的問題:

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

  1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
  2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .


第一點可能的原因是 Yagni (You Aren't Gonna Need It),在試驗市場時 PoC 或是 MVP 的商業邏輯反而不會那麼複雜,快速用 monolith 開發驗證比起擁抱 microservice 來的重要太多,而且可以快速修改。

第二點分成兩個現象:第一個現象是,即使是對產品的商業領域很有經驗的資深架構師,也很難一開始就切出正確的 BoundedContext;第二個現象是,在 microservice 裡,改架構的難度比起 monolith 高非常多 (i.e. 跨 boundary 的 refactoring)。這兩個現象加在一起就會造成一開始導入 microservice 的專案失敗。

文章接著想要提出一些建議,在一開始使用 monolith 可以注意的方向,這些注意的事項可能可以讓之後轉成 microservice 變得比較輕鬆。

第一種方式是在 monolith 架構下注意 API boundary 與 data 的儲存方式,當想要切換到 microservice 的時候就有機會比較簡單。

第二種是更常見的方式,一開始先是 monolith 架構,然後把 boundary 好切割的拆成 microservice,所以在過度期會是一組不那麼大的 sub-monolith 架構,然後週邊圍繞著很多 microservice。這個做久了就有機會轉成全部都是 microservice。


第四種方式是一開始的時候不用 monolith,而是幾個很大包的 service (所以一開始不太能叫 microservice),當商業模式成熟穩定後,切出更細緻的 boundary 的時候再拆成 microservice。

把這篇文章拿去搜尋 Hacker News 上的討論,可以看到除了 2021 年的這次討論外,在 2017 年的時候就有一批討論也蠻有趣的,可以看到有些不同的風向:「Monolith First (2015) (」。

當然也未必要信 Martin Fowler 的看法,軟體工程這塊還是有很多不同的流派...

Stack Overflow 公開 2016 的架構

Stack Overflow 公開了 2016 年現在的系統架構:「Stack Overflow: The Architecture - 2016 Edition」。

Stack Overflow 的重要性可以從前陣子 Twitter 上流傳的一張讓大家笑的很開心的圖看出來:

身為目前「程序猿」(!) 最重要的 debug (!!) 資料來源,而且是目前少數用 ASP.NETMicrosoft SQL Server 作為網站與資料庫的架構,並且是放在傳統 IDC 機房而非 Cloud Service 的知名網站,大家也很好奇他們是怎麼堆出來的。

上次公開 Stack Overflow 的系統架構是 2013 年年底了 (參考當時寫的「Stack Overflow 的現況...」這篇),這份更新距離上次兩年多了,也有很多可以交叉比較的事情。

比較有趣的是效能的提昇的說明,本來以為會是說因為我們改善程式碼的效率或是其他類似的理由,結果居然直接說是因為買新機器了 XDDD:

You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That’s due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves.

另外覺得比較有趣的是 CiscoASR-1001ASR-1001-x,不知道是什麼理由選擇這個系列,改天找 Cisco 的朋友問問看好了...

另外他們的 Websockets 也拿來做有趣的事情:

We use websockets to push real-time updates to users such as notifications in the top bar, vote counts, new nav counts, new answers and comments, and a few other bits.

另外他們也發現有些瀏覽器連線已經連 18 個月了 (喂喂),也許應該去看一下人是不是還活著:

Fun fact: some of those browsers have been open for over 18 months. We’re not sure why. Someone should go check if those developers are still alive.

我猜是 production server 上開瀏覽器查資料後沒關掉,就一直連著...