SRE Study Notes - CH2,3,4 (20171117)

SRE Study Group: https://study-area.sre.tw/01_SRE/CH02-04/

Transcript

2. Chapter 2 The Production Environment at Google From the Viewpoint of an SRE 2 https://research.google.com/pubs/105254.html
3. 簡介 Google 資料中心 3
4. 資料中心 - 硬體 4 • 軟體服務器 (Server) • 物理服務器 (Machine) ◦ 10 台物理服務器組成一個 Rack • 數台 Rack 組成一個 Row • 一個或多個 Row 組成一個 Cluster (叢集) • 多個 Cluster 組成一個資料中心 (Datacenter) • 多個相鄰的資料中心組成一個園區 (Campus)
5. 資料中心 - 硬體 5
6. 資料中心 - 硬體 6 • Swtich 是 Google 自己做的 - 叫做 Jupiter • 網路用 Clos 連接 • B4 基於 SDN (OpenFlow 協議) 建置，覆蓋全球
7. 物理服務器的系統軟體 - Borg 7
8. 物理服務器的系統軟體 - Borg 8 • Kubernates (K8s) 的前身 • Borg 負責執行 Job • 每個 Job 由一個或多個 Task 組成 • Borg 自己的 DNS 系統：Borg Name Service (BNS) • 負責分配資源給每個 Task，像是需要 2CPU + 2G RAM • Borg 會自己處理故障的 Instance
9. 儲存 9 • 提供簡單的儲存叢集服務 • 概念類似於 Lustre, HDFS • 實作：Bigtable 、Spanner
10. 網路 • 基於 OpenFlow 協議的 SDN • 沒有用高級的 Router • 計算最佳路徑 • Borg 也負責分配網路頻寬 (Bandwith Enforcer, BwE) 10
11. 其他在資料中心裡的系統軟體 • 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
13. Chapter 3 Embracing Risk (擁抱風險) 13
14. Agenda 14 • 管理風險 • 度量服務的風險 • 服務的風險容忍度 • 辨別消費者服務的風險容忍度 • 基礎設施服務的風險容忍度 • 使用錯誤預算的目的 • 錯誤預算的構建過程 • 好處
15. 管理風險 (Managing Risk) 15 『可靠性』成本提升不是線性增加，而可能是 100 倍。原因歸咎如下： • 冗余物理服務器 / 計算資源的成本 • 機會成本 明確的將維運風險和業務風險對應起來
16. 度量服務的風險 (Measuring Serivce Risk) • 將所有淺在因素，縮減為單一性能指標 • 難以度量的，像是：用戶不滿、信任、品牌口碑、媒體報導 • 指標：計劃外停機 • 風險承受力指標：計劃外停機時間的可接受水平 ◦ 翻譯：能接受多久，非預期的停機時間？ 16 一天 2.5M Request，一天要少於 250 個錯 不見得每個 Request 都是平等的 一年可用性 99.99% 最多可以停 52.56 分鐘
17. 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
18. • 辨別消費者服務的風險容忍度 • 基礎設施服務的風險容忍度 • 兩者都從三個面相看：可用性目標、故障類型、成本 服務的風險容忍度 (Risk Tolerance of Services) 18
19. 辨別消費者服務的風險容忍度 • 可用性目標 ◦ 使用者期望的服務水準是什麼？ ◦ 這項服務關係到收入？ ◦ 這是個有償服務、免費服務？ ◦ 市場上，競爭對手的服務水平為何？ ◦ 這項服務是針對消費者還是企業？ 19
20. • 故障的類型 ◦ 持續的低故障率和偶爾發生的全網中斷哪一個比較糟？ ◦ Case A: 網站部分圖檔無法顯示 ◦ Case B: 網站使用者 A 看到使用者 B 的資料 • 接受計畫內的常規服務中斷 辨別消費者服務的風險容忍度 20 → 盡快找到問題修復網站。 → 馬上把網站關掉，直到問題處理好。
21. • 成本 ◦ 建構和維運多一個零的可用性，收益會增加多少？ ◦ 額外的收入可以抵消付出的成本？ 辨別消費者服務的風險容忍度 21 增加 0.09% 成本只要 900
22. 基礎設施服務的風險容忍度 基礎設施會有多個用戶，每個用戶需求都不一樣。以 Bigtable 為例： • 可用性目標水平 ◦ Bigtable 關注的是吞吐量 (throughput) ，而非可靠性 • 故障類型 ◦ Low latency / High throughput 是兩種不同用戶的需求，這兩種用戶的成功、失敗是相反的 • 成本 ◦ 建立兩個 Cluster: Low latency + high throughput ◦ high throughput: 利用率高, 成本為 low latency 10%-50% 22
23. 使用錯誤預算 (Error Budget) 的目的 • 軟體對故障的容忍度 • 測試 • 部署頻率 • 金絲雀測試 (Canary) 的持續時間和大小 23
24. • 錯誤預算提供一個明確、客觀的指標，決定服務在單一季度中，能接受說多少不 可靠性。 • 實際作法 ◦ 產品管理定義 SLO，確立服務季度中正常運行的時間 ◦ 系統的 uptime 透過中立第三方監控系統 • 範例： ◦ 季度運行目標：99.999% ◦ 錯誤預算：0.001% ◦ 某個問題用了 0.0002% ，相當於佔用了 20% 的錯誤預算 錯誤預算 (Error Budget) 的建構過程 24
25. 關鍵點 25 • 管理服務的可靠性在於風險管理，而風險管理的成本很高 • 100% 不會是正確的可靠性目標 • 錯誤預算的調整可以激勵 SRE 和產品研發團隊，強調共同責任。
27. Chapter 4 Service Level Objectives 服務品質目標 27 https://www.linkedin.com/in/marc-alvidrez-56560/
28. Agenda 28 • 服務品質術語 • 服務指標 (SLI) 在實踐中的應用 • 服務目標 (SLO) 在實踐中的應用 • 服務協議 (SLA) 在實踐中的應用
29. 服務品質術語: SLI / SLO / SLA • Service Level Indicator (SLI)：服務品質具體的量化指標 • Service Level Objectvie (SLO)：SLI 的目標值、範圍值 • Service Level Agreement (SLA) 29
30. 服務品質具體的量化指標，像是： ◦ request latency ◦ error rate ◦ system throughput: request per second (RPS), query per second (QPS) ◦ availability: SRE 重視的 SLI ◦ durability (持久性)：資料能夠完整保存間 Service Level Indicator (SLI) 30
31. 服務品質目標值、範圍值： • latency < 500ms • error rate < 1 RPS • throughput > 100 RPS Service Level Objective (SLO) 31 ITIL: SLT (Service Level Target)
32. 32 https://en.wikipedia.org/wiki/Service_level_objective
33. 故事：Chubby 計畫性內停機 • Chubby is Google’s lock service for loosely coupled distributed systems. • 每個地理位置的服務都仰賴 Chubby • Chubby 故障的頻率很低，導致其他人都以為他不會掛 • 但是 SRE 知道 Chubby 出問題會影響很多服務 • 解法： ◦ SRE 保證達到一定的 SLO，但不會大幅度超越 ◦ 每季度，真實故障沒有將 SLO 可用指標降低，SRE 就會安排死給你看可控性故障，將服務停 機！ ◦ 找出對 Chubby 不合理的依賴 ◦ 強迫每個服務負責人要面對分散式系統的天生缺陷 33
34. 服務與用戶之間一個明確的、或不明確的協議，描述在達到或者沒有達到 SLO 之後 的後果。 • 後果：財務方面的 -- 罰款、退款 • 所以如果沒有定義『後果』，那就是在討論 SLO，而不是 SLA • SLA 通常是與業務產品的決策有關 • SRE 通常不會參與 SLA 的規劃 • SRE 會參與 SLI 的制定、SLO 的量測 Service Level Agreement (SLA) 34
35. 服務指標 (SLI) 在實踐中的應用 35
36. 維運人員和最終用戶關心什麼 • 不需要把所有的指標 (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
37. 指標的蒐集 • borgmon (第十章) • Prometheus • 其他日誌分析系統 - ELK, Grafana, CloudWatch Log …. 37
38. Aggregation • 蒐集指標，需要有原始度量 (Measure) 的資料 • 應該每秒採樣 (Sample)？還是每分鐘？ • SRE 傾向分析百分比的數據，而不是平均值 • 長尾效應比平均數更有特點 38
39. 指標標準化 標準化常見的 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
40. 服務目標 (SLO) 在實踐中的應用 40
41. 目標的定義 • 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
42. 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
43. 服務協議 (SLA) 實踐中的應用 • SLA 需要業務單位、法務單位選擇適合的『後果』條款 • 在 SLA 起草過程中，SRE 可以幫助理解 SLA 的 SLO 達標機率及難度 43
44. Summary • SLA 是用來評量『後果』條款的標準，最常用的是 ◦ availability 99.99% year ◦ durability 99.9999999% year • SLA 由多個 SLO 組成 44
45. Q & A AWS S3 的 11 個 9 是代表什麼？ • SLA • SLO • SLI 45