AWS 採用「共同責任模型」 助客戶在雲端系統上構建高韌性方案

透過雲端技術建立高韌性的項目架構，往往需要確保數據的安全性、可用性、可控制度、從災難中復原的能力、容錯，以及對混沌工程的理解與應用。由 AWS 建構及採用的「共同責任模型」中，AWS 負責操作、管理和控制客戶的硬體、軟件、網絡和設施，而客戶則須負責管理數據、應用程式及配置，以確保數據受到保障。這套模式的建立，一方面可以減輕客戶操作上的負擔，同時亦有助客戶，尤其是需要保護數據的初創企業提升數據安全意識，為建立高韌性架構奠定基礎。

在 AWS，精簡而可靠的工作文化是組織架構上的一大要點。透過業界著名的「兩個披薩團隊」理論，以「能夠被兩個披薩餵飽」的原則組建團隊，最大限度地提升員工為客戶進行革新的專注度，同時減少因官僚主義帶來的延誤，以高效率的工作進程及簡化的溝通渠道，提升員工滿意度、工作效率及減少決策開支。這種結構確保每個團隊對其服務的營運和性能負責，從而培養員工的責任感並加快解決問題的效率。

這樣的企業文化，使 AWS 在為客戶設計方案時，也能考慮到以最快、最直接、最有效的方式處理事件與危機，並在不同的服務中反映出這種管治邏輯，有效協助客戶建立具韌性的方案。

以雲端服務為例， Amazon EC2 的 Auto Scaling 組件能夠確保客戶的應用程式擁有正確數量的 EC2 執行個體，適時應對不同程度的流量，其主要組件包括：

1. Auto Scaling 組：包含一組 Amazon EC2 執行個體組成，在開始作業時會啟動足夠的執行個體，以滿足所需的容量
2. 啟動配置：用於啟動 EC2 執行個體的組態範本
3. 擴展策略動態：能夠動態地根據 CPU 使用率或網絡流量等指標，增加或減少群組中執行個體的數量，以滿足不斷變化的條件

Auto Scaling 能夠透過自動調整 EC2 執行個體的數量來回應用戶需求，從而增加應用程序的可用性，同時通過在需求較低的時期縮減執行個體，並在需求較高的時期擴展執行個體，自動地為客戶節省成本，滿足高韌性的要求。

在災難復原選項方面，AWS 中可用的災難復原策略可以大致分為四種方法，涵蓋低成本、低複雜性的製作備份，到使用多個主動區域的較複雜策略。其中一項能夠提升平台韌性的策略為「暖待命」。暖待命策略主要是在另一區域中建立一個規模較細，但功能齊全的環境副本，此策略在可以在災難發生時快速擴展到完整容量，並在出現故障或災難情況時，將流量重新定向到備用環境，最大限度地減少停機時間和數據丟失，並確保業務連續性。

另一方面，透過分離儲存與運算資源，確保跨區域的低延遲數據能夠成功同步，提升韌性與災難復原能力。這種設計在故障或災難出現時才會啟動計算執行個體的功能，確保數據一致性與系統韌性，並得以從經歷災難中復原。這項方法有著高可用性，對於客戶關鍵應用至為重要。

在故障或災難發生的過程中，Aurora 會自動切換到另一個可用區域中的備用執行個體，從而將應用程序中斷降至最低。過程包括持續監控主執行個體的健康狀況，並自動將副本更新為主執行個體、並確保所有副本的數據完整性和一致性。

此外，可用區域 (AZ) 是 AWS 區域中一個或多個擁有冗餘電源、網路和連接性的獨立數據中心。AZ 讓客戶能夠操作生產應用程式和數據庫，比單一數據中心具有更高可用性、容錯能力和可擴展性。AWS 區域中的所有 AZ 透過高頻寬、低延遲網路與完全冗餘的專用以光纖互連，在 AZ 之間提供高輸送量、低延遲的網路。

其中，AWS 的 Amazon RDS 異地同步備份功能則會在不同的 AZ 中建立及維護執行個體，當主執行個體發生故障時，RDS 會自動將作為後備的執行個體提升為新的主執行個體，這個過程不需要手動干預；在故障轉移的過程中，DNS 紀錄更會自動更新，以確保應用程式能夠迅速恢復正常運行。這樣的設計確保高可用性和數據持久性，即使在基礎設施發生故障時也能夠保證業務的連續性。

AWS 的技術總監 Werner Vogels 曾說「一切都會失敗」，強調在設計基礎設施時應假設錯誤或災難的情況總會無可避免、毫無預兆地會出現錯誤或災難。通過預先計劃出現問題時的應對策略，系統得以自動執行快速恢復和容錯機制，提升方案的韌性。

AWS 提供全面的工具和最佳應用方案，幫助客戶設計韌性架構，當中包括通過利用多 AZ 部署、多區域策略以及 Auto Scaling 和一系列監控工具，讓初創公司得以構建能夠承受各種故障場景的強大、高性能系統。

原刊來源 / Original publication ↗