Release It! 2/e 讀後心得
除了滿足功能需求外,軟體設計階段你會額外考慮那些面項呢?
- 執行效率
- 記憶體使用量
- concurrency
- 可測性
- …
對多數人來說,即使沒有要求,也會避免使用「顯然」沒效率或浪費空間的演算法或資料結構。例如需要排序時不會用 O(N²) 的 bubble sort,需要用 key 查詢資料時會優先想到 hash table。而時間和空間的效率分析也是面試時常問的問題。
再來,設計上可能會考慮 concurrency 問題,因為隨經驗累積,知道 concurency 很難作對且出錯後很難察覺。因此,面試時可能也會問如何正確的使用 lock或是架構上如何避開 concurrency 出錯的機會。開發時甚至會使用 Go、Rust 這類有考慮 concurrency 的程式語言。
有些人可能會在設計時額外考慮如何測式程式、如何用最小風險的方式更新程式。這些都是隨經驗累積,行有餘力後才能在設計階段考慮的事。經驗不足時,只好等發現錯誤才補救,此時得付出更高的成本。另一種經驗不足的結果是作過多的早期最佳化,增加不必要的複雜度和拖慢開發時間。
因此,隨著經驗的累積,會希望在同樣的開發時間下,善用累積的經驗多考慮每個階段「顯然」需要注意的事。這些事還包含:
- 如何提早測出上線後會遇到的問題
- 如何部署上線程式
- 如何管理上線程式
現今流行的 continuous integration 和 continuous deployment 就是針對部署而作的 best practice。
綜合來說,本書主要在講產品上線前和上線後該作的事。內容滿雜的,個案分析很有趣,後面摘錄部份內容說明要考慮的面向。以此為契機留意這些主題,日後才有機會改善。
責任區分
設計系統的架構受制於產生這些設計的組織的溝通結構。
要小心此點的影響,例如將 DevOps 切成不同團隊後,會造成系統之間多一層介面讓開發團隊和 DevOps 對接。若開發團隊自行處理 DevOps,可以減少不必要的介面,降低系統複雜性。
作者覺得 DevOps 改叫 platform team 比較適合。DevOps team 該作的是開發工具和提供知識,讓各 app 團隊用他們的 know-how 作 deployment 和 operation。這和 Google 的 testing team 一樣,目的是作測試工具和散播知識。寫測試是 app 團隊成員的責任。只有這樣才能作好服務。
每個開發者都該在設計時考慮 product → development → quality assurance → deployment → operation,減少事後補救。
題外話,作者認為:
Microservices are techinological solution to an organizational problem.
因此,某個團隊想更新服務時,作好相容性處理,不用受其它團隊時程影響。滿有趣的觀點。
產品面的分析 (Control Panel)
整個系統透明度愈高,愈易維護。建立一個 control panel 有助於了解全貌,串起各個服務的狀況。
最重要的兩個問題:
- 客戶是否高興?
- 產品是否賺到符合預期的錢?
由此出發規劃各個子系統該提供什麼資訊,control panel 要怎麼串起各別的資訊,以便一眼看出這兩個問題的答案。
作者說這屬於 application performance management,並列舉一些相關服務:
- New Relic
- Datadog
- AppDynamics
要監控的東西太多了,要練習思考 “economic value more than technical availability”,習慣後會更容易決定要監控的內容。
Development
穩定的系統需要 steady state,因此要用各種方法避免單一模組的服務量超載,還有避免局部錯誤擴散到整個系統。
確保 請求/占用資源 不會超載
- shed load:超載時直接拒絕上游的 request,讓 load balancer 知道找別人。不能假設上游 producer 不會傳送超載的 requests。
- 用 circut breaker 保護下游服務,大概如下圖所示。使用 circuit breaker 減輕 consumer 的壓力。Fail fast 比 slow timeout 好。有需要可以用成熟的實作,例如 Netflix 的 Hystrix。
- shed load 用來保護服務之間 (end-to-end),服務內部 message queue 滿載時,也可以藉由 block request 產生 back pressure,以阻止 producer 產生更多 request。
- 凡是有產生資料的地方都要有明確的上限,包含 cache、message queue、logs 等。定好滿載時如何丟棄資料。例如 cache 使用 weak reference 在 OOM 時優先被回收;log rotation 定好每個檔案的 bytes,最多保留最近幾個檔案。
隔離錯誤
不論我們如何小心,難免會有錯誤發生。在避免錯誤發生的同時,也要考慮隔離錯誤,讓它們發生時不會造成系統性的錯誤:
- 借用 bulkheads 的概念,隔離使用的「服務」,避免出錯時擴及全船。例如服務佈到不同 AWS regions / availability zone。bulkheads 還可個別運用在不同資源上 (後述)。
- 隔離使用空間:寫入 logs 到獨立的 partition,即使 logs 不小心寫爆了,只會影響 logs。
- 隔離 CPU 使用:預留一個 thread 服務管理指令,確保 CPU 滿載時仍能下達系統指令。
- 隔離網路頻寬:使用多張網卡連不同網段,特別是管理用的內網,確保外部灌入資料滿載時,不會影響內部頻寬。
Let it crash
- 為了避免 error propogation,另一個選擇是let it crash,預期重開治百病。
- 使用前提是重開到上線服務的時間極短,像是重開 container 符合此前提,但重開 VM 就太久了。還有要確保重開局部服務不會影響整個系統。
- microservices 有助於用 let it crash 處理難以處理的錯誤。
- 我個人滿喜歡重開治百病的解法,可以簡化一些難以處理的錯誤,避免為了處理罕見錯誤而增加別的錯誤。
其它
- 使用 timeout 避免占用資源和 deadlock。
- health checks 要作確實,反映能否真的提供服務,不是「機器還活著」。內容可包含機器 IP 資訊、目前 RPS、各種資源使用量等。可供 load balancer 決策。
- 為方便測試,備好 testing server 提供真實資料的回應,還有 no response、slow response、garbage response 等各種異常回應。
- 和 middleware 拖勾。服務之間用 synchronous/asynchronous 差異很大,盡可能在早期設計決定。基本上 async 的系統較可靠,但也比較難開發。
- 完全自動化的壞處是出錯時會瞬間大爆炸。要適時地引入人為監控。比方說作 gradual rollout 可以先下指令自動更新一小批。觀察服務正常後再逐漸更新更大批機器。
- 要正確地實作高效能和可靠的 connection pool 比我們想得難多了,因此使用廣為人知的成熟實作,不要自己作。同樣的,producer/consumer queue 也該使用別人成熟的實作。
以 session 為例,分析設計考量
- 盡可能不要存資料在 session 裡。
- 確保記憶體不足時會優先刪除 session data,例如在 Java 用 weak reference 保留 session data。
- 更進一步是將 session data 移到程式外,使用 Redis 這類的服務。Redis 可同時作為 in-memory cache 和 persistent storage。
小結
設計時要考慮:
- 限制每個子系統能處理的上限,同時不要對下游發出無限的請求。
- 子系統內部針對重要的功能,將 CPU / disk / memory 隔離使用。
- 子系統之間針對重要的功能,將網路隔離使用。
- 子系統之間過載時快速拒絕請求。
- 子系統出錯時能快速重開,避免擴散。
非同步系統是克服各種 stability antipatterns 的好方法。
Quality Assurance
- longevity tests 有助於提早發現上線後才會發現的問題,不需要給予系統重高的負載,但要持續不斷有負載,包含某段時間給序極低的負載,才有機會找出 connection pool 或 firewall timeout 的問題。
- 像是 load balancer 可能會在一段時間沒收到封包後,會丟掉連線相關資訊 (例如 NLB),導致連線失效了,但連線兩端的程式沒有查覺。作者遇到的例子是 firewall 丟掉連線資訊,導致 database connection pool 裡的連線在淩晨時段失效,但是上層程式不知道,操作都卡死。找出原因前,需要固定在離峰時段重啟才能運作。
- end-to-end test 時,盡可能用真實資料,不管量還是種類,提早抓出上線後才會遇到的問題。
- 盡可能快速且頻繁地制造難以處理的錯誤,才能快速修正。Netflix 的 Chaos Monkey 是個好例子。在不拖跨系統的前提下,局部地破壞子系統,有助於提升長期穩定性。
Deployment
Configs
上線用的 configs 要用另外的 repository 管理,確保大家使用同一份組態,並且能追踪改變。作者提及他曾加入一個上線延遲一年的 300+ 人團隊,加入後第一件事就是和各組負責人問清楚他們用的設定,然後收集到一個 repository。不然無法想像服務要如何上線。
使用 Container
使用 container 有許多好處,確保 app 由一個明確的 image 開始擴增,然後保持不變。日後需要作新功能時,再重建一個 image,確保掌握變化。
https://12factor.net/ 提供 app 和 app 管理者之間的責任分界,說明 app 該作什麼。例如:
- logs 寫到 stdout 由 process/container 的管理程式處理。意即 log rotations 由 operation 管理,而非 process 本身。
- 由管理程式處理程式重啟、回收 exit code 等事,不要作 daemontize 和寫入 damon PID 到檔案。
- 同一個 app 有不同部署時,從環境變數讀入變化的部份。
12factor 似乎沒有特別強調用 container,不過用 container 可以少作一些事,例如使用 docker logging driver 將 logs 導到不同服務。
使用 container 後,部署的主要的困難是:
- container 之間的網路組態。
- 讓每種服務有足夠的資源可用,也就是分配 container 執行的服務和所在的主機。
Kubernetes, Mesos, Docker Swarm 等服務就是用來克服上述兩大困難。服務太多不易管理時,可考慮使用。
CI、CD
這大家都在談,不需多說。
Data migration
簡單的作法是跑一次性的 schema migration + data migration 再重啟服務,但這樣 downtime 會拉長。實務的作法是 app 讀取舊資料時,順手作 migration。全作完再移掉 migration code。
即使是 SQL-based database 也可以這麼作,比較安全且通用的作法是對 table T 開新的 table T2,將資料由 T1 轉到 T2。轉移過程中可能仍有 app 寫入 T,此時可透過設定 trigger 自動將寫入 T 的資料轉到 T2。
Operation
- 發生意外時,第一優先是回復服務減少損失,其次才是找出出錯原因。全部 thread 的 backtrace 是除錯的好資料,事先要備好這個機制在重啟服務前自動留下此資訊。
- 一般來說希望透過 kill & restart 的方式快速重啟子系統,可以自動修正。避免要 restart the world 才能更新修正。對於不能快速重開的服務,仍需要線上設定的參數,像是 reset circuit breaker、調整 connection pool size 和 timeout、開關功能等。
- 管理者比開發者更常看 logs,內容要寫清楚,盡可能提供 context。比方說 “file not found” 無法告知管理者要怎麼處理,但是 “failed to load config file XXX: file not found” 就清楚許多。盡可能 wrap 底層 error,提供更清楚的 context 回傳給上層,讓上層邏輯能提供更多訊息到 logs 裡。
- logs 和 metrics 不同,要提供最低限度的 metrics 了解系統狀況。包含流量、線上和過去使用人數、資源使用狀況 (disk、memory、connection pool 等)、各個服務的連接點 (integration point) 健康狀況。留意和過去相比異常的變化。
- 將日常服務和需管理權限的功能分成不同程式,避免誤用或安全漏洞。
其它
- HTTP-based 的 load balancer 可用 cookie 作 sticky sesison。TCP-based 可用 source IP 作 sticky session。
- 若有使用 virtual IP,在 failover 時切換 virtual IP 對到的機器,會造成 TCP 傳到一半流水號出錯。因此 app 要假設會發生這種 IO 錯誤並重建連線。
- 收集 logs 的主要服務有付費的 Splunk 和自己架 Elastic Stack。
- OWASP Top 10 是了解常見安全漏洞的好地方。例如不要提供不同的錯誤訊息讓攻擊者找出有提供管理者權限的 API,回應 404 會比 403 安全。還sensitve data 要加密後再存起來。
- 團隊隨時維持效率 100% 不見得是好事,要留一些餘地處理突發狀況。人事上和系統相似,高效率伴隨著降低彈性。
結語
這本書實在太雜了,點了很多問題,有些也沒提供解法。我閱讀的主要目的是擁有正確的觀念 (mindset)。能先處理就處理,即使沒處理到,之後能有系統地記取教訓,下次再提前作好準備。