# 3/8 SRE 讀書會共筆

---

場地提供：PIXNET
- 誠徵 [SRE 服務可靠度工程師](https://gist.github.com/jnlin/8329bea1c1ed92a1924da7e032304261)，有興趣的朋友可聯繫 [e-mail]

# 第二十二章處理連鎖故障 - ccshih

## 前言
- 整體系統的一部分故障，導致系統其他部分更容易故障（會傳染）
- 假設所有 FE 節點目前都接近滿載，當掛了一個，其他節點會因過載而故障
- 分散式系統的日常
- 直覺如何解決？
- 避免滿載情形發生
- 避免故障擴散，例如作限流

## 大綱
- 連鎖故障的原因
- 避免伺服器過載
- 慢啟動與冷快取
- 連鎖故障夾針對連鎖故障的測試方式
- 連鎖故障的立即處至
- 結論

## 連鎖故障的原因
- 過載，大部分的原因
- 掉 instance 可能導致其他故障
- 資源耗盡
- 可能是程式寫錯
- 上下游間的蔓延

## 當 CPU 耗盡，會發生
- 處理中的請求增加
- 同時處理的請求量上升
- 佔用更多的運算資源，也可能佔用更多下游資源
- 請求在 Queue 中等待
- 增加延遲時間、佔用更多記憶體
- Thread Starvation
- 需要的 Lock 被長時間綁架，Thread 只能 wait
- 被 Watchdog 重新啟動
- 因為超過客戶要求的 RPC deadline，而被 Retry 轟炸
- 不斷作白工 (Think Lean)
- 不斷地 Context-switch 導致 Cache 無法發揮
- 惡性循環

## 當記憶體耗盡，會發生
- Process 被賜死
- GC
- GC > 耗 CPU > 請求增加 > 耗記憶體 > GC > 死循環
- 擠壓應用程式快取空間
- 增加下游負擔

## 當 File description 耗盡
- health check 失敗

## 故障循相依關係蔓延，難以追查根因
### 前端 Java 服務
- 若跨不同單位，更難以追查
- 快取命中率降低
- 快取空間不足
- 記憶體吃緊
- 因為 GC 而 CPU 吃緊
### Backend

## Case Study
- [好文介紹]Scaling Kubernetes to 2,500 Nodes: http://www.evanlin.com/til-openai-5000/

## 被洶洶洪流沖到再起不能
- 假設一個服務的最大承載量 100 QPS，因無法承載上游 110 而導致連鎖故障
- 此時若上游降低為 90 QPS，仍然無法停止連鎖故障，因為當連鎖故障發生時，最大承載量已經遠小於 100 QPS

## 上游 LB 錯認狀態，在忙碌時引發連鎖故障
- 可提供服務，但上游 LB 卻以為不行

## 如何避免過載
- 事先壓力測試，知道承載極限在什麼位置
- 過載的時候，為了節省資源，提供較差的結果
- 自行限流，例如控制上游
- 先做好容量（capacity) 規劃; 必要但不可以完全依賴

## Queue 的用途
- 舉例：抽號碼牌，進 Queue，由櫃台處理
- Thread Pool 可以派多少 Thread 處理？
- 一般希望 Queue 的容量越大越好，收很多人進來
- 但排隊的會不開心，因為要等很久
- 假設 Queue 容量是 Thread Pool Size 十倍
- 一個單位處理時間是 0.1 秒，第十一個就要等 10 秒

## Queue 容量的建議
- 滿載時拒絕客戶

## 流量拋棄
- 避免被沖垮
- Per-task throttling 限制場內人數
- 從 FIFO 換成 LIFO 客戶不等了就不用浪費時間
- 作客戶分級，可能先拋棄不重要的流量
- 每個元件都要掐住流量嗎？還是只針對上游？

## 優雅降級
- 應用如果允許，給予較差的結果; 但視為罕見狀況，若常觸發需告警
- 不應該常常發生
- 規劃開關條件，不要太複雜的自動啟動條件，而且容易關閉

## Retry
- 過載的時候，Retry 是惡性循環的原因
- 就算是負載緩慢增長也會導致

- 這兩種狀況可能問題也不會消失
- 須花很多資源處理
- 本來就不穩定

## 如何處理重試
- 前述避免過載的策略
- Exponential Backoff: back-off delay (10s, 20s, 40s ...)
- 限制重試次數
- 在伺服器設定重試預算
- Jitter (將重試負擔平均分散這各個時間)
- 某些像是 400 的錯誤不需要重試
- 監控重試的比率

## Deadline
- 有點像是 Timeout 的東西
- 不要作客戶不會用到的東西
- 對伺服器而言：
- 太短：敏感，放棄有用的半成品
- 太長：不要要的鎖住資源，作虛工
- 須考量網路延遲
- 設計一個 end to end 的時間，例如 200ms，所有的元件加總起來必須在 200ms 內完成 (gRPC slide)

## 延遲的雙峰分布 Bimodal Latency
- Thread per request 1000 QPS, 正常處理時間 100ms，需要 100 個 Thread 滿載處理
- Pool 配置 1000 個 thread，所以 Thread Util = 10%
- 假設 5% 請求異常，會讓處理的 thread 卡住
- 假設 deadline 剩下 100 sec (1000x)，所以如果 thread 接到異常請求，會被卡住 100 sec
- avg throughput < 1000 / avg latency
- avg latency = 5% * 100s + 95% * 100ms = 5.095s
- avg throughtput < 1000 / 5.095 = 196 QPS
- 超過 80.4% 的請求收到錯誤
- **deadline 的設定不可太保守** ; 不要與正常回應時間差距太大
- 若已確定無法完成請求，fail fast!

