基于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ù)的安全分析平臺(tái)，通過大規(guī)模采集企業(yè)的各類安全數(shù)據(jù)，并運(yùn)用各種規(guī)則引擎、機(jī)器學(xué)習(xí)算法，在海量數(shù)據(jù)里挖掘出隱藏的安全問題，最終的目的是構(gòu)建企業(yè)里基于數(shù)據(jù)的安全大腦，用數(shù)據(jù)驅(qū)動(dòng)安全。本文介紹如何在支持彈性計(jì)算的云平臺(tái)如 AWS 上構(gòu)建一套高可用性和高可擴(kuò)展性的大數(shù)據(jù)分析平臺(tái)。和上期一樣，我也不會(huì)介紹安全方面的內(nèi)容，更多的是大數(shù)據(jù)平臺(tái)技術(shù)落地上的工程化實(shí)踐經(jīng)驗(yàn)，包括如何設(shè)計(jì)，如何規(guī)劃，如何監(jiān)控。其中會(huì)拿機(jī)器學(xué)習(xí)算法分析模塊舉例如何設(shè)計(jì)高可擴(kuò)展性，但是會(huì)弱化機(jī)器學(xué)習(xí)算法本身

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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