雲端運算的基礎設施架構原則

電腦運算資源在傳統的機房時代跟硬體是緊密連結在一起的。我們需要訂出Server的要多少顆實體CPU可能還要指定要幾核心，多少條的RAM每條RAM要多少GB，這台Server可以裝多少個HD，每顆HD要多大。最後我們再把組裝起來，看有多少台Server要上架到機櫃，拉網路線，接Switch，接Router然後安裝、設定作業系統跟相關的Application。最後要畫圖出來指定Application server放哪個Datacenter，哪個樓層，哪個機櫃。還要貼標籤在這台Server等等作業。

但在雲端時代(我們指公有雲，私有雲你還是要負責這一些硬體工作)我們將這些電腦資源與硬體的連接關係切斷(Decouple)。硬體還在機房哪邊，但機房已經不用你管了哪些硬體也有別人幫你管了。我們將注意力從實體的Infra layer轉移到虛擬的Infra layer。這種虛擬的Infra layer上的Object我們可以隨時 create、duplicate、change and destroy，不用再被硬體綁住。

這一種轉變會改變我們在設計/使用電腦資源的思維模式。我們不能再靠著將硬體屬性的思維加入我們的Application/Service的運作。我們必須能夠不用靠著把硬體堆疊在機房的這一類的儀式來加入或移除系統的instance，而且能夠簡單維護系統的一致性與品質，即使在短時間快速擴大系統規模時依然能保持這樣的一致性與品質。

以下我們會介紹幾個在雲端平台中如何設計/實作 Infrastructure的架構原則。這些原則會闡述三個在雲端平台的核心實踐的原因。

核心實踐

• Define everything as code
• Continuously test and deliver
• Build small pieces

我們也會列出幾個IT團隊會因為雲端的特性 — dynamic infrastructure而產生常見陷阱。

原則一: 要假設所有的系統都是不可靠的

在傳統的機房思維中，我們花了大把的銀子買了最貴硬體(一台Server或一組storage可能就可以去買一台BMW 7系列的車子)，所以我們的假設就是這些硬體都是不會壞的(壞了就把廠商就叫來電)。但在雲端時代我們的假設就要改變 — 雲端機房的硬體隨時都會掛掉。

為什麼這麼說呢?因為雲端機房的scales遠比你的機房大很多。一般自有機房實體機器有個幾百台這家公司不是金控集團不然就是很有錢的公司，但雲端機房機器數量可以以千台為單位甚至到萬台。試想雲端機房的機器有可能是買哪種一般商用等級的機器嗎?如果是哪收你的月租費可能會高到你不想用雲端而是自建機房算了。另外機器硬體壞掉的機會以機器數量的scales來看(你可能幾百台，人家幾萬台)，你覺得哪邊每天都會有機器壞掉呢?所以雲端業者對這些硬體的態度就是，偵測到它壞掉然後就換掉它。

傳統機房的作業，有時為了非預期性的原因你需要停機。你需要對系統做 patch and update。 你要 resize系統並重新分配負載作業，有時也要做故障排除的工作。以上這些作業在static infra大都需要停機。但在很多現代企業組織停機意味著公司停止營運賺錢。

所以在雲端平台，你不可以對待Cloud infra像在傳統機房一樣覺得它會一直是穩定的底層，你必需認定你的Application/Service在這些不穩定的硬體中運行時如果底層的resource變動了/掛掉了導致你的Application/Service有問題時該怎麼辦?

原則二:讓每件事都是可被重製的

有一種方式可以讓你的系統是可恢復的，哪就是確保你在重建它時是毫不費力的跟可靠的。

毫不費力是指你連想都不用想怎麼去重建步驟，只要決定要不要執行就好。那些重建的步驟(configuration setting/ software version/ dependencies)都已經事先定義好了。這不只讓回復系統變得很容易，同時還幫助你達成以下事項:

• 由於可以很容易重製整個系統，所以可以讓你的測試環境與正式環境達成一致性。
• 你要在別的region重建系統是可以的，所以就算某個Region都掛了你也可以在別的地方輕易的重建整套性系統
• 當loading變重時你可以隨時增加運算能力
• 複製系統，為每個客戶提供專用的instance

當然，系統會產生你無法預先定義好的資料/內容/log. 所以必須確認這些無法預先定義好的事也在我們的replication strategy。最容易想到的方式可能就是做copy or streaming到backup的地方然後重建系統時再把資料restore回來。關於這一類的問題我們會再後面的篇章中再詳細說明。

