以平均分散於 3 個可用區域的 Auto Scaling 群組,營運一個尖峰時段需要常態 6 台處理能力的 Web 應用程式。若希望在 1 個可用區域完全停止時仍維持尖峰時段的處理能力,下列哪項最小台數設定最為合適?

解析

平均配置於 3 個可用區域時,失去 1 個可用區域即等同於同時失去整體的三分之一台數。必須以剩餘的三分之二支應尖峰時段所需的 6 台,因此需要 6 ÷ (1 - 1/3) = 9 台。若每個可用區域各配置 3 台,在失去 1 個可用區域後仍會剩下 6 台。

各選項解析

實際使用情境

僅僅「做成多可用區域」並不足以承受可用區域故障。EC2 Auto Scaling 群組雖會嘗試將執行個體平均配置到所指定的多個子網路(即可用區域),但只要 1 個可用區域停止,該可用區域上的執行個體便會同時失去。因此,若要在可用區域故障後仍維持所需的處理能力,便需要事先將「會失去的部分」納入計算而確保台數的靜態穩定性(static stability)概念。設所需能力為 N、可用區域數為 Z,則為承受 1 個可用區域喪失所需的總台數為 N ÷ (1 - 1/Z) 無條件進位後的值。2 個可用區域為 N 的 2 倍,3 個為 1.5 倍,4 個約為 1.34 倍,可用區域數越多,所需的多餘率越低。 此處常有「可用區域故障後 Auto Scaling 會自動於其餘可用區域補充,應該不需要多餘台數吧」的反駁,但實際上補充需要執行個體啟動、初始化、通過健康檢查的時間,且可用區域故障時同一區域的其他使用者也會同時要求容量,未必能立即取得所需容量。在故障的瞬間就以「已經運作中的狀態」持有所需能力,即為靜態穩定性的要點。相關設定方面,若將 Auto Scaling 群組的健康檢查類型不僅設為 EC2 而設為 ELB,則因程序異常而應用程式無回應的執行個體也會成為替換對象。 SAA-C03 中,會以「即使 1 個可用區域停止仍希望維持效能」的附加條件,出成選擇最小台數或所需容量的計算題。掌握 3 可用區域架構為所需能力的 1.5 倍、2 可用區域架構為 2 倍的比例,即可即答。選擇過度台數的選項在成本最佳化的觀點下為誤答,因此以「選出滿足需求的最小架構」的方式判讀相當重要。