Skip to content

淺談 Moby’s BuildKit

  • Dev, Ops

前陣子因為工作需要,研究了一下所謂 Docker build 的 3.0 版本 —— docker buildx build,希望能找出其與 docker build 背後的差異

docker buildx 指令是使用 Moby’s BuildKit 這套工具來代理 building,所以以下會用 BuildKit 來指稱新的建構模式

直接下結論

  • BuildKit 須要透過一個前端服務去轉換 Dockerfile (或其他語言定義的建構流程),再交給 LLB 處理
  • 即使是同一個 Dockerfile,docker build/buildx 兩者建構出的 layer 完全不同,無法共享
  • 如果你建構很複雜,已經有在使用 multi-stage build(例如須要先編譯成二進制檔案),那會比較有幫助,如果是要 build 類似 python 這種直譯式的應用程式,因為流程較為單純所以幫助不大

Read More »淺談 Moby’s BuildKit

SRE: How Google Runs Production Systems 讀書筆記(四)

  • Ops

on-call

關鍵是「數量」跟「品質」的平衡:

  • 數量:不超過 25% 時間 on-call
  • 品質:須要有充足的時間處理(含分析、debug、事後檢討,一個事件約須花 6 小時完成)

幾分鐘內要回應?

回應時間與服務水準、可靠性有關,例如面向使用者的服務須在 5 分鐘內回應,非敏感業務通常是 30 分鐘

維運負擔過大怎麼辦?

事件 / 警報比例應接近 1:1,避免重複警報導致維運壓力、調派有經驗的 SRE 協助、與研發團隊一起分擔維運

系統太穩定怎麼辦?

維運壓力不夠會導致自信過度或自信不足,每個工程師每季應至少參與一次 on-call,公司可定期舉辦災害演練

故障排除技巧

故障排除是一連串的「假設」+「排除」,這個技能是可以教學相長的,如果能做好事後檢討、紀錄負面結果(negative result),故障排除會是學習一套系統很有效的方法

小心避免以下陷阱:不理解現象(方向錯誤)、假設是對的,但測試假設的方法錯誤、過早下結論、被巧合/偽相關誤導

「緊急情況下,飛行員的首要任務是保持飛機飛行及安全登陸,故障定位和排除只是次要目標。」

Google 用什麼追蹤工具?

每個系統用的工具可能不同,文中提到的 Dapper 是 Google 內部很廣泛應用的工具,特別看了一下文獻整理幾個重點

在分散式系統,跨服務請求很常見,例如發出一個 requestX,在下游會發出額外數個請求 —— 攤開看就是一個 Tree(巢狀的 RPCs)

這個請求/響應歷程的樹狀結構稱為一個 Trace,當中的節點就是單一請求/響應,稱為 Span,裡面會紀錄時間戳、traceID、parentID、host 等詳細資訊。Span 是以本地文檔的方式建立和寫入的,再透過 Dapper daemon 去拉取並儲存到後端 —— BigTable, Trace 存成 row,Span 存到其對應的 sparse column

可以把 Span 視為是一種 Log,除了運行在伺服器上的 Dapper daemon,應用程式也可以透過函式庫發送 Span、加標籤或自訂的額外訊息等,這個重要功能稱為 annotation

Dapper 設計上很重視的理念是「低成本」,包含本地檔案的讀寫、後端儲存、網路頻寬(只佔小部份),因此採用取樣 (sampling) ,經驗上顯示取樣不只可以大幅降低延遲,也能讓資料得以保存更久,Dapper 的預設取樣率是 1/1024——對數據密集型系統而言,不會造成分析上的盲點

Dapper 原本只是一個追蹤工具(黑箱的),但後來演化成一個大型的監控平台,有強大的界面可以幫助分析,甚至到後來,發現可以應用的層面更廣:系統的依賴關係(dependency)分析、網路狀態分析、在共享儲存的基礎上區分服務、長尾延遲的分析、錯誤報告分析等

Read More »SRE: How Google Runs Production Systems 讀書筆記(四)

SRE: How Google Runs Production Systems 讀書筆記(三)

  • Ops

發行工程(release engineering)

這章開頭介紹了有關「發行」這個新的學科,在 Google 雖由 SRE 以外的特定角色負責,但 SRE 一樣須要與之密切合作與關注;後半部份介紹發行流程、以及 Google 使用的發行系統 Rapid 與建構工具 Blaze (開源版本為 Bazel)

發行工程師在幹麻?

發行工程是一項獨立出來的工作,核心是 build 跟 deliver,由發行工程師負責

發行工程師的工作不是「負責發行」,而是開發工具、制定 best practice,好讓產品研發團隊能自主發行,也就是 self-serving

發行模式有哪些?

發行的步驟由發行工程師、SWE、SRE 三者一起定義,舉幾個例子:

  • 每小時建構一次,再根據變更項目和測試結果挑出要發行的版本
  • Push On Green,測試通過就發行

