1

Chapter 2The Production Environment at Google

From the Viewpoint of an SRE

2

https://research.google.com/pubs/105254.html

簡介 Google 資料中心

3

資料中心 - 硬體

4

● 軟體服務器 (Server)● 物理服務器 (Machine)

○ 10 台物理服務器組成一個 Rack● 數台 Rack 組成一個 Row● 一個或多個 Row 組成一個 Cluster (叢集)● 多個 Cluster 組成一個資料中心 (Datacenter)● 多個相鄰的資料中心組成一個園區 (Campus)

資料中心 - 硬體

5

資料中心 - 硬體

6

● Swtich 是 Google 自己做的 - 叫做 Jupiter● 網路用 Clos 連接

● B4 基於 SDN (OpenFlow 協議) 建置，覆蓋全球

物理服務器的系統軟體 - Borg

7

物理服務器的系統軟體 - Borg

8

● Kubernates (K8s) 的前身

● Borg 負責執行 Job● 每個 Job 由一個或多個 Task 組成

● Borg 自己的 DNS 系統：Borg Name Service (BNS)● 負責分配資源給每個 Task，像是需要 2CPU + 2G RAM● Borg 會自己處理故障的 Instance

儲存

9

● 提供簡單的儲存叢集服務

● 概念類似於 Lustre, HDFS● 實作：Bigtable 、Spanner

網路

● 基於 OpenFlow 協議的 SDN● 沒有用高級的 Router● 計算最佳路徑

● Borg 也負責分配網路頻寬 (Bandwith Enforcer, BwE)

10

其他在資料中心裡的系統軟體

● Lock Service: Chubby - The Chubby lock service for loosely-coupled distributed systems

● Monitoring and Alerting: Borgmon● Software Infrastructure:

○ Remote Procedure Call (RPC) -> Stubby -> gRPC○ Protocal Buffer: gRPC 傳輸格式，簡稱 Protobuf

● Development Environment:○ 圍繞基礎建設，建構完整的開發環境

○ 工程師如果遇到工作項目之外的組建問題，可以修改這個問題，並且提出 CL (ChangeList)○ CL 會被測試框架測試，如果破壞了其他工作，就會通報提交者。

○ CL 通過測試，會自動部署正式環境

11

12

Chapter 3Embracing Risk (擁抱風險)

13

Agenda

14

● 管理風險

● 度量服務的風險

● 服務的風險容忍度

● 辨別消費者服務的風險容忍度

● 基礎設施服務的風險容忍度

● 使用錯誤預算的目的

● 錯誤預算的構建過程

● 好處

管理風險 (Managing Risk)

15

『可靠性』成本提升不是線性增加，而可能是 100 倍。原因歸咎如下：

● 冗余物理服務器 / 計算資源的成本

● 機會成本

明確的將維運風險和業務風險對應起來

度量服務的風險 (Measuring Serivce Risk)● 將所有淺在因素，縮減為單一性能指標

● 難以度量的，像是：用戶不滿、信任、品牌口碑、媒體報導

● 指標：計劃外停機

● 風險承受力指標：計劃外停機時間的可接受水平○ 翻譯：能接受多久，非預期的停機時間？

16

一天 2.5M Request，一天要少於 250 個錯不見得每個 Request 都是平等的

一年可用性 99.99% 最多可以停 52.56 分鐘

17

SLA Downtime Day Hour Min

99% 1% 3.65 87.6 5,256

99.5% 0.5% 1.852 43.8 2,628

99.9% 0.1% 0.365 8.76 525.6

99.99% 0.01% 0.0365 0.876 52.56

99.999% 0.001% 0.00365 0.0876 5.256

99.9999% 0.0001% 0.000365 0.00876 0.5256

● 辨別消費者服務的風險容忍度

● 基礎設施服務的風險容忍度

● 兩者都從三個面相看：可用性目標、故障類型、成本

服務的風險容忍度 (Risk Tolerance of Services)

18

辨別消費者服務的風險容忍度

● 可用性目標

○ 使用者期望的服務水準是什麼？

○ 這項服務關係到收入？

○ 這是個有償服務、免費服務？

○ 市場上，競爭對手的服務水平為何？

○ 這項服務是針對消費者還是企業？

19

● 故障的類型○ 持續的低故障率和偶爾發生的全網中斷哪一個比較糟？

○ Case A: 網站部分圖檔無法顯示

○ Case B: 網站使用者 A 看到使用者 B 的資料

● 接受計畫內的常規服務中斷

辨別消費者服務的風險容忍度

20

→ 盡快找到問題修復網站。

→ 馬上把網站關掉，直到問題處理好。

● 成本○ 建構和維運多一個零的可用性，收益會增加多少？

○ 額外的收入可以抵消付出的成本？

辨別消費者服務的風險容忍度

21

增加 0.09% 成本只要 900

基礎設施服務的風險容忍度

基礎設施會有多個用戶，每個用戶需求都不一樣。以 Bigtable 為例：

● 可用性目標水平○ Bigtable 關注的是吞吐量 (throughput) ，而非可靠性

● 故障類型○ Low latency / High throughput 是兩種不同用戶的需求，這兩種用戶的成功、失敗是相反的

● 成本○ 建立兩個 Cluster: Low latency + high throughput○ high throughput: 利用率高, 成本為 low latency 10%-50%

22

使用錯誤預算 (Error Budget) 的目的

● 軟體對故障的容忍度

● 測試

● 部署頻率

● 金絲雀測試 (Canary) 的持續時間和大小

23

● 錯誤預算提供一個明確、客觀的指標，決定服務在單一季度中，能接受說多少不

可靠性。

