基于AWS基礎(chǔ)設(shè)施構(gòu)建高可用高可擴(kuò)展的系統(tǒng)

1、 基于AWS基礎(chǔ)設(shè)施構(gòu)建高可用、高可擴(kuò)展的系統(tǒng)瀚思成立于 2014 年，屬于 To B 的安全行業(yè)。我們主要為企業(yè)用戶構(gòu)建基于大數(shù)據(jù)的安全分析平臺，通過大規(guī)模采集企業(yè)的各類安全數(shù)據(jù)，并運(yùn)用各種規(guī)則引擎、機(jī)器學(xué)習(xí)算法，在海量數(shù)據(jù)里挖掘出隱藏的安全問題，最終的目的是構(gòu)建企業(yè)里基于數(shù)據(jù)的安全大腦，用數(shù)據(jù)驅(qū)動安全。本文介紹如何在支持彈性計算的云平臺如 AWS 上構(gòu)建一套高可用性和高可擴(kuò)展性的大數(shù)據(jù)分析平臺。和上期一樣，我也不會介紹安全方面的內(nèi)容，更多的是大數(shù)據(jù)平臺技術(shù)落地上的工程化實踐經(jīng)驗，包括如何設(shè)計，如何規(guī)劃，如何監(jiān)控。其中會拿機(jī)器學(xué)習(xí)算法分析模塊舉例如何設(shè)計高可擴(kuò)展性，但是會弱化機(jī)器學(xué)習(xí)算法本身

2、的特性，優(yōu)化，應(yīng)用場景等方面。后續(xù)的兩個分享會有更多這方面的內(nèi)容。一定有人會問到，為什么要在云平臺上構(gòu)建安全分析平臺。這里有多方面的原因，首先瀚思有在線的安全分析服務(wù)“安全易”。其次，瀚思自己有很多的安全數(shù)據(jù)需要處理，比如全球威脅情報。自己構(gòu)建數(shù)據(jù)中心來支持這樣的運(yùn)算服務(wù)對于初創(chuàng)公司來講，upfront cost 有點(diǎn)高，選用 AWS 這樣的平臺，即開即用，按需付費(fèi)是很合適的模式。也一定有人會問到，那為什么選擇 AWS。瀚思的研發(fā)團(tuán)隊，在創(chuàng)業(yè)之前，從 2011 年開始就在 AWS 上大規(guī)模構(gòu)建在線的安全掃描服務(wù)，算是國內(nèi)最早接觸 AWS 平臺的團(tuán)隊之一。然后，瀚思有全球部署安全分析觸點(diǎn)的需求，

3、AWS 的數(shù)據(jù)中心的全球覆蓋率是最好的。從 Gartner 的 MQ 來看，AWS 也是公有云市場上 leader 中的 leader，遠(yuǎn)超其他競爭對手。這是 Gartner 2017 年公有云市場的 Magic Quadrant，可以看到 AWS 依然遙遙領(lǐng)先。簡單來講，這樣的典型平臺里數(shù)據(jù)的處理流程是：采集 - 存儲 - 分析 - 展現(xiàn)。其中存儲和分析是一個迭代完成的過程，分析的結(jié)果會進(jìn)入存儲，也會再次被用作分析。最終所有的數(shù)據(jù)，無論采集的原始數(shù)據(jù)還是分析加工出來的數(shù)據(jù)，都會通過數(shù)據(jù)可視化的技術(shù)來展現(xiàn)給用戶。采集 - 存儲 - 分析 - 展現(xiàn)，這樣的數(shù)據(jù)流程里，采集、分析、展現(xiàn)一般都分類為