因規模和軟體性質而異,有的發行時間會需要延長到好幾天(如基礎設施)

怎麼建構?

無論使用什麼建構工具(Google 用 Blaze),建構應該要是一致且可重複的,也就是在兩台不同機器上建構同一個版本,應該得到相同結果

建構過程應是密閉的 (hermetic),不應受機器上安裝的其他函式庫或軟體影響

正式站有 bug 怎麼辦?

Google 通常不在 master 分支直接發行,而是從 master 切新的分支用來發行(避免建構後無關的變更影響到 master)

針對 bug 的修復會先上到 master,在發行分支再把該變更 cherry pick 過來,即可重新建構跟發行

怎麼持續建構/部署?

因為這章提到的工具跟元件比較多,從 Florian Rathgeber 的簡報上找到的一張關聯圖來看可能會比較好理解

image

  • Midas Package Manager(MPM):是 Google 使用的套件管理系統,資料元存在 BigTable 上。我粗淺的理解方式是把它「對應」到容器的映像檔,它們都是利用「名稱 + 標籤」作為唯一識別,但比起容器映像檔,MPM 有更進階的功能,例如 ACL 跟簽章;另外一個從根本上不同的是映像檔是有序的 layers,而 MPM 則是無序的 filegroups
  • Blaze:建構工具,用來建構 MPM、二進制檔案、對應的測試
  • Rapid:分散式發行系統,可執行由建構藍圖 (blueprint) 定義的工作流、利用 Blaze 來跑建構及測試;Worker 是跑在 Borg 上,可以並行處理發行工作
  • Sisphus(希臘神話的薛西佛斯):自動化部署的框架,提供更彈性的部署功能、流程儀表板

一句話概括基本流程:Rapid 負責跑測試、建構 MPM(打上特定標籤),Sisphus 負責部署此 MPM 版本

Read More »SRE: How Google Runs Production Systems 讀書筆記(三)

SRE: How Google Runs Production Systems 讀書筆記(二)

  • Ops

第三章在講風險,開頭再度強調了「不該追求極端的可靠性」,我們必須考慮機會成本——可靠性的成本並非線性成長,多追求一個級別的提昇(例如 99% 提昇至 99.9%)說不定成本要提高百倍才做得到,甚至,好不容易達成後對使用者來說根本沒差

怎麼看風險?

可靠性(或者說對故障的容忍程度)是靠風險管理得出的結果。風險是一個非線性的連續體(continuum)的概念,我們要問的問題是:服務合理的風險是多少?

合理的風險更像是一個可選的區間,透過衡量「成本」、「業務風險」與「維運風險」對應後我們可以再選出一個目標值

怎麼量化風險?

故障導致的業務風險很難量化(例如媒體大肆報導導致退訂),最直接的作法是參考指標(延遲、停機時間、請求成功率等)

拿停機時間來看——可用性水準訂為 99.99%,一年當中可以接受的停機時間就是 52.56 分鐘

但對分散式服務來說,停機可能是很久才會發生一次的(較難追蹤校正),可以改用請求成功率——可用性水準訂為 99.99%,如果一天要接受 2.5 M 個請求,錯誤數量少於 250 個即可(要注意不同請求的重要性不同,直接面向使用者的請求會更重要)

可用性目標應該多久更新一次?訂定的依據是什麼?

通常以一季為單位來訂,每週或每天追蹤其變化

成本考量很重要,舉了一個很好的比較:Gmail 跟 Youtube——Gmail 定的可用性目標很高,因為如果服務中斷,會導致大量成本及嚴重後果(例如包含許多企業在內的使用者流失);反之,為 Youtube 設定的可用性目標較低,因為快速發展更重要

可以思考下列這些問題:

  • 使用者是誰?他們期望怎樣的服務水準?
  • 服務是否直接關係到收入?(公司的收入或客戶的收入都算)/ 是付費還是免費?
  • 競爭對手的服務水準如何?
  • 多一個「9」,收益增加多少,成本增加多少?
  • 服務是否為基礎設施?服務水準是否可以適用各個業務端?

如果難以訂定,可以參考「ISP 的服務錯誤率」(大約 0.01%-1%),只要可用性優於此基礎,故障就會被網際網路的噪音(noise)掩蓋掉

持續發生的零星故障 / 全網中斷哪個更糟糕?

看情況。不同故障類型不能以同樣方式來量化,要考慮不同故障會對業務端造成多大影響

同一個服務怎麼滿足不同類型的使用者?

有時服務的特性是雙面刃,書上舉了 BigTable 為例:要低延遲,利用率愈低愈好(可以更快處理),但要低成本,利用率愈高愈好(避免閒置)

我自己在使用 BigTable 也遇過這種競爭約束(competing constraints)的情況:同一個應用要服務 streaming 跟 batch 這兩種不同場景

書上提供一個解決方式:用戶隔離——低延遲使用者跟離線分析使用者分別使用不同叢集

Read More »SRE: How Google Runs Production Systems 讀書筆記(二)

