歡迎光臨
每天分享高質量文章

AWS 雲上混沌工程實踐之啟動篇

亞馬遜 AWS 官方博客開通了混沌工程專欄,此為首篇介紹混沌工程的文章。從混沌工程的基本概念出發,對現實中混沌工程實踐的突出困惑做了分析和解答,並以混沌工程的演進時間線為例,詳述了混沌工程社區的發展,不是一蹴而就,而是在實踐中逐步深入對混沌工程的理解:從最初對基礎設施的擾動實驗(Chaos Monkey),發展出整套猴子軍團 Simian Army,為控制實驗的爆炸半徑提出故障註入測試(FIT),再到精細化流量配比以對照區分,直至引入斷路器實現真正的無人值守。
工程師團隊最不願碰到的便是大半夜被電話叫醒,開始緊張地查驗問題,處理故障以及恢復服務。也許就是因為睡前的一個很小的變更,因某種未預料到的場景,引起蝴蝶效應,導致大面積的系統混亂、故障和服務中斷,對客戶的業務造成影響。特別是近幾年,儘管有充分的監控告警和故障處理流程,這樣的新聞在 IT 行業仍時有耳聞。問題的癥結便在於,對投入生產的複雜系統有多少信心。監控告警和故障處理都是事後的響應與被動的應對,那有沒有可能提前發現這些複雜系統的弱點呢?

 

混沌工程 Chaos Engineering

 

在分佈式系統上進行由經驗指導的受控實驗,觀察系統行為併發現系統弱點,以建立對系統在規模增大時因意外條件引發混亂的能力和信心。

 

混沌工程發展簡介

 

2008年8月, Netflix 主要資料庫的故障導致了三天的停機, DVD 租賃業務中斷,多個國家的大量用戶受此影響。之後 Netflix 工程師著手尋找替代架構,併在 2011 年起,逐步將系統遷移到 AWS 上,運行基於微服務的新型分佈式架構。這種架構消除了單點故障,但也引入了新的複雜性型別,需要更加可靠和容錯的系統。為此, Netflix 工程師創建了 Chaos Monkey ,會隨機終止在生產環境中運行的 EC2 實體。工程師可以快速瞭解他們正在構建的服務是否健壯,有足夠的彈性,可以容忍計劃外的故障。至此,混沌工程開始興起。
混沌工程演進時間線
圖中展示了混沌工程從 2010 年演進發展的時間線:
  • 2010 年 Netflix 內部開發了 AWS 雲上隨機終止 EC2 實體的混沌實驗工具:Chaos Monkey

  • 2011 年 Netflix 釋出了其猴子軍團工具集:Simian Army

  • 2012 年 Netflix 向社區開源由 Java 構建 Simian Army,其中包括 Chaos Monkey V1 版本

  • 2014 年 Netflix 開始正式公開招聘 Chaos Engineer

  • 2014 年 Netflix 提出了故障註入測試(FIT),利用微服務架構的特性,控制混沌實驗的爆炸半徑

  • 2015 年 Netflix 釋出 Chaos Kong ,模擬 AWS 區域(Region)中斷的場景

  • 2015 年 Netflix 和社區正式提出混沌工程的指導思想 —— Principles of Chaos Engineering

  • 2016 年 Kolton Andrus(前 Netflix 和 Amazon Chaos Engineer )創立了 Gremlin ,正式將混沌實驗工具商用化

  • 2017 年 Netflix 開源 Chaos Monkey 由 Golang 重構的 V2 版本,必須集成 CD 工具 Spinnaker 來使用

  • 2017 年 Netflix 釋出 ChAP (混沌實驗自動平臺),可視為應用故障註入測試(FIT)的加強版

  • 2017 年 由Netflix 前混沌工程師撰寫的新書“混沌工程”在網上出版

  • 2017 年 Russell Miles 創立了 ChaosIQ 公司,並開源了 chaostoolkit 混沌實驗框架

