從應用程式 Inside-Out 出發的 Web 可靠性設計 (台灣軟體工程協會, 高雄師範大學) (20250628)

時間: 2025/06/28 (六)
主辦單位: 台灣軟體工程協會 (TCSE), https://tcse2025.seat.org.tw/
地點: 高雄師範大學 (和平校區)
講題: 從應用程式 Inside-Out 出發的 Web 可靠性設計
錄影: https://youtu.be/qyloAUXVA-o

Transcript

1. 從應用程式 Inside-Out 出發的 Web 可靠性設計 Rick Hwang 2025/06/28
2. • 一、什麼東西的 可靠性？(5m) • 二、Inside-Out 設計概念 (10m) • 三、Capacity Unit (15m) • 四、總結 (5m) Agenda
3. 曾任翔威國際駐 IBM (Mainframe) 資深軟體工程 師、Oplink (IoT) SQA Manager / SDET Lead、 91APP (電商) Operation and Infrastructure Manager / Architect、2021 年獲得 AWS 授予 Community Hero 榮譽稱號。 專注 SaaS / Multi-Tenancy / API 架構設計 、分散 式系統、系統分析與設計 、軟體測試 、AWS … 等 領域。 著有技術部落格 《Complete Think》、個人著作 《SRE 實踐與開發平台指南 》、共同著作《 軟體測 試實務手冊 》、譯著《 分散式系統設計 》。 3 Rick Hwang
4. 一、軟體工程的「可靠性」
5. 系統架構演進 (1/4)：初創 Browser Web Server Database Web Services People
6. 系統架構演進 (2/4)：改善業務需求 Web Server (Dynamic) Database Web Services Web Server (Static) Batch Job (Consumer) Browser People Load Balancer 靜態與動態資料分離，透過 LB 做路由配置 批次作業
7. 系統架構演進 (3/4)：提升效能 Web Server (Dynamic) Database Web Services Web Server (Static) Cache Queue Browser People Batch Job (Consumer) Load Balancer 提升效能：增加 Queue 降低 DB 附載 提升效能：新增快取；增加 Queue 降低 DB 附載
8. 系統架構演進 (4/4) ：利用內外部資源 Web Server (Dynamic) Database Web Services Web Server (Static) Batch Job (Consumer) Cache Queue Browser People Load Balancer Internal Services Member Service Catalog Service External Services Notification (Email / SMS) Payment depends X Service N Service depends 同一家公司，不同部門 不同公司的 SaaS 服務
9. 什麼的「可靠性」？ Browser Web Service 我很可靠? 我很可靠？ 服務可靠幾個九？ People Internal Depends 我很可靠? External Depends 我很可靠?
10. 可靠性工程 (Reliability Engineering) 依據 Practical Reliability Engineering 一書的定義： The probability that an item will perform a required function without failure under stated conditions for a statd period of time. (一個功能在規定的條件與時間 內，運行需要的功能，而不發 生故障的機率。 ) 這段話有兩個關鍵因子： 1) 條件解釋成系統運行環境； 2) 時間之內的成功機率。 要達到可靠性背後隱含必要的捨棄個別功能，使得特定功能持 續運行。 定義「可靠性」
11. 二、Inside-Out 設計理念
12. Web Service Internal Services External Services depends depends Inside-Out or Outside-in Client (Browser, Mobile)
13. Web Service Internal Services External Services depends depends Outside-In • 單位？by TPS, RPS • 多少費用與價 值？ BlackBox Outside-Out ( 從外到裡) Client (Browser, Mobile)
14. Client (Browser, Mobile) Web Service Internal Services External Services depends depends Inside-Out 我肚子有多大 → 同時可以做多少事 情 → 這些是要投入多少資源？成 本？ BlackBox Inside-Out ( 從裡到外)
15. Client (Browser, Mobile) Web Service Internal Services External Services depends depends Inside-Out BlackBox BlackBox Inside-Out ( 從裡到外) Inside-Out
16. Client (Browser, Mobile) Web Service Internal Services External Services depends depends Outside-In Inside-Out • 單位？by TPS, RPS • 多少費用與價 值？ 我肚子有多大 → 同時可以做多少事 情 → 這些是要投入多少資源？成 本？ 定義 Inside-Out / Outside-in
17. 生活中的 Inside-Out / Outside-in 以台電計價而言： • 對使用者而言：用多少，收多少錢，隨選 (On-Deamand) → Outside-in • 對台電而言： 每度的發電成本是多少？ → Inside-out 公有雲的概念： • 把 IT 資源 (運算、Storage、I/O) 都有計價單位，像是 VM 4c8g 每分鐘一個 計價單位。 → Inside-out 應該要像水、電、瓦斯 … 等「容易計算」的概念。
18. 發想：AWS DynamoDB - RCU / WCU
19. AWS DynamoDB: RCU / WCU Source:Quotas in Amazon DynamoDB Source: DynamoDB provisioned capacity mode 非廣告，而是從好產品中學習概念。
20. 一個 Compute Unit，例如 4core8GiB，可以提供「多少 產能」？對於軟體開發團 隊而言，怎麼從自身成本 (由內而外)，反推可以貢獻的業務價 值？ 反過來講：這套系統 (4core8GiB) 成本每個月支出成本是 3 萬，卻能帶來 30 萬 的營收。 核心問題 (QBQ, Questions behind the Question)
21. • 核心概念：找出由 內而外視角，可以提供的「生 產力」的「單位資源」 • 展開「單位資源」的目的與想法 • 提供「最佳化 (Optimization)」基礎條件 摘要
22. 三、Capacity Unit
23. 以處理檔案加解密為例 目標規格： 1. 支援處理檔案最大 500 MiB 2. 系統整體可以乘載至少 100 RPS (Request Per Second) 3. 每個請求處理加解密的時間需要小於 30 秒
24. 實作技術： 1. RESTful API Server 2. Java - SpringBoot 3. Runtime 只有一個行程 (Process) 4. 沒有依賴其他像資料庫或者外部元件 任務 1. 提供 RESTful API，透過 MultiPart 的 方式接收檔案。 2. 把收到的檔案放到記憶體或磁碟暫存 3. Handler 負責處理加解密工作 實作摘要 註：方便解 說，省略細節。 Client Application (Springboot) Storage Handler File API
25. 結果摘要： 1. 測試固定的檔案大小，連續測 10 秒鐘，也就是 10 次 2. 同時的 Client 數量，也就是圖中的 RPS 3. 結果為 成功數 / 請求總數 實測一：預設系統參數 Filesize \ RPS 100 50 20 10 100 MiB 854/1000 421/500 163/200 97/100 200 MiB Server OOM Server OOM Server OOM 81/100 500 MiB Server OOM Server OOM Server OOM 38/100
26. 1. 調整 JVM HeapSize：明確指定 HeapSize 為 4 GiB 大小 2. 調整同時處理的能力：調整 MultiPart 設定，包含單個檔案最大大小 (max-file-size)、整個請求最大大小 (max-request-size)、提高緩衝閾值 (file-size-threshold) 3. 改用高效能的 Application Server：把 tomcat 換 undertow 這個以 NIO 為基礎的高效能 App Server 實測二：調整系統參數 Filesize / RPS 1 2 5 10 20 1 MiB 10/10 16/20 36/50 70/100 164/200 10 MiB 10/10 15/20 33/50 85/100 174/200 20 MiB 10/10 19/20 49/50 98/100 190/200 50 MiB 10/10 16/20 49/50 98/100 198/200 100 MiB 10/10 19/20 49/50 60/100 70/200 200 MiB 10/10 20/20 23/50 31/100 31/200 500 MiB 9/10 6/20 7/50 9/100 14/200 註：背後有個 Thread-Blocking 問題， 但這不是關鍵瓶頸
27. Recap: 目標規格 1. 支援處理檔案 最大 500 MiB 2. 系統整體可以乘載 至少 100 RPS (Request Per Second) 3. 每個請求處理加解密的時間需要 小於 30 秒 提示：找出由 內而外視角，可以提供的「生 產力」的「單位資源」
28. RPS: Request Per Second (每秒請求數 ) RPS=1: 每秒固定送一個大小 500MiB 的檔案，真實的狀況大概長怎樣？ 重新思考： RPS=1
29. RPS: Request Per Second (每秒請求數 ) RPS=1: RESTful API 通常處理的時間 : 200ms ~ 500ms 重新思考： RPS=1 (RESTful API)
30. 系統設定： 1. HeapSize 為 4GiB 探索情境： 1. 每秒送出一個 1GiB 檔案 2. 連續送十秒 (十次) 結果： 1. 三個成功，七個失敗 2. 每個請求處理的時間 8,000ms ~ 10,000ms 3. 如果把時間延長，繼續送 的請求，幾乎都會失敗， 因為同時間只能處理三 個 (OOM) 探索極限： FileSize=1GiB ( RPS=1 )
31. 系統設定： 1. HeapSize 增加為 8GiB 探索情境： 1. 每秒送出一個 1GiB 檔案 2. 連續送十秒 (十次) 結果： 1. 有七個成功，三個失敗 2. 每個請求處理的時間 8,000ms ~ 10,000ms 小結： HeapSize 8GiB 可以放 進去 7 個 1GiB 大小檔 案，因而 OOM 探索極限： FileSize=1GiB ( RPS=1 )
32. 結論：做不到 或者是 要花很多錢 目標規格： 1. 支援處理檔案 最大 500 MiB 2. 系統整體可以乘載 至少 100 RPS (Request Per Second) 3. 每個請求處理加解密的時間需要 小於 30 秒 系統有物理極限 (8GiB 只能處理 7 個)，無法滿足產品規格的目標，帶來的邊際效應 是系統不具備可靠性 (RPS=1 就可以讓系統 OOM)，而且付出成本不高。 唯一能做的，為了應付極端情境，就是 無限制地加大資源 ，只能用軍備競賽的方式，滿 足未知的需求。但如果打的是 RPS=100 連續打 一天？一天後系統還活著？一個月後的帳 單？
33. 回顧產品規格，斯考「可靠設計」必要的原則： 在限定的資源 內，保證每個被接受的請求，都 可以正確的被完整、順利地執行 先忽略目標 RPS=N 這個需求，而是先針對 每個請 求設計： 1) 請求如果能被接受 2) 請求被接受後 能保證、順利被完成執行 這兩點才是整個系統可靠的關鍵設計。 重新思考可靠性
34. 生活中可靠性最常見的例子就是： 便利商店的櫃檯數量與排隊人流。 • 櫃檯數量就是同時能結帳數量的上限，代表同時能夠接受 的請求數； • 而每一個櫃檯的目的是結帳，包含完成收款、扣款、開發票 等流程，這個流程必須被完成，交易才算成功。 如果不管理結帳人數，讓很多人去跟櫃檯結帳，就前面的例子， 每秒一個人去跟櫃檯結帳，但是不見得每個結帳都能 夠順利被 完成，那麼這個結帳本身是不可靠的。 生活中的可靠性 Generated by ChatGPT
35. 調整假設的產品規格 修正後，調整如下： 1. 支援處理檔案最大 1000 MiB 2. 系統整體可以同時處理 1MiB 檔案 Ｎ 個請求 ，1GiB 同時 Ｘ 個，被接受的請求成功率為 100% a. 超過 Q 同時處理上限時，也就是不被接受 的請求，則回傳 HTTP 429 (Too Many Request)，Client 透過 retry with exponential-backoff. 3. 每個請求處理加解密的時間需要 小於 30 秒 第一版的目標與規格 1. 支援處理檔案最大 500MiB 2. 系統整體可以乘載至少 100 RPS (Request Per Second) 3. 每個請求處理加解密的時間需要 小於 30 秒 新舊規格的差異，有以下兩點： 1. 把單位 RPS 換成同時處理，而且明確定義檔案大小與同時處理的比例。 2. 明確定義超過同時處理的上限時，必續告訴使用者目前系統已經滿載
36. 定義 Capacity Unit 1. 每個 Compute Unit 以 4GiB HeapSize 為基礎 2. 用同時能處理 1 MiB 的數量當基數，實測數字同時可以成功處理 40~45 個，取整數 40 當基數 3. 用同時能處理 1GiB 的數量當上限，實測數字約 2~3 個，用 3 當基數 用 40 當作基數，換算每個檔案大小處理時需要耗損的 單位數
37. 定義 Capacity Unit ( 實測數據) FileSize Concurrent 倒數 Capacity Unit 1 MiB 40 40 / 40 1.0 10 MiB 40 40 / 40 1.0 20 MiB 35 40 / 35 1.1 50 MiB 30 40 / 30 1.3 100 MiB 20 40 / 20 2.0 200 MiB 15 40 / 15 2.7 500 MiB 5 40 / 5 8.0 1000 MiB 3 40 / 3 13.3
38. 實作 Capacity Unit: Consumd Unit • 計算請求的 Consumed Unit (消耗單位 )、Remaining Unit (剩下單位 )、Resumed Unit (恢復單 位) • 透過 Lock 實作，讓 Application 收到請求時，依照檔案大小區間找到對應的 Capacity Unit • Capacity Unit 的 Interface 如下： 我們把這個實作放到系統裡，用亂數模擬方式驗證這個設計符合預期。 public interface ICapacityUnit { int DEFAULT_MAX_CAPACITY_UNIT = 40; // HeapSize=4096MiB int remaining(); void consume(int value) throws CapacityInsufficientException; void resume(int value) throws CapacityResumingException; }
39. 看成果：再次實測 RPS=1 No Timestamp Consumed (Q) Before After Accepted ProcessTime (Z, ms) 0 2025-01-09T17:06:39.351+08:00 0 40 40 True 0 1 2025-01-09T17:06:40.351+08:00 6 40 34 True 5,016 2 2025-01-09T17:06:41.379+08:00 2 34 32 True 3,823 3 2025-01-09T17:06:42.392+08:00 5 32 27 True 13,535 4 2025-01-09T17:06:43.407+08:00 7 27 20 True 11,574 5 2025-01-09T17:06:44.428+08:00 9 20 11 True 128 6 2025-01-09T17:06:45.441+08:00 3 28 25 True 7,247 7 2025-01-09T17:06:46.457+08:00 7 25 18 True 3,716 8 2025-01-09T17:06:47.477+08:00 7 18 11 True 10,090 9 2025-01-09T17:06:48.496+08:00 4 11 7 True 14,522 10 2025-01-09T17:06:49.512+08:00 8 7 7 False N/A 11 2025-01-09T17:06:50.528+08:00 8 14 6 True 337 12 2025-01-09T17:06:51.543+08:00 6 14 8 True 16,109 13 2025-01-09T17:06:52.558+08:00 4 8 4 True 17,187 14 2025-01-09T17:06:53.575+08:00 13 7 7 False N/A 15 2025-01-09T17:06:54.590+08:00 1 7 6 True 14,063 每次檢查邏輯 (psuedo)： 結果： • 第 10 和 14 個請求是失 敗的，因為當下 Capacity 已經不夠，所 以這兩個請求被拒 絕。 • 第 11 個請求因為剛好第 7 個請求已經釋放 7 個 Capacity Unit，所以可以 請求 11 是被接受的。 if (Before > Q); than: After = Before - Q
40. Capacity Comsumed (Grafana)
41. https://codeberg.org/hjacobs/kube-ops-view Kube-ops-view 俄羅斯方塊
42. 總結
43. 兩個面向 業務面向 • 做生意：成本 / 價錢 (cost / price) • SaaS：軟體即服務，收費單位是什 麼？合約怎麼簽？把這些問題丟 給 AI ◦ OpenAI: Token • Capacity Unit：定義計價單位 工程面向 • Unix 哲學：只做一件事，將其做至極 致。 • 一堆小而美的東西放在一起的結果， 形成一個相對穩定的狀態。 • 高內聚、低耦合 • 提供可靠度的關鍵因子與成本結構
44. 個人觀點：核心想法與思路
45. 一個 Unit 成本 (cost) 多少？ 可以貢獻多少 收入 (price - cost)？
46. 從應用程式 Inside-Out 出發的 Web 可靠性設計 Rick Hwang 2025/06/28