SRE: How Google Runs Production Systems 讀書筆記(一)

  • Ops
  • Google SRE 全球共計約 1000 人
  • SRE 是一群天生的懷疑論者,懷疑一切「高大尚」技術,以及任何「神奇的產品」
  • SRE 在確保系統可靠性方面沒有什麼萬靈丹,有的只是極度的務實(progmatic)
  • 如果用一個詞來描述 Google 的歷史,那就是不斷的 scaling up
  • 系統維運本質上是人與電腦共同參預的一項系統性工程
  • IT 產業大多自我封閉,交流過少,很多從業人員或多或少受到教條主義的限制
  • 今天我們能感受到整個業界都在鼓吹厚顏無恥的「給我程式碼,其餘免談」;開源社群內部也正在形成一種「別問我問題」的風氣,過於強調平等卻忽略專家的意見
  • 相對於最終的軟體結果、架構設計,真實的設計過程和作者本身的思考歷程更具價值
  • 一套軟體的 40% ~ 90% 成本,其實是花費在建置之後的不斷維護過程

SRE 的工作範疇

  • 維運具體服務
  • 設計研發大型分散式系統
  • 協助產品部門開發其系統的額外元件,如負載平衡,同時盡可能重複使用這些元件
  • 想出各式各樣的方法,利用現有元件解決新的問題
  • 對架構設計、維運流程不斷最佳化,讓這些大型系統有更好的「可靠性」

  • 可靠性(reliability)——系統能夠在指定環境下,在要求的時間內成功持續執行某個功能的機率
  • SRE 的 「S」最開始指的是 google.com
  • SRE 是從 Google 的內部職位、從 Web 社群中誕生的
  • 與 DevOps 一詞不同的是,SRE 同樣認同 IaC,但 SRE 最關注的是可靠性(或者說是風險),甚至可以為了可靠性而「消除維運的需求」
  • 可靠性就像安全性,愈早關注愈好
  • 「無論對一套系統的執行原理掌握得多麼透徹,也不能阻止人為的意外錯誤。」
  • SRE 的 「E」可以指事 —— Engineering,也可以是指人——Engineer

Read More »SRE: How Google Runs Production Systems 讀書筆記(一)

步入中年的轉職馬拉松 / 一個低端工程師的自白

Intro

在 2019 年底,還在上個公司就職的我,應一個面試邀約拜訪了 91APP。因為拜社群之福,我在早期就有「持續面試很重要」這個概念,不管你當下有沒有工作。

當時的我剛完成一個機器學習的基礎設施,讓整個流程得以自動化,頗為自得意滿。我天真地以為,別人會找我去面試,單純是因為我值得。

也是在這個面試中,我踩了人生第一個面試地雷——那就是抱怨當前的工作。我說:公司專案太多又太雜了,又都只有一兩個人負責。

結果可想而知,在隔天收到了感謝函。不過幸運的是,邀約我的前輩順帶給了一些很客氣的提點。他在信裡這麼說:「你的硬實力是不錯的,但你缺乏軟實力。」

同一個時期,想要離職的念頭開始萌芽。當然,我並非討厭這個工作,反而更像是漸漸找不到工作的意義了。上下班的時候,腦中不停發出例外,可以說它是一種 ValueError ,而當時的我並不知道如何去處理這個例外。

造成這個例外的可能情形:

  • 潛意識地知道自己知識量不足(軟實力),但沒花足夠的時間來彌補,大部分時間都花在拼湊和硬幹上面(硬實力)
  • 腦海中有「標準」的藍圖,但不是很清楚,而公司的標準接近能動就好,因此無所適從
  • 開始懷疑自己,懷疑專案的發展性
  • 一直以來的單打獨鬥,嚮往可以激盪討論合作的環境,說白一點就是希望有人帶
  • 不想再扮黑臉(沒錯我是 INTP)

終於,某天公司的舊系統因為太舊出問題了(單純就是因為太舊),雖然我沒接觸過該系統,但身為後端人員,多少還是覺得有點責任。當下去了一趟 Legacy 後,發覺再也忍受不了了。我喪失了所有自信。我只想讓腦袋重新開機。

我必須馬上去談這件事。當天,我跟主管提出離職的想法。我只知道自己該做出一些改變,或者更深入地說,我害怕因為長時間忽略這些內心感受,進而潛移默化成自己不想變成的那個人,再也做不出正確的決定。我也想起有人說三十歲是工程師生涯重要的臨界點。那麼與其不上不下的,不如去尋求一個長遠的突破。

借托爾斯泰之筆,我們可以這樣隱晦描述──「幸福的 RD 總是幸福的,不幸的 RD 各有各的不幸。」

也就是說,即使在別人眼裡,工程師看起來是那樣吃得好穿得暖,但事實是每個工程師和你們一樣,都有各自難以解決的問題。就如同我的 ValueError

Read More »步入中年的轉職馬拉松 / 一個低端工程師的自白

Bitnami