這種毫不費力的建立/重建任何infrsatructure的能力是powerful。它排除了我們在做系統變更時的風險與恐懼，讓我們有信心能夠應對系統失敗。原因是你可以很快的提供新的服務跟系統出來。

陷阱 : 雪花式的系統

這是指系統的instance或是系統中的一部分是很難重建的。它也可能是應該與其他環境相似的環境，像是staging environment ，但是團隊無法全盤了解系統的方式有所不同。

人們不會去故意得去建立這種雪花式系統。它們就是這樣自然發生了。你第一次用新工具建立了系統，你可能在建立期間會一直撞牆從中得到你自己的lessons learn。但如果接手你的人或同事是直接依靠你建立的系統，你也許沒有時間根據你的lesson learn回去重建一次或優化系統。假如你沒有一套簡單跟安全的變更機制跟practices，哪優化你所建立的系統是很困難的。

雪花系統的另一個原因是當人們要對系統其中的一個instance(不想影響其他部分)做變更時。他們是經常處於壓力之下要做系統修復的，而這個問題是出現在整個大系統中的一個部分，或者他們想要在測試環境做一個重大的更新測試，但專案時間讓他們沒有辦法這麼做。

所以你現在應該知道會造成上面的所說的雪花系統發生的原因在於上面所講的如果已經是我們系統運作的常態後，哪麼你就對安全的做系統變更或升級是沒有信心的。更嚴重的是，如果系統掛掉還可能很難修好或需要花很多時間修好。這樣就會造成我們會避免去做系統異動（以期不要犯錯），不想把系統升級（於是效能／安全問題都來）。

雪花式系統製造出了風險與浪費團隊管理系統的時間。所以花時間與資源將我們的系統打造成是可重製的系統是值得的。假如你的雪花式系統是不值得你去優化它的，哪老實說這套系統也不值得留著它。

最佳取代雪花式系統的方式式寫一段可以replicate 系統，平行處理運行整套系統所需要的各部分直到系統ready可以開始運行的code。使用自動化測試與pipeline 來驗證它是正確並可被重製的，而且是你可以容易做變更的。

原則三： 製造一次性的事物

建立可以對應動態的Infrastructure的系統是一個level。而建立一個自己本身就是動態系統又是另一個level. 這個動態系統可以讓我們很優雅的 add/remove/start/stop/change與移動系統中的任何一部分。能做到這個程度就會讓系統的運作是彈性、可用性、規模性。 它也可以簡化和降低風險。

讓你的系統變得可延展是Cloud native software的主要觀點。Cloud abstract infrastructure resource(compute, networking, and storage)是從實體硬體產生的。所以Cloud native software的application 的功能性是完全的與infrastructure 解耦的（decouple）。

假如你的系統是動態的，哪麼你使用的工具也要能對應這種動態特性。例如你的監控不會在重建系統的一部分時發出告警。但是如果重建的過程中產生了loop，哪它就必須有告警出現。

原則四：最小化的變動

隨著時間的流逝，你的系統會變得越來越難了解，越來越難變更，越來越難維護它。因為這類個工作是伴隨著系統中的很多部分，還有系統中每個部份有著不同的形態。所以要讓這系統變得好管理就是要把系統中的每個部份的型態固定在只有幾種就好 — to keep variation low. 這將會讓你管理幾百台完全型態的server比管5種完全不同類型的Server還簡單。

我們把原則二的拿來跟這個原則做互補。假如你定義一個簡單的component並且依據這個create很多個完全相同的instances，之後你就可以很容易了解，變更，修復這一個有著相同類型的instance.

要讓這樣的作業是可以work的，我們必需在apply任何變更要一起對所有同的compoeent做出變更。不然就會產生 configuration drift的狀況。以下在你你的系統中可能有著這些的型態的變動

• Multiple operation systems, application runtime, databases, 等等。每一種都需要你的團隊有相關技能的技能與知識。
• 軟體有多種版本，像是 operating system or database。即使你只使用一種作業系統，但它可能有好幾個版本。每個版本需要的configuration 跟tooling也可能不太一樣。
• 不同版本的package. 當Server有新版本的package, utility, library相較與其它的事，這些會讓你的系統有風險。你原來使用的command可能沒辦法使用在這些新版本上，或是舊版本有弱點或bug.

公司之間的每一個團隊對於要選擇甚麼樣的技術跟解決方案可能存在著緊張關係，因為每個團隊可能是針對自己的需求來看，相對的讓總量變動保持在組織可以管理量能之內才是重要的。

Configuration Drift