## 慢啟動與冷快取
- 慢啟動範例
- 建立連線 pool
- 虛擬機 Runtime 優化 (Java)
- 冷快取情境
- 新增伺服器
- 重啟伺服器
- 快取的種類
- Latency Cache 只是用來降低延遲, nice to have
- Capacity Cache 用來撐住流量, must have, 如果倒掉 DB 會跟著倒
- 如果服務極度依賴快取，請考慮
- 採用避免過載的技巧
- 不要瞬間放流量進來

## 永遠往後呼叫，不要在同一層中互相呼叫
- 避免分散式死鎖
- 避免在高負載時候加重負擔
- 讓前端能獲得後端負載資訊
- 簡化依賴關係，有利於部署與調整

## 連鎖故障的觸發時機
- 換版
- 計劃性停機
- 自然增長
- 只要是「異動、改變」就有可能觸發連鎖故障

## 針對連鎖故障的測試方式
### 目的
- 了解整體系統的崩潰臨界點？崩潰的鎮狀
- 崩潰下的反應：是否能成功降級？回覆的臨界點？資料寫入是否錯亂？
### 壓測
- 突然流量與漸進增長的流量都要測試

### 故障測試
- 隨機關掉伺服器
- 有信心的話，在正式環境實施小規模故障測試

### 了解大客戶的請求方式
### 確保不會被非關鍵性的下游服務影響
- 例如搜尋時的拼音校正: 非關鍵性服務
- 不能因為被關鍵性服務出問題導致重要的關鍵服務出問題

## 連鎖故障的立即處置
- 增加運算資源 (有時候會無效)
- 暫時停用 health check
- 正常狀況的 health check 在連鎖故障時可能會過度嚴苛
- 分辨兩種 health check
- 重啟伺服器
- 在這些情況有用：GC 死亡循環、資源被一些沒有 deadline 的請求佔用、被 deadlock 鎖死

- 但要注意，重啟過程會加重其他伺服器的負擔，可能引發另一波連鎖故障
- 捨棄流量
- 大絕招，也許只能治標
- 若根本問題沒解決，只能治標
- 進入降級
- 停用批次作業
- 阻擋造成問題的請求

## AWS 案例
https://aws.amazon.com/tw/message/680342/

## 結論
- 事先了解臨界點、系統在連鎖故障時的症狀、哪些服務可能是問題根源
- 預防：快速失敗、限流、降級方案、適當的 deadline、容量規劃

# 第二十五章數據處理流水線 - Rick Hwang

## agenda
- 管線設計模式的起源
- 簡單管線設計模式與大數據
- 週期性管線模式的挑戰
- 工作分發不均造成的問題
- 分散式環境中週期性資料管線的缺點
- Google Workflow 簡介

## 管線模式的起源
- input > prorgram > output
- coroutine 程式 (可中斷的協程)
- DTSS 通訊
- UNIX pipeline
- ETL: 資料清洗
- 91app 使用：xplenty 第三方服務
- BigData

## 週期性管線模式的挑戰
- 條件
- 要有足夠的執行容量
- 確保程式之間處理的能力一致
- 實作
- MapReduce & Flume
- 週期性實作管線模式其實很脆弱
- 相關問題：
- 任務執行預期
- 資源耗盡
- 任務的依賴性
- 分塊卡住，影響整個系統
- 要調教後才會穩定：
- 工作串流
- 執行週期
- 分塊處理技術

## 工作分配不均造成的問題
- 大數據的關鍵思維：尷尬平行演算法
- 把巨大的工作，切割可裝載在機器的小區塊
- 要注意區塊的資源分配
- K8S, container
- 卡住的工作分塊
- 資源分配不足＆過量
- 資料流操作困難

## 分散式環境中，週期性資料管線的缺點
- 這些工作的特點
- 低優先
- 高延遲
- 降低成本
- 最大化機器負載
- 造成的問題
- 新的工作累積在調度器上
- 為了加速執行，正在跑或快結束的工作可能被終止
- 解決方案
- 提供足夠的服務容量
- 計算需要的資源與取得的依賴

## 監控 週期性管線問題
- 驚群效應
- 類似雙11搶購
- 每次執行，可能啟動數千個工作流程
- 執行實體過載
- 分散式叢集過載
- 網路基礎設施過載
- 摩爾負載模式
- 兩個以上的管線任務執行
- 共享資源消耗問題

## Workflow as MVC pattern
- model: 主作業處理程序
- view: 工作流程
- controller: 輔助活動

## workflow 的執行階段
- 把工作流程拆分更小的任務組
- 可以對小區塊資料操作
- 任意階段輕易的實現對應 重組 排序 分割 合併
- 工作流程可以有多個平行實現
- 工作的流程可以自我調度，選擇不同類型工作執行

## 保障業務的持續性
- 可靠度：光纖被切斷 天氣狀況 連鎖故障
- 可以透過 Spanner 儲存日誌，利用其 Global 特性 (賣藥)

## Solutions
- K8S jobs
- GCP Dataflow

## 小結
- 週期性的管線資料很有價值
- 資料本身是持續性、自然成長，就不要採用週期性設計，而是利用 Workflow 特性設計

## Questions
- 大家的系統有類似 Pipeline 的 task ?
- 這些 task 的每個程序可以單獨執行？
- Pipeline Input / Output 資料放哪？