4、應(yīng)用服務(wù)器的范疇，通過特定的代碼邏輯來解決數(shù)據(jù)處理的某一個環(huán)節(jié)。而存儲則很明顯屬于存儲服務(wù)器的范疇，包括傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，以及 NoSQL 數(shù)據(jù)庫，其他的集群存儲等。構(gòu)建大數(shù)據(jù)分析平臺，一般會采用非常多的開源組件，這一點(diǎn)很常見。但是開源組件，一般很少有原生對 SaaS 部署方式的內(nèi)建設(shè)計支持。這樣將大數(shù)據(jù)分析平臺 SaaS 化時，就會遇到很多難點(diǎn)，這里列舉了 4 點(diǎn)。其中多租戶和訪問控制，是基于開源模塊構(gòu)建對客戶的 SaaS 服務(wù)時的常見問題，比如 ELK 框架如何 SaaS 化。針對這兩點(diǎn)，我在去年 AWS Summit 北京站有一個專題分享，有興趣的同學(xué)可以關(guān)注瀚思的公眾號，在去年 9

5、月的公眾號文章里有相關(guān)的內(nèi)容介紹。今天主要討論“高可擴(kuò)展性”和“高可用性”這兩個話題。針對存儲服務(wù)器，這兩點(diǎn)通常用集群 + 數(shù)據(jù)冗余 + 數(shù)據(jù)備份解決，每一類存儲服務(wù)都有比較完整的方案。因此今天主要圍繞應(yīng)用服務(wù)器來談這兩個問題。高可拓展性設(shè)計 首先，我們來談?wù)劯呖蓴U(kuò)展性設(shè)計Auto Scaling Group (ASG) 是 AWS 平臺為高可擴(kuò)展性提供的基礎(chǔ)服務(wù)之一。ASG 可以通過 Group 內(nèi)服務(wù)器平均 CPU 負(fù)載、進(jìn)出帶寬或者應(yīng)用程序自定義的指標(biāo)來控制 Group 內(nèi)服務(wù)器數(shù)量的動態(tài)增長或者削減。比如：當(dāng)集群平均 CPU 負(fù)載超過閾值，ASG 開始基于 AMI 創(chuàng)建更多的 EC2

6、服務(wù)器加入 ASG 來分擔(dān)工作，直到 CPU 平均負(fù)載降到閾值內(nèi)。有了 ASG 為基礎(chǔ)，可以創(chuàng)建出一個充分利用彈性計算平臺特性的高可擴(kuò)展性應(yīng)用服務(wù)器集群。但是從 AMI 隨時創(chuàng)建一個新服務(wù)器加入集群即開始分擔(dān)工作，或者隨時削減一臺服務(wù)器，不影響整體集群的計算任務(wù)，對應(yīng)用服務(wù)器設(shè)計有一個很高的要求：無狀態(tài)。無狀態(tài)（stateless） 這個詞，相信很多人可能聽過。關(guān)于無狀態(tài)的應(yīng)用服務(wù)器設(shè)計要素，這里是我個人經(jīng)驗總結(jié)的兩點(diǎn)：1）單個應(yīng)用服務(wù)器的可更替性，2）應(yīng)用集群里任意服務(wù)器的對等可替換性，其中前者是后者的基礎(chǔ)。接下來分別詳細(xì)解釋。首先是單個應(yīng)用服務(wù)器的可更替性。主要考慮的是集群里某臺服務(wù)器由于

7、某種原因掛掉（比如手抖了一下敲錯腳本），ASG 恢復(fù)一臺服務(wù)器后，可以達(dá)到這臺服務(wù)器被更替前同樣的狀態(tài)。不會由于服務(wù)器的更替，導(dǎo)致新服務(wù)器程序邏輯不一致，數(shù)據(jù)丟失，不可恢復(fù)，應(yīng)用邏輯中斷，集群作為整體的計算狀態(tài)出現(xiàn)錯誤等狀態(tài)。為達(dá)到這種可更替狀態(tài)，主要考慮的是數(shù)據(jù)與應(yīng)用分離，以及妥善處理好當(dāng)前正在執(zhí)行的任務(wù)的狀態(tài)。這頁 slides 細(xì)分了數(shù)據(jù)與應(yīng)用分離的幾個主要考慮方面。數(shù)據(jù)與應(yīng)用分離，也是對無狀態(tài)設(shè)計的最常規(guī)理解。在單個服務(wù)器可更替的基礎(chǔ)上，更進(jìn)一步的無狀態(tài)設(shè)計要求，是集群里的任意服務(wù)器之間的對等可替換性。主要意思是服務(wù)器上的計算任務(wù)可以自動無縫遷移到其他服務(wù)器，不依賴于本機(jī)的上下文或者歷