● 實際作法○ 產品管理定義 SLO，確立服務季度中正常運行的時間

○ 系統的 uptime 透過中立第三方監控系統

● 範例：○ 季度運行目標：99.999%○ 錯誤預算：0.001%○ 某個問題用了 0.0002% ，相當於佔用了 20% 的錯誤預算

錯誤預算 (Error Budget) 的建構過程

24

關鍵點

25

● 管理服務的可靠性在於風險管理，而風險管理的成本很高

● 100% 不會是正確的可靠性目標

● 錯誤預算的調整可以激勵 SRE 和產品研發團隊，強調共同責任。

26

Chapter 4Service Level Objectives

服務品質目標

27

https://www.linkedin.com/in/marc-alvidrez-56560/

Agenda

28

● 服務品質術語

● 服務指標 (SLI) 在實踐中的應用

● 服務目標 (SLO) 在實踐中的應用

● 服務協議 (SLA) 在實踐中的應用

服務品質術語: SLI / SLO / SLA● Service Level Indicator (SLI)：服務品質具體的量化指標

● Service Level Objectvie (SLO)：SLI 的目標值、範圍值

● Service Level Agreement (SLA)

29

服務品質具體的量化指標，像是：

○ request latency○ error rate○ system throughput: request per second (RPS), query per second (QPS)○ availability: SRE 重視的 SLI○ durability (持久性)：資料能夠完整保存間

Service Level Indicator (SLI)

30

服務品質目標值、範圍值：

● latency < 500ms● error rate < 1 RPS● throughput > 100 RPS

Service Level Objective (SLO)

31

ITIL: SLT (Service Level Target)

32https://en.wikipedia.org/wiki/Service_level_objective

故事：Chubby 計畫性內停機

● Chubby is Google’s lock service for loosely coupled distributed systems.● 每個地理位置的服務都仰賴 Chubby● Chubby 故障的頻率很低，導致其他人都以為他不會掛

● 但是 SRE 知道 Chubby 出問題會影響很多服務

● 解法：○ SRE 保證達到一定的 SLO，但不會大幅度超越

○ 每季度，真實故障沒有將 SLO 可用指標降低，SRE 就會安排死給你看可控性故障，將服務停

機！

○ 找出對 Chubby 不合理的依賴

○ 強迫每個服務負責人要面對分散式系統的天生缺陷

33

服務與用戶之間一個明確的、或不明確的協議，描述在達到或者沒有達到 SLO 之後

的後果。

● 後果：財務方面的 -- 罰款、退款

● 所以如果沒有定義『後果』，那就是在討論 SLO，而不是 SLA ● SLA 通常是與業務產品的決策有關

● SRE 通常不會參與 SLA 的規劃

● SRE 會參與 SLI 的制定、SLO 的量測

Service Level Agreement (SLA)

34

服務指標 (SLI) 在實踐中的應用

35

維運人員和最終用戶關心什麼

● 不需要把所有的指標 (Metric) 都定義為 SLI● 代表性的健康指標 4~5 個就夠了

● SLI 常見的歸類○ User-facing serving systems: availability, latency, throughput

■ 所有人都關心的

○ Storage systems: latency, availability, durability○ Big data systems: data pipeline, throughtput, end-to-end latency○ Correctness (正確性)

36

指標的蒐集

● borgmon (第十章)● Prometheus● 其他日誌分析系統 - ELK, Grafana, CloudWatch Log ….

37

Aggregation● 蒐集指標，需要有原始度量 (Measure) 的資料

● 應該每秒採樣 (Sample)？還是每分鐘？

● SRE 傾向分析百分比的數據，而不是平均值

● 長尾效應比平均數更有特點

38

指標標準化

標準化常見的 SLI，避免每次都重新評估

● Aggregation intervals: “Averaged over 1 minute”● Aggregation regions: “All the tasks in a cluster”● How frequently measurements are made: “Every 10 seconds”● Which requests are included: “HTTP GETs from black-box monitoring jobs”● How the data is acquired: “Through our monitoring, measured at the server”● Data-access latency: “Time to last byte”

39

服務目標 (SLO) 在實踐中的應用

40

目標的定義

● SLO 具體定義 (可以有多個)○ 90% Get RPC < 1ms○ 99% Get RPC < 10ms○ 99.9% Get RPC < 100ms

● 如果同時有批次處理用戶，以及即時用戶，SLO 可以是：○ 批次: 95% Set RPC < 1s○ 即時: (99% Set RPC + RPC Loading < 1K) < 10m

● 再次強調: SLO 100% 是不合理，也是高成本的

41

SLO 的選擇

● Don’t pick a target based on current performance○ 不能只看眼前，要從全局出發

● Keep it simple○ 太複雜的匯總，會難以理解，同時會掩蓋系統性的變化

● Avoid absolutes (絕對值)○ 要求擴展系統而沒有增加任何 latency ，或者永遠 Available 都是不切實際的

● Have as few SLOs as possible○ 選擇足夠的 SLO 覆蓋系統屬性

● Perfection can wait (不完美也很美)○ 隨著時間了解系統之後，進行 SLO 定義與調整。

42

服務協議 (SLA) 實踐中的應用

● SLA 需要業務單位、法務單位選擇適合的『後果』條款

● 在 SLA 起草過程中，SRE 可以幫助理解 SLA 的 SLO 達標機率及難度

43

Summary● SLA 是用來評量『後果』條款的標準，最常用的是

○ availability 99.99% year○ durability 99.9999999% year

● SLA 由多個 SLO 組成

44

Q & AAWS S3 的 11 個 9 是代表什麼？

● SLA● SLO● SLI

45