這是指曾經完全相同的系統之間隨時間推移而發生的變化。如下圖所示，手動針對特定的instance做了一些臨時性系統變更就會造成configuration draft，即使你使用的是自動化工作也有可能會變成這個樣子。而configuration drift特別會讓維護自動化管理的工具更難維持一致性。

為何Infrastructure會隨著時間的推移而發生分歧呢?底下讓我們看一個不存在的團隊 DevOpsBest 的故事。

DevOpsBest 團隊為每個電子商務的商店運行一個單獨的Application instance，每個instance都配置為使用自定義品牌和產品目錄內容。在初期時， DevOpsBest團隊跑scripts 為每個新的商店來部署它們個別新的Application server。這個團隊採用手動或scripts的方式來管理，但隨著商店越來越多變更也越來越多且複雜，團隊開始被這類日常工作占據越來越多的工作時間。

某天其中一個客戶A因為做線上促銷的關係流量暴增而發生的問題，團隊為該客戶A調整了他們的訂單系統避免下次發生一樣的問題。而其實其他客戶的基礎都來自同一個架構，團隊也是需要在其他客戶做出相同調整的。但團隊太忙了而且當下其他客戶沒有跟客戶A一樣發生類似的問題所以看起來是不需要的。

一段時間之後DevOpsBest團隊採用了 CHEF這一套自動化工具來管理他們的Application 配置管理。他們先試用在一個剛上線的新客戶上，然後慢慢擴及到了其他客戶的平台上。不幸的是團隊並沒有把客戶A的server給放進CHEF中。所以團隊把對客戶A的優化給排除了。後來客戶A的服務器效能又變慢了，直到團隊發現才修復錯誤再把客戶A的平台放進CHEF來管理。

自動化的恐懼螺旋

這是描述有很多的團隊掉進 configuration drift跟 technical debt.這是因為很多人開始將這一類的自動化工具導入已經在運作的環境時只會拿來用在一些特定的工作中，像是部署新的Server或做一個特定的configuratiob change。

我們害怕全面把工作交給我們的自動化工具，因為我們對它們在系統內會做什麼缺乏信心。

我們在我們的自動化工具缺乏信心，因為我們的Server沒有一致性。

我們的Server運作沒有一致性是因為我們沒有經常使用這些自動化工具並達成一致性。

這些就是自動化的恐懼螺旋(如下圖)。Infra團隊必須打破這種恐懼螺旋才能讓自動化方案實施成功。團隊必須面對他們的恐懼。從一群服務相關Server開始。確認你的infrastructure code可以一再重複的apply到這些Server中。然後使用每小時的排程作業持續不斷的將這些code部署到這些Server中。然後再選另一組服務/平台相關的Server重複剛剛提到的這些作業流程。一直重複這些流程直到你每一台Server都持續被自動化工具update。

良好的監控與自動化測試建立起能持續同步我們infra code的信心。使用上面的方式能立即修正你的configuration drift

原則五: 確認任何的作業流程你都可以一直重複

根據原則二你應該可以在infrastructure重複任何作業。這種重複性的作業可以很簡單的被實作在scripts跟configuration management工具中，比你手做作業好多了。但自動化工作可以做得更多特別是你還沒習慣的手動作業。

例如你要執行分割硬碟的作業，如果寫成scripts跟驗證這個scripts的時間一定是比手動作業還要花時間。大部分的人應該都會選擇手動作業 fdisk command。

但問題開始會產生了，可能隔沒多久你的同一個團隊的其他同事也要進行硬碟分割作業。他選擇一樣的手動分割。但你們卻做了不一樣的決定，他的 /var partition是80GB的 ext3格式，而另一個同事卻是 /var 100GB xfs格式。這裡開始產生的configuration drift，並且開始侵食我們自動化的能力與信心。

有效率的Infra團隊應該要有著很強的寫scripts文化。假如這個作業可以靠scripts完成，哪麼就去做。假若很難去完成想辦法去學習與實驗。也許有其他的方式或工作可以完成，或是這個作業可以被簡化或用其他不同的方式處理。將我們的作業全都變成是可以用scripts完成的通常會讓作業變得是簡單的／無暇的／可靠的。

結論

這邊文章我們比較了在傳統ＩＴ的Infra 架構（靜態的）與現代Infra 架構（動態的）：

• 假設所有的系統是不可靠的
• 讓每件事都可被重製的
• 製造一次性的事物
• 最小化的變動
• 確認任何的作業流程你都可以重複實現

這些原則是利用Cloud Platform特性的關鍵。 與其抵制以最小的effort進行系統變更的能力，不如利用這種能力來獲得系統的quality和reliability.