8、史執(zhí)行狀態(tài)。有了這一層保證，才能在 ASG 根據(jù)策略動態(tài)增加或者削減服務(wù)器數(shù)量時，整個應(yīng)用服務(wù)器集群的工作任務(wù)可以動態(tài)負(fù)載到變化過后的服務(wù)器，實現(xiàn)高可擴(kuò)展性。這里列舉了幾個常見的對等可替換性設(shè)計的制約因素。不同的應(yīng)用服務(wù)器的無狀態(tài)設(shè)計要求與思路是不一樣的。前面列舉的采集、分析、展現(xiàn)三類大數(shù)據(jù)分析平臺相關(guān)的應(yīng)用中，分析應(yīng)用是最難做到無狀態(tài)的，因為他往往涉及數(shù)據(jù)上下文依賴，從而不滿足“對等可替換性”。這里我們以一個無監(jiān)督機(jī)器學(xué)習(xí)算法“時間序列異?！狈治鰹槔?，分析一下這樣一個算法類的分析應(yīng)用服務(wù)集群，如何滿足無狀態(tài)設(shè)計的兩點(diǎn)要求。這個是我們產(chǎn)品的時間序列異常分析算法的執(zhí)行結(jié)果界面的截圖。我們的時間序

9、列異常檢測算法通過無監(jiān)督機(jī)器學(xué)習(xí)的方法，基于歷史數(shù)據(jù)訓(xùn)練找到數(shù)據(jù)指標(biāo)中的異常點(diǎn)，比如圖中的紅點(diǎn)。在這樣一個算法執(zhí)行任務(wù)集群上，可能運(yùn)行有非常多的并行算法分析任務(wù)，這樣一個看起來對數(shù)據(jù)前后關(guān)系有強(qiáng)上下文依賴的算法應(yīng)用集群，如何做到無狀態(tài)設(shè)計呢？無狀態(tài)設(shè)計的主要思路，是將應(yīng)用服務(wù)的主要邏輯分解成多個子任務(wù)或子步驟，直到子任務(wù)可以被整體狀態(tài)遷移。時間序列異常檢測算法的執(zhí)行過程，常規(guī)來講有兩個步驟：第一，通過 ETL 過程梳理待分析的數(shù)據(jù)，得到算法輸入所需的（time，value）形態(tài)的基于時間序列的數(shù)據(jù)流；第二，將分析周期內(nèi)的時間序列數(shù)據(jù)輸入算法邏輯，計算出異常點(diǎn)。因此時間序列異常分析集群的工作，是

10、兩個子步驟的循環(huán)任務(wù)。且一個集群會在同一時刻并行運(yùn)行很多的算法分析任務(wù)。每個算法分析任務(wù)的子任務(wù)，需要能夠動態(tài)的負(fù)載到任一臺服務(wù)器上，分析處理好這兩個子任務(wù)的狀態(tài)遷移，就完成了設(shè)計目標(biāo)。這兩個任務(wù)本身的特性非常類似，我們以數(shù)據(jù) ETL 處理步驟為例進(jìn)行設(shè)計說明。比如我們需要算 1 分鐘步長內(nèi)每筆數(shù)據(jù)里 bytes 字段的 sum 值，即 1 分鐘為單位的數(shù)據(jù)傳輸量。這樣的 ETL 結(jié)果輸入給時間序列異常算法，可以找到數(shù)據(jù)傳輸量這個分析目標(biāo)的異常波動。這里每 1 分鐘的聚合計算就是一個子任務(wù)單元。這個 ETL 子任務(wù)，首先要解決服務(wù)的可更替性。參照前面的設(shè)計考慮點(diǎn)，獲取的數(shù)據(jù)源，輸出的數(shù)據(jù)結(jié)果，

