BOAS架構中最底層的IaaS層,由伺服器、網路、儲存等元件組成,並且利用百度自家開發的Matrix叢集作業系統,可對大規模Container進行調度。(圖片來源/百度)

從搜尋引擎起家的百度,除了原有的搜尋服務,近年更跨足於地圖、行動團購服務糯米,並且經營中國最大社群論壇貼吧。負責建置百度PaaS私有雲平臺的百度資深工程師段兵表示,百度內推出任何一個產品,投入研發人數往往超過100人,每周發布新版本次數超過50次,而維運團隊需要更需要管理超過1,000臺伺服器及100個不同的應用程式。

但他表示,在傳統IT架構下,不僅硬體資源的使用效率低落,而且過去應用程式直接部署於裸機的做法,導致各服務與底層作業系統、函式庫的相依性高。面臨結構越來越複雜,以及規模增加的業務,「如何支撐系統運作,並且進行快速地更新、迭代,是百度所面臨的挑戰。」因此,早在Docker爆紅的2013年之前,百度就開始著手利用Container技術,打造自家PaaS私有雲平臺BOAS(Baidu Open Application Service)。

BOAS五大階段發展

誕生於2012年的BOAS平臺,源自於百度對於PHP地依賴,在2010年時,百度將從過去C語言開發,大量轉為使用PHP開發應用程式。段兵解釋,由於PHP是一種無狀態(Stateless)的腳本語言,除了能快速實作應用程式邏輯外,相比過去使用C語言,一周只能發布10次新版本的速度,使用PHP進行開發的發布次數則大大增加,但是同時,「維運成本同時也大幅增加。」此時,百度便萌生開始利用Container架構內部私有PaaS平臺BOAS的想法。次年,百度則替BOAS平臺進行深度PHP客製化,並且將貼吧的前端業務系統整合至BOAS,「對於BOAS穩定性是相當大的肯定。」

在整合百度貼吧前端系統獲得成功後,2014年百度更大舉將百度錢包、糯米等核心業務整合至BOAS,同時將大部分使用Java開發的Web服務也移轉至BOAS平臺。在這兩年中,貼吧後端系統更一併整合至BOAS中。

然而,為何百度陸續地將核心產品整併至BOAS中?「主要是源自我們對迭代速度提升的要求」,段兵表示,目前BOAS僅需要1名維運人員,就可以管理2萬臺伺服器及超過10萬個Container,除了維運效率提升5倍之多外,「硬體資源使用率總共提升了20%,服務穩定度也超過99.99%。」

沒有BOAS前,開發過程繁複而且緩慢

在過去還沒有BOAS平臺中,在研發團隊拿到需求設定文件後,得開始布建開發環境,並且編寫基礎函式庫以及應用程式碼。在完成開發流程後,開發團隊則將程式碼提交給測試工程師。此時,測試團隊也得要自行建構測試環境。

結束測試階段後,則進入產品發布階段。這階段中,維運團隊得要採購伺服器、建置正式環境,並且負責部署應用程式等繁瑣工作。在服務成功上線後,則會生成許多系統Log資料,維運團隊也得根據營運狀況,進行系統性能分析並產出報告,「過去的流程不僅角色多,過程也複雜,導致研發速度緩慢。」

因此,在導入BOAS後,不僅簡化了流程,也減輕各角色間負責的工作。段兵表示,現今研發團隊拿到需求開發後,只要專注心力在開發程式碼即可,「BOAS會提供開發環境、測試環境。」在完成測試階段後,BOAS則可讓開發者建置正式環境,提供程式碼部署、引進使用者流量等服務。

當產品已經進入正式環境後,BOAS也能提供資料收集服務,讓維運團隊不再需要手動收集系統資料,就能提供系統性能分析、監控警報,並根據這些系統資訊產生維運報告,「這就是BOAS能達到的效果。」段兵表示。

BOAS的三層架構:IaaS、PaaS,以及SaaS

不過,究竟BOAS是何種PaaS平臺?段兵給了一個定義:「可以讓使用者靈活地管理應用程式生命周期,並採開放形式管理的PaaS服務。」他認為,BOAS總共包含三大特色:靈活、明確規範,並且橫跨應用程式的生命周期。第一特色為靈活,使用者可以透過UI介面、API操作BOAS,並且根據不同需求,提供客製化解決方案。

第二,BOAS平臺有訂定明確使用流程,必須符合百度內部的開發模式。像是整併於BOAS的百度貼吧、糯米、百度雲等產品,「我們不是針對各產品提供相異服務,而是使用統一的PaaS平臺。」最後,在應用程式的開發、測試,到上線階段中,都可以透過BOAS執行。

而BOAS的結構,則包含了三大層:底層IaaS、中間層PaaS,及最上層的SaaS。最底層的IaaS層,由伺服器、網路、儲存等元件組成,並且利用百度自家開發的Matrix叢集作業系統,可對大規模Container進行調度。在中間的PaaS層中,則建構了許多模組化服務,包含資源管理、變更發布、流量引入、監控警報、映像檔服務。最上層的SaaS,則是運作了貼吧、糯米、地圖等服務。

百度資深工程師段兵認為,效能對建置私有雲有相當重要的影響,因此「快速啟動、高性能是我們選擇Container的主要原因。」

效能是百度採用容器的首要理由

