借 AWS 建 IaaS 架構經驗、淺談十年來的十項教訓

作者為：Amazon Web Services 首席技術總監 Werner Vogels

AWS（Amazon Web Services）始於 2006 年 3 月 14 日 Amazon S3 的發佈，至今已有十年時間。回首過去十年，我們在構建和營運 AWS 雲端運算服務中累積大量的經驗教訓，這些服務不僅需要安全、可靠和可擴展的，同時還要以最低的成本提供可預測的性能。由於 AWS 是全球構建和營運此類服務的先鋒，因此這些經驗教訓對我們的業務來說尤其重要。正如我們多次重申，「經驗不存在壓縮演算法」。因為 AWS 每月有超過一百萬的活躍用戶，而這些用戶也許會為數以億計的自家客戶提供服務，所以能讓 AWS 累積上述經驗教訓的機會比比皆是，從而不斷提升服務質素。 我在這些經驗教訓中挑選了一些和大家分享，希望對各位也能有所幫助。

1. 構建可改進的系統

從建立 AWS 的第一天開始，我們已清楚意識到我們在研發的這套軟件不是一勞永逸的。現在可以用的軟件，一年之後很可能將不再適用。我們的預期是，每次用戶數量增加一或兩倍，我們便需要重新檢視和適當地修改已有的架構，以便解決擴展性的問題。

但是我們不能採取過去常用的停機方式進行系統檢修及升級，因為世界各地的眾多業務都依賴我們的平台提供全天候的服務，所以我們需要構建一個在引入新的軟件零件時不會引起服務癱瘓的架構。Amazon 傑出工程師（Amazon Distinguished Engineer）Marvin Theimer 有一次開玩笑說，Amazon S3 這項服務的改進用飛機的演變來形容最為貼切。我們最開始開的是一架單引擎的小型飛機，一段時間後升級成一架波音 737 客機，之後又換成一隊波音 747 客機，而現在更像是由空中巨無霸空中巴士 A380 組成的一支大型機隊。由始至終，在 AWS 的用戶毫不知情下，我們一邊通過空中加油確保飛機的正常飛行，一邊在萬米高空上將用戶從一架舊飛機移送到另一架新的上面去。

2. 預料不可預料的情況

故障是注定的；隨著時間的流逝，一切終將歸於失敗：從路由器到硬碟，從作業系統到被儲存單元損壞的 TCP 數據包，從短暫誤差到永久失效，無論你用的是最高品質硬件還是最低成本的零件，這都是理所當然的。

在服務規模變得很大之後，這個問題愈加明顯：舉例來說，當 Amazon S3 服務處理數以萬億的儲存交易時，即使誤差或然率極小的情況也會發生。在設計和構建階段，有些故障場景事先會被考慮到，但更多的則是未知數。

因此，我們需要構建的是將故障視為自然發生的情況的系統，即使我們並不知道會是怎樣的故障。縱使「後院已經著火」，這些系統應該要依然可以繼續運作。我們必須能在不需要關閉整個系統的情況下管理好受影響的局部零件。我們已經培養一套可控制故障發生時受影響範圍的基本技能，確保系統的整體健康狀態得以維持。

3. 提供基元而非框架

很快我們開始發現，用戶大都喜歡在 AWS 提供的服務上持續構建和改進自己的業務系統。當擺脫傳統 IT 硬件和數據中心的束縛後，他們開始以一種全新、有趣及前所未見的使用模式開發自己的系統。正因如此，為滿足用戶多樣的需求，我們的架構需要保持高度的靈活性。

關於這一點，其中一項最重要的機制就是我們提供給用戶的是一系列基元和工具，而不是一個固定、統一的大框架，讓用戶可以選擇他們喜歡的方式來使用 AWS 雲端服務。這個機制使我們的用戶非常成功，因此往後數代的 AWS 服務也沿用這套用戶已習慣的機制。

另一項重要的須知是，我們很難在用戶還沒開始使用一項服務之前，就準確預知到對使用者而言該服務需要優先考慮的問題。這也是為什麼我們所有的新服務最初的發佈都是最小的功能系列，然後借助用戶的意見擴展該服務的功能。

4. 自動化是關鍵

開發一個需要持續操作的軟件服務和開發一個最終交付給客戶的軟件有著巨大的差異。管理規模龐大的系統需要一種完全不同的觀念，才能確保滿足使用者對可靠性、性能以及可擴展性的要求。

實現這個目標的一個主要的機制，就是避免容易產生誤差的人手操作，盡可能地將管理工作自動化。為此，我們需要構建一套可以控制主要功能的管理 API。在這方面，我們也幫助自己的用戶。通過將應用分解成一個個獨立的模組，每個模組都有自己的管理 API，你可以很方便地定義自動化規則來維持大規模、可靠及可預測的性能。若要判斷自動化做得是否到位，可以思考一下你是不是還需要使用 SSH（Secure Shell）進入某台伺服器進行運作維修？如果答案是 yes，便說明你需要改善自動化系統。

5. API 定義要嚴謹，因為一旦推出就無法更改