今天,許多公司包括 FANG,都有自己的 Chaos Engineer ,使用某種形式的混沌工程實驗,來提高現代架構的可靠性。由於混沌工程的目的是給複雜的分佈式系統引入擾動,並觀察系統行為,藉此發現系統弱點。因此,混沌工程實驗中涉及的可行性調研、實驗場景和環境的設計與計劃、工具的選型和配合方式、系統行為的觀測方法、以及找到問題後如何改善系統架構和運維樣式,都需要科學的分析和有經驗的混沌工程專家指導。根據筆者的觀察,多數用戶對混沌工程實踐躊躇不前,總繞不開下麵這幾個問題:
問題 1:混沌工程是不是只適合像 FANG 這樣技術成熟的大公司,擁有複雜的分佈式系統,很強的研發和運維能力?
答:否。混沌工程進行的是探索系統複雜性的開放實驗,目的是改善原有的系統架構和運維樣式,加強業務服務的健壯性。沒有像 FANG 那樣複雜的分佈式系統,一樣需要混沌工程實踐來達到健壯性的目的,只是混沌工程設計實施的複雜性不同、實踐的成熟度不同:技術成熟的大公司,由於其系統的複雜性更大,無法完全理解透徹其上下游紛繁的依賴關係,因此更需要借助混沌工程實踐,並利用自身較強的研發和運維能力,來深入瞭解系統行為以提高穩定性。另外,從資源獲取的角度上看,在雲上實施混沌工程實驗,對其他公司而言,更加便捷有效。
問題 2:混沌工程實驗像 Chaos Monkey 只是殺殺機器而已,運維看看就好了吧?
答:否。回溯混沌工程發展的時間線,業界對混沌工程的理解是逐步深入的。Netflix 開發的 Chaos Monkey 成為了混沌工程的開端,但混沌工程不僅僅是 Chaos Monkey 這樣一個隨機終止 EC2 實體的實驗工具。隨後混沌工程師們發現,終止 EC2 實體只是其中一種實驗場景。因此, Netflix 提出了 Simian Army 猴子軍團工具集,除了 Chaos Monkey 外還包括:
  • Latency Monkey 在 RESTful 客戶端到服務器通信中引入隨機延遲,以模擬服務降級並測量上游服務是否正確響應。

  • Conformity Monkey 在發現不符合最佳實踐的實體時將其關閉。

  • Doctor Monkey 會在每個實體中運行健康檢查,同時也通過其他外部監控指標來檢測不健康的實體。一旦檢測到不健康的實體,將它們從服務中刪除,並且在實體所有者找到問題的原因後終止。

  • Janitor Monkey 搜索未使用的資源並按規則處理,以確保AWS上的環境資源有效避免浪費。

  • Security Monkey 在發現安全違規或漏洞時,如發現未正確配置的AWS安全組,並終止使用該違規安全組的實體。此外,還會確保所有的 SSL 和 DRM 證書有效且無需續訂。

  • 10-18 Monkey (l10n-i18n)針對多個區域和國家的客戶提供服務的實體,檢查有關語言和字符集的配置。

  • Chaos Gorilla 模擬了 AWS 可用區域(AZ)的中斷,以驗證服務是否會自動平衡至可用的 AZ,而無需人工干預,也不會給用戶帶來可見的影響。

使用 Simian Army 進行混沌工程實驗,看起來似乎已經很完美。類似像 Latency Monkey 的引入,由於服務之間的呼叫鏈傳遞,到最後這個小的擾動到底會引發多大的故障,沒有人可以預測。在生產上做這樣不可控的實驗,是很危險的。隨著故障註入測試(FIT)的提出,社區開始關註利用應用架構的特性,特別是微服務架構,來控制實驗的爆炸半徑,比如 Netflix 使用 Zuul 強大的流量檢查和管理功能,將受影響的請求隔離到特定的測試帳戶或特定設備,避免 100% 的混亂。
進一步分析發現, FIT 的執行過程也影響了整個系統的監控指標,即實驗群體與其他非實驗群體的統計指標混合不可分辨:無法確定實驗的進行時間,無法評估其影響是否超過了系統本身的噪音。為了進一步的區分,則需要進行更多更大的實驗,這將有可能給用戶帶來不必要的中斷。因此需要對實驗集群和非實驗群集的流量配比進行精細控制,同時因應無人值守的實驗要求,則引入微服務架構中的斷路器,如其超出預定義的誤差預算,自動結束實驗。這就是為何 Netflix 提出了新的 ChAP(混沌實驗自動平臺)以加強故障註入測試。
綜上所述,混沌工程的發展不是一蹴而就的, Chaos Monkey 是其開端,但社區對混沌工程的理解在逐步深入,從對基礎設施的擾動( EC2 實體隨機終止等),到利用應用網關控制爆炸半徑,再到精細化流量配比以區分影響,直至引入斷路器實現真正的無人值守。混沌工程 9 年來的發展,由淺入深,由基礎設施演進到應用架構,不是單單運維看看就好。
問題 3:混沌工程實驗的概念聽著很吸引人,可是不知道從而下手。有沒有什麼實際可落地的框架和工具呢?
答:筆者有幸參與了混沌工程的革新實踐,總結起來對混沌工程的理解有兩點特別重要:
  • 儘量減少實驗的爆炸半徑(故障註入測試的引入)

  • 為了確保不會破壞生產業務,工程團隊需“精心策劃”混沌工程實驗

混沌實驗不只是測試,而是生成新知識的過程( Chaos Monkey -> Simian Army -> FIT -> ChAP ),混沌工程試驗不僅僅是測試系統的一個案例。另一方面,混沌工程是一種產生新知識的方法。正是因為現代軟體系統往往太複雜,任何人都無法完全理解它們,所以工程師通過混沌工程實驗以揭示系統的更多面。
當然混沌工程實驗有其自身的技術門檻,因此必須專家的指導並配以完善的混沌實驗框架和工具。此為整個系列的首篇,後面筆者會深入探討有關混沌工程實驗中涉及的可行性調研、實驗場景和環境的設計與計劃、工具的選型和配合方式、系統行為的觀測方法、以及找到問題後如何改善系統架構和運維樣式等等問題 – stay tune for next episode!
本文轉載自亞馬遜AWS官方博客,原文鏈接:https://aws.amazon.com/cn/blogs/china/aws-chaos-engineering-start/

已同步到看一看
赞(0)

分享創造快樂