11、應(yīng)該部署在外部的數(shù)據(jù)隊列集群或者存儲集群，做到數(shù)據(jù)與應(yīng)用分離。當(dāng)前算法任務(wù)的 ETL 具體設(shè)置，應(yīng)存儲在策略服務(wù)器，做到配置與應(yīng)用分離。當(dāng)前 ETL 任務(wù)的執(zhí)行狀態(tài)（未啟動，運(yùn)行中，已完成），應(yīng)該標(biāo)記在外部存儲。到此，任何一個 1 分鐘的 ETL 單元，如果計算到一半服務(wù)或者服務(wù)器出錯退出，可以有替代服務(wù)重新完成這個 ETL 單元。第二步是解決對等可替換性，即任何一個算法任務(wù)的任何一次 ETL 步驟單元，可以由集群里任意一臺服務(wù)器完成，實現(xiàn)子任務(wù)的可遷移。首先將 ETL 任務(wù)預(yù)標(biāo)記出來，存儲在外部存儲比如數(shù)據(jù)庫。這個步驟可以由集群里每臺服務(wù)器都嘗試為集群要處理的每個算法任務(wù)標(biāo)記出下一個 ETL

12、 計算任務(wù)，通過算法任務(wù) ID+ 計算起始時間戳為主鍵來保證任務(wù)的唯一性，并將任務(wù)標(biāo)記為 waiting 狀態(tài)。接下來每個服務(wù)器可以競爭任務(wù)列表里的下一個 waiting 任務(wù)，這里可以用類似選舉算法來決定誰取到下一個任務(wù)。一旦決定，即為任務(wù)打上 running 狀態(tài)標(biāo)記及開始時間。這個期間，其他服務(wù)器不會爭取 running 狀態(tài)的任務(wù)，ETL 計算完成則標(biāo)記為 Done 狀態(tài)。計算過程中，一旦服務(wù)器或者應(yīng)用崩潰，或者由于 ASG 主動削減一臺服務(wù)器，導(dǎo)致此服務(wù)器負(fù)責(zé)的任務(wù)未結(jié)束一直是“ongoing”狀態(tài)，在下一輪任務(wù)選舉過程中，需要對所有 ongoing 任務(wù)做超時檢測，一旦超時，則重新

13、標(biāo)記為 waiting 狀態(tài)，重新進(jìn)入選舉列表。通過將子任務(wù)的狀態(tài)外遷到存儲服務(wù)器，以及任務(wù)的選舉分配 + 超時檢查，完成了 ETL 計算任務(wù)在集群內(nèi)的對等可替換性。即任何任務(wù)可以運(yùn)行在任何服務(wù)器上，沒有前序或者后序的狀態(tài)依賴。至此，ETL 計算任務(wù)實現(xiàn)了無狀態(tài)設(shè)計。以此類推的完成算法計算子任務(wù)的無狀態(tài)設(shè)計，這樣任何一個算法任務(wù)的任何一次子任務(wù)，可以運(yùn)行在集群任何一臺服務(wù)器上，則整個時間序列異常算法分析應(yīng)用服務(wù)器實現(xiàn)了無狀態(tài)。接下來可以在 ASG 的控制下，通過集群的平均 CPU 負(fù)載來動態(tài)水平擴(kuò)展或者縮減服務(wù)器數(shù)量，完成了集群的高可擴(kuò)展性。這里舉例的只是一種應(yīng)用場景的設(shè)計思路，并不能解決所有

14、的應(yīng)用服務(wù)器的場景，需要對不同的應(yīng)用邏輯針對性設(shè)計，No Silver Bullet。高可用性設(shè)計 接下來，我們來談?wù)劯呖捎眯栽O(shè)計。一個大型 SaaS 系統(tǒng)的高可用性（High Availability，簡稱 HA）是一個比較復(fù)雜的系統(tǒng)工程，不是一兩個簡單技術(shù)點(diǎn)的應(yīng)用就可以解決，也很難通過十幾分鐘的 Session 來講清楚。我在這里試圖把我從過往經(jīng)驗中看到的各種方法和實踐，通過一定的層次結(jié)構(gòu)整理出來供大家參考。從大的方面來講，決定系統(tǒng)的 HA，主要決定因素有兩個方面：設(shè)計與監(jiān)控。設(shè)計在架構(gòu)與技術(shù)思路上提高系統(tǒng)的 SLA，監(jiān)控在止損思路上防止降低 SLA。這張圖 Highlight 了所有在高

