【大規模容器叢集實例】百度打造自家PaaS私有雲，1人也能維運10萬臺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平臺新挑戰：超大規模容器叢集怎麼管？