段兵比較了VM和Container這兩個虛擬化技術間的優缺點。相比於Container,VM的隔離性、資源限制機制都更好,但是運作性能方面,VM約會耗損20%的CPU效能,而Container僅耗損5%,性能直逼裸機。在啟動速度上,Container更是以毫秒為單位計算。他認為,效能對建置私有雲是相當重要的考量因素,「快速啟動、高性能是我們選擇Container的主要原因。」

在決定選用Container作為BOAS底層架構後,管理方式也會與VM相當不同,「IT架構發生極大變化,底層不再是由單機的CPU、網卡、儲存設備構成,而是許多分散式叢集組成。」段兵表示,百度也分別在北京、上海及香港等地設置IDC機房,而使用此些機房為基礎,結合分散式作業系統,將硬體資源整合成統一資源池。

針對單一Container,百度也設計了相關機制,進行資源進行隔離、限制。段兵表示,百度自製的Container引擎也仿效Docker的設計,支援資源限制cgroup,以及PID程序隔離機制,但是在單一容器能取用的資源上,則設計了兩個參數Quota及Limit,前者保障Container使用的硬體資源,後者則定義了資源使用上限。段兵舉例,像是針對單一容器,使用者可就可以限制其儲存參數Quota為4GB,Limit則為6GB,其實際用量可以介在兩者之間。此外,使用者甚至可以設定為-1GB,來降低其優先程度。

除了單一Container設定和優化機制,更關鍵的是在大規模容器調度的設計,百度也做了特別的考量,而BOAS平臺的設計概念總共從四大維度為出發點。第一是離散度,段兵解釋,離散度是釐清運行某服務可分配到的實例(Instance)數目,此舉有利於將服務平均分配在不同機櫃、伺服器中,減低硬體故障對服務造成的影響。第二是服務依賴程度,部署於同一主機中相異服務間的溝通、聯繫。

再者是副本控制,BOAS平臺同時支援水平擴充(Scale-out)以及垂直擴充(Scale-up),前者是控制Container副本的數量,後者則是重新調整Container中Quota、Limit參數的大小,「因為業務剛開始上線營運時,很難評估資源的需求為何。」

為了實現自動化及減少維運成本,百度得讓BOAS具備自動擴充(Auto-scaling)功能,段兵認為,此功能解決的核心問題是「對容量的評估不夠準確」,即便對系統進行監控、分析,也很估算出特定時間內服務所需要的容量為何,「自動彈性伸縮機制就是要解決此問題。」

在建置自動擴充功能時,段兵歸納出數個導入前的評估指標,像是必須事先計算應用程式的CPU利用率、使用者流量,推估未來服務的容量是否足夠。再者,使用者也得計算未來需要擴增多少實例,比較推算結果是否與符合預期數字。此外,每次新增的實例數目都得有所限制,「因為彈性擴充必須設定冷卻時間,即下次進行水平擴充所需的最短時間」,如果實例數量擴張過多也必須進行移除。

然而,除了系統自動動態擴張,針對未來可預期的爆增流量,也必須事先進行準備。段兵舉例,像是中國各大電商促銷日往往來帶爆量人潮,如京東618大型促銷活動、百度糯米517吃貨節,或是阿里巴巴雙11特賣,「可預期這些期間流量會大幅成長,得預先計畫在某些時段進行擴充。」

BOAS平臺提供了服務實例視覺化圖表,可呈現容器實例進行水平擴充後,資源池可調用的總資源也下降的關係。

系統監控帶來維運視覺化、自動化

BOAS平臺掌管了超過10萬個Container ,自然不可能單靠人力手動維護,自動化監控系統也就成為重要功能,「監控的核心價值在於,讓維運工作視覺化、自動化。」段兵解釋,系統資料視覺化讓維運團隊、開發團隊可以觀察某服務在正式環境的運作狀況,並且利用視覺化介面,改變應用程式的狀態,而系統自動水平擴充,不需藉由人力新增伺服器紓解流量。

監控系統得蒐集的資料除CPU、記憶體、硬碟等硬體運作資訊外,也會從業務日誌統計程式碼錯誤、每秒查詢率等數據。在備齊了這些資料後,也得進行資訊整合,所以BOAS可供使用者不同資料尺度進行檢視,大至IDC機房、叢集,小至各服務、實例。

利用這些數據,BOAS系統還能對開發者進行預警,例如,當某應用程式CPU使用率過高,導致伺服器過載時,就必須進行水平擴充,或是發現服務發出HTTP 503、500等錯誤訊息時,就得要重啟服務,或是將服務搬遷至他處。

聚合:App監控

BOAS平臺蒐集系統運作資訊,並透過視覺化方式呈現,例如展示應用程式當前的運作情況,針對狀態異常的服務,維運團隊也可重新啟動。

Container監控

使用者可以利用BOAS平臺的監控系統,觀測Container每段時間記憶體、CPU的使用比例。

建置BOAS平臺三大心得

在建置BOAS過程中,段兵也歸納出3大心得。第一是利用背景程式(Daemon)啟動Container,即便資源管理、部署管理系統皆發生異常,仍然不能影響Container內執行的程序。第二則是技術架構革新對組織帶來的影響,「雲端化是一個技術變革,而技術架構的變化,也等同於組織架構的變化」,必須逐步地革新。

最後是Container共用作業系統核心的特性,使其先天隔離不如VM的弱點。對此,百度也設計一些機制,藉以補強其弱點,像是對每個服務設定SLA,對於每個業務使用資源設定預期值,「一旦超過,可以透過第三方外掛程式進行處理。」段兵表示。

 相關報導  Container平臺新挑戰:超大規模容器叢集怎麼管?


Advertisement

更多 iThome相關內容