15、可用性設(shè)計中經(jīng)常會被提及的關(guān)鍵詞，非常多也非常離散。不過大家可能會發(fā)現(xiàn)，其中很多關(guān)鍵詞，在剛才我們討論高可擴(kuò)展性的時候都有涉及到。這很正常，因為一個彈性可擴(kuò)展的應(yīng)用集群，其中每臺服務(wù)器都有對等可替換性時，就相當(dāng)于實現(xiàn)了 Active-Active 互備，AA 本身就是一種經(jīng)典的高可用性設(shè)計方案。不過 AA 局限于服務(wù)器與應(yīng)用程序?qū)用?，一個完整的全系統(tǒng)高可用性設(shè)計涉及 5 個層面：基礎(chǔ)設(shè)施、服務(wù)器、應(yīng)用程序、系統(tǒng)服務(wù)、區(qū)域。這里，我們把剛才離散的所有 HA 設(shè)計關(guān)鍵詞，按照這 5 個層面做了一個分類，讓各位在做 HA 設(shè)計時有一個更清晰的結(jié)構(gòu)化考慮思路。接下來我們對每一個主要的設(shè)計要點(diǎn)做詳細(xì)的解

16、釋。后面的 slides 本身就是建議和 best practice 的合集，文字較多，我的附加解釋會稍微少一些。我們在前面介紹高可擴(kuò)展性設(shè)計的服務(wù)可更替性時，已經(jīng)介紹過數(shù)據(jù)與應(yīng)用服務(wù)分離的概念。理想的情況是 SaaS 系統(tǒng)的每一個應(yīng)用角色都沒有單點(diǎn)?，F(xiàn)實情況下，對業(yè)務(wù)連續(xù)性的關(guān)鍵路徑上解決單點(diǎn)基本上就可以。一些非關(guān)鍵路徑，非實時任務(wù)的應(yīng)用，在這一點(diǎn)上可以有妥協(xié)。這里再次 recall 一下無狀態(tài)設(shè)計的兩個方面，這是 HA 和 HS 的核心理念。異地多活是一個非常復(fù)雜和龐大的話題，我們只在一定程度上做了小規(guī)模的嘗試，這里列出的是一些可能的方法和思路。一個超大型的 SaaS 系統(tǒng) + 超高負(fù)荷情

17、況下的異地多活方案遇到的問題要遠(yuǎn)比我這里列出的復(fù)雜。在我們有了五個層面的完備的高可用性設(shè)計，且完全落地后，為什么我們還需要監(jiān)控？理由有很多，最基礎(chǔ)的一個：bug 永遠(yuǎn)有。從我的個人經(jīng)驗來看，監(jiān)控的核心訴求，是“比客戶更早發(fā)現(xiàn)問題”，或者我們通常講的“第一時間發(fā)現(xiàn)問題”。我之前負(fù)責(zé)的一個 SaaS 系統(tǒng)，曾經(jīng)出現(xiàn)過一個 bug：在極端條件下，緩存系統(tǒng)的 sdk 的多線程 bug 被觸發(fā)，導(dǎo)致 A 客戶的配置策略應(yīng)用到 B 客戶的數(shù)據(jù)上。但是我們的系統(tǒng)本身運(yùn)行狀態(tài)一切正常，我們既有的常規(guī)監(jiān)控也一切 OK。但是在系統(tǒng)服務(wù)層級，我們 SaaS 給客戶的服務(wù)邏輯上已經(jīng)是不可用了。由于客戶自己從懷疑到確認(rèn)，從 Level1 技術(shù)支持一直 escalate 到研發(fā)，事情已經(jīng)發(fā)生一星期了，從開始少量客戶被影響，到我們知道時已經(jīng)是全球所有數(shù)據(jù)中心的大規(guī)模災(zāi)難了。事后分析發(fā)現(xiàn)，緩存錯誤出現(xiàn)時，各個系統(tǒng)的日志里的 warning，error log 顯著增加，不過當(dāng)時我們并沒有對系統(tǒng)日志做很好的監(jiān)控。如