Skip to content

Ops

用 Terraform, Google Cloud VPN 架設 Hybird Cloud

  • Ops
tags: gcp, cloud-vpn, shared-vpc, terraform

為了更了解地端、雲端網路如何連接，用了 GCP 來做一整套簡單的實驗。

架構說明

img

雲端

為了模擬比較複雜的組織架構，雲端使用了 Shared VPC 的架構，有以下幾個優點：

  • 減少 VPC 數量，較容易管理
  • 多個子專案(service project)可以共享同一個主專案(host project)定義的網路
  • 子專案可以各自分開 billing
  • 劃分網路權限，子專案只能使用主專案定義的網路

要使用 Shared VPC 架構有幾個前提：

  • 須要有 GCP Organization
  • 主專案須設定為 shared VPC host
  • 子專案須 attach 到主專案

雲端的 VPC Gateway 的實作方式採用 GCP 的 Classic VPN，也稱為 route-based VPN，採用事先定義好的靜態路由規則(static routes) 來做 routing。

GCP 還有另一套 VPN 叫 HA VPN，背後是使用 BGP 來做動態路由設定，由於架構較複雜，沒在此實驗採用。

要使用 GCP 的 Classic VPN 有以下前提：

  • 兩端只能走 IPsec 協議
  • 兩端都必須有 public IPv4 位址

在兩端 peering 上也要避免 IP 位址重疊。另外，若要做到高可用，可以建立多個 VPN gateway 來達成。

地端

為了模擬地端環境，另開一個 GCP 專案，也會設定一個獨立的 VPC。

地端採用一台 VM 實例來扮演 VPC Gateway，使用的工具是 strongSwan

Read More »用 Terraform, Google Cloud VPN 架設 Hybird Cloud

淺談 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 讀書筆記（一）