雖然我們已從 Amazon 零售項目中汲取教訓，但對於 AWS 這種以 API 為中心的服務，這個原則變得更加重要。一旦用戶開始用我們的 API 開發他們的應用和系統，我們就不可能再對這些 API 進行變更。因為 API 的任何改動都會影響使用者已有的項目。因此我們充分意識到，在把 API 交付給用戶之前，我們只有一次精準地設計 API 的機會。

6. 監控你的資源使用情況

當決定一項服務的收費模式時，請務必確保你有一份關於該服務的資源成本和營運的資料，尤其是那些高產量、低利潤率的業務。作為服務供應商，AWS 需要對服務成本保持高度敏感，以便我們能清楚地知道我們是否能承擔提供某項服務，同時也能夠辨識一些可以通過提高營運效率而進一步降低成本的地方，從而降低服務價格，最終惠及用戶。

舉一個例子：在早期的時候，我們並不是很了解 Amazon S3 服務所用到的資源成本。我們當時假定，儲存和頻寬應該是我們首要考慮的收費點；在運作一段時間之後，我們才意識到請求數量跟儲存與頻寬同等重要。如果用戶有大量的小檔案需要儲存，這種情況下，即使是百萬量級的請求，都不會佔用太多的儲存空間和頻寬資源。最終我們作出調整，將請求數量也納入收費模型，以便 AWS 在收支上可以保證這項服務的可持續性。

7. 從一開始建立安全機制

保護你的用戶永遠都應該是你的首要任務，在 AWS 也不例外。不光要從營運的角度，還要從工具和機制的角度保證這一點。對此，我們也將繼續保持最高的支持與投入。我們很快領略到若要建立安全的服務，我們需要在服務設計的最初階段就抱有這種安全意識。安全團隊的任務不是在成功開發一項服務後才開始安全檢查，相反地，安全團隊的工作應該和開發團隊一樣，是貫穿整個研發的生命週期，以確保服務的安全性。當涉及安全的問題時，是沒有任何妥協的餘地。

8. 資料加密是優先任務

資料加密，是保證使用者資料安全的重要機制。十年前，資料加密相關的工具和服務還不夠完善，直到 AWS 剛開始營運的最初幾年，我們才逐步累積很多關於在服務中整合資料加密的最佳實踐。

Amazon S3 最初提供的，是伺服器方面的加密機制。我們在數據中心移除帶有使用者資料的磁碟，因此這些資料是無法被讀取的。但是其後推出的 Amazon CloudHSM（適用於硬件安全模式）和 Amazon Key 管理服務，容許使用者自訂加密金鑰，這樣 AWS 就不需要替使用者管理它們的加密金鑰。

現在，AWS 所有的新服務，在原型設計階段已經整合資料加密。例如，在 Amazon Redshift 服務中，每一個數據組都通過一個隨機的金鑰進行加密，而這些隨機的金鑰則由一個主金鑰進行加密儲存。用戶可以自訂這個主金鑰，這就能保證只有用戶本人才能讀取這些機密的商業資料或敏感的個人資訊。

9. 網絡的重要性

AWS 的服務支援各種各樣的工作負載場景。從大批量的交易處理到大規模的影像轉碼，從高性能平行運算到大量的網絡請求。這些不同的工作負載場景，對網絡的要求也各不相同。

AWS 已開發一套獨特的機制，針對數據中心的設計和營運的創新；這套機制提供靈活的網絡基礎設施，以便滿足任何使用者的不同工作負載場景的需求。在這個過程中，我們也認識到，為了讓使用者達成它們的目標，我們必須勇於開發自己的網絡解決方案。這樣也能滿足我們的特定需求，例如擁有在網絡上隔離不同的 AWS 用戶的能力，以保證高度安全。

AWS 自主開發的軟硬件解決方案，也能給我們的用戶帶來進一步的性能提升。虛擬機器之間的網絡通訊便是一個成功的例子。由於網絡通訊是一項共用的資源，在使用 AWS 研發的解決方案前，用戶時常會遇到網絡擁擠的問題。最終，AWS 通過開發支持單根 I/O 虛擬化技術的 NIC，令每個虛擬機器擁有獨自的 NIC 的解決方案。這一改動降低網絡延遲多於兩倍，同時提升網絡性能達十倍。

10. 不設限，保持平台的中立與開放

多年來，AWS 團隊提供越來越多的服務和功能，為我們的用戶創造一個廣闊的開發平台。但是 AWS 遠遠超越我們團隊開發的這些功能與服務，因為合作夥伴提供的服務進一步擴大和豐富整個生態系的。例如，我們的合作夥伴 Stripe 提供的支付服務讓 Twilio 在 AWS 上支援電話業務。

很多使用者應用 AWS 開發出自己的產品，以解決特定的垂直領域的問題。例如，飛利浦開發用於健康數據管理的 Healthsuite 數碼平台；Ohpen 則基於 AWS 開發零售銀行平台；Eagle Genomics 開發運算平台處理基因等。AWS 並不會限制我們的合作夥伴，規定他們什麼可以做什麼不可以做。「不設限」的原則釋放創新的動力，為意想不到的創新敞開大門。

對於在接下來的十年裡， AWS 的團隊會學到哪些經驗教訓，我們的用戶又會創造出什麼樣的價值，我充滿期待。

請記著，對 AWS 來說，這僅僅是一個新的開始。