Microsoft Azure Well-Architected Framework

Azure Well-Architected Framework 是一組指導原則,可以用來改善工作負載的品質。 該架構包含五個卓越的架構要素:成本最佳化、卓越營運、效能效率、可靠性及安全性。

若要使用 Microsoft Azure Well-Architected Framework 中找到的原則來評估您的工作負載,請參閱 Microsoft Azure Well-Architected 檢閱

我們也建議您使用 Azure Advisor 和 Advisor 分數,以找出並優先處理機會,以改善工作負載的狀態。 這兩項服務都可免費供所有 Azure 使用者利用,並符合 Well-Architected Framework 的五個要素:

  • Azure Advisor 是個人化的雲端顧問,可協助您遵循最佳做法來優化您的 Azure 部署。 它會分析您的資源設定和使用量遙測,然後建議可協助您改善 Azure 資源的成本效益、效能、可靠性、卓越營運和安全性的解決方案。 在這裡深入瞭解 Azure Advisor

  • Advisor 分數 是 Azure Advisor 的核心功能,可將 Advisor 建議匯總成簡單、可採取動作的分數。 如此一來,如果您採取必要的步驟來建立可靠、安全且符合成本效益的解決方案,並優先處理將對工作負載的狀態產生最大改善的動作,就能讓您一目了然。 Advisor 分數是由整體分數所組成,可進一步細分為五個類別分數,對應至每個 Well-Architected 架構。 請 在這裡深入瞭解 Advisor 分數。

要素 描述
成本最佳化 管理成本以將傳遞的價值最大化。
卓越營運 讓系統在生產環境中順利運作的作業流程。
效能效率 系統適應負載變更的能力。
可靠性 系統從失敗中復原並繼續運作的能力。
安全性 保護應用程式和資料,使其免於威脅。

成本最佳化

設計雲端解決方案時,重點是及早產生增量價值。 套用 建置-測量-學習 的原則,在避免資本密集解決方案的同時加速上市時間。 在您的架構上使用隨用隨付策略,並投資向外擴展,而不是提供大型投資優先的版本。 將機會成本考慮因素納入架構,並在先進者優勢與「快速跟進」之間取得平衡。 使用成本計算機來估計初始成本和營運成本。 最終,建立原則、預算和控制項,以設定解決方案的成本限制。

成本指導方針

卓越營運

此要素涵蓋讓應用程式在生產環境中執行的作業流程。 部署必須可靠且可預測。 應將部署程序自動化,以避免發生人為錯誤。 部署程序應迅速且成為例行工作,以免拖累新功能或錯誤修正的發行速度。 同樣重要的是,您必須能夠在更新發生問題時快速復原或向前復原。

監視和診斷能力極為重要。 雲端應用程式會在遠端資料中心內執行,而您並沒有其基礎結構或作業系統 (有時候) 的完整控制權。 在大型應用程式中,登入 VM 來疑難排解問題或詳查記錄檔是不切實際的行為。 在使用 PaaS 服務時,甚至可能沒有可供登入的專用 VM。 監視和診斷能力可讓您深入了解系統,以在失敗發生時得知消息並知道其發生位置。 系統必須全都可供觀察。 請使用通用且一致的記錄結構描述,以便讓系統中的所有事件相互關聯。

監視和診斷程序有數個不同的階段:

  • 檢測。 從應用程式記錄、Web 伺服器記錄、Azure 平台內建的診斷功能以及其他來源,產生未經處理的資料。
  • 收集和儲存。 將資料合併到一處。
  • 分析及診斷。 疑難排解問題,並觀察系統整體健康程度。
  • 視覺化和警示。 使用遙測資料來找出趨勢或對作業小組發出警示。

透過 Azure 原則 強制執行資源層級規則有助於確保針對所有支援您工作負載的資產採用操作卓越的最佳作法。 例如,Azure 原則有助於確保所有支援您工作負載的 Vm 都遵守預先核准的 VM Sku 清單。 Azure Advisor 提供 一組 Azure 原則的建議 ,協助您快速找出可針對您的工作負載實行 Azure 原則最佳作法的機會。

請使用 DevOps 檢查清單,從管理和 DevOps 的角度檢視您的設計。

卓越營運指引

效能效率

效能效率可讓您的工作負載進行調整,以有效率的方式符合使用者對其放置的需求。 實現此目標的主要方式是適當地使用調整功能,並實作已內建調整功能的 PaaS 供應項目。

應用程式有兩種主要的調整方式。 垂直調整 (「相應增加」) 代表增加資源的容量,例如使用較大的 VM 大小。 水平調整 (「相應放大」) 則會為資源 (例如 VM 或資料庫複本) 新增執行個體。

水平調整的優勢明顯大過垂直調整:

  • 真正的雲端規模。 可以將應用程式設計成在數百乃至數千個節點上執行,達到單一節點所不可能提供的規模。
  • 水平調整具有彈性。 您可以在負載增加時新增更多執行個體,也可以在負載較少時予以移除。
  • 相應放大程序可自動觸發,不論是根據排程或因應負載的變化。
  • 相應放大的成本可能低於相應增加。 執行數個小型 VM 的成本會少於執行單一大型 VM。
  • 藉由增加備援執行個體,水平調整也可以提升災害復原能力。 如果有某執行個體停止運作,應用程式還是會繼續執行。

垂直調整的優點是不必變更應用程式就可進行。 但是到達一定規模後就會出現限制,而無法再進行相應增加。 屆時,如果要再擴大規模,就必須進行水平調整。

水平調整必須在系統設計時就要考量到。 例如,您可以將 VM 放在負載平衡器後方,以進行擴增。 但是在集區中的每個 VM 都必須能夠處理任何用戶端要求,因此,應用程式必須是無狀態模式或是將狀態儲存在外部 (例如,儲存在分散式快取)。 受控 PaaS 服務通常都會內建水平調整和自動調整。 能夠輕鬆調整這些服務是使用 PaaS 服務的主要優勢。

能夠輕鬆調整這些服務是使用 PaaS 服務的主要優勢之一。 這種做法可能只是將效能瓶頸推向其他地方。 例如,如果您調整 Web 前端來處理更多用戶端要求,可能會讓資料庫觸發鎖定爭用。 然後,您就必須考慮採取其他措施 (例如,開放式並行存取或資料分割),才能提高進入資料庫的輸送量。

請一定要進行效能和負載測試,以找出這些潛在的瓶頸。 系統的具狀態部分 (例如資料庫) 是最常造成瓶頸的因素,必須謹慎設計才能順利進行水平調整。 解決一個瓶頸可能會讓其他地方又出現瓶頸。

使用 效能效率檢查清單,從延展性觀點來檢閱您的設計。

效能效率指引

可靠性

可靠的工作負載是一個既有彈性又可供使用的工作負載。 災害復原是指系統從失敗中復原並繼續運作的能力。 災害復原的目標是使應用程式在發生失敗後,能夠恢復到完全正常運作的狀態。 可用性是使用者在需要時能否取得您的工作負載。

在傳統的應用程式開發中,會將焦點放在增加平均失敗間隔時間 (MTBF)。 將許多心力花在避免系統發生失敗之情形。 在雲端運算中,則需要不同的思維,原因如下:

  • 分散式系統實為複雜,某處發生失敗很可能會讓整個系統發生連鎖反應。
  • 為了維持低成本,雲端環境會使用標準規格之硬體,因此一定會偶有硬體發生故障情形。
  • 應用程式經常依賴外部服務,但這些外部服務可能會暫時無法使用,或是針對大量使用者進行限流處理。
  • 現今的使用者都期望應用程式應全天候都隨時可用,永遠不會離線。

綜合上述之因素,雲端應用程式必須設計成預期會偶爾發生失敗並可以從中復原。 Azure 平台已內建許多災害復原功能。 例如:

  • Azure 儲存體、SQL Database 和 Cosmos DB 全都提供內建的資料複寫功能,不論是單一區域內或是跨區域皆有提供。
  • Azure 受控磁碟會自動放在不同的儲存體縮放單位,以減少受到硬體故障的影響程度。
  • 可用性設定組中的 VM 會分散到數個容錯網域。 容錯網域是一組 VM,這些 VM 會共用電力來源和網路交換器。 將 VM 分散到不同的容錯網域可以減少當實體硬體故障、網路中斷或電源中斷所產生的影響。

話雖如此,您仍需要在應用程式中建置復原功能。 復原策略可以套用到系統架構中的所有層級。 某些緩和措施在本質上較有戰術意義,例如,在短暫的網路失敗後重試遠端呼叫。 其他緩和措施則較有策略意義,例如將整個應用程式容錯移轉到次要區域。 戰術性緩和措施可以產生很大的不同結果。 雖然很少遇到整個區域都發生中斷的情況,但網路壅塞之類的暫時性問題並不罕見,因此請先以此做為目標措施。 擁有適當的監視和診斷能力也很重要,這樣才能偵測到失敗的發生,並找出根本原因。

在為應用程式設計災害復原能力時,您必須了解您的可用性需求。 可接受多少停機時間? 這是功能成本的部分考量。 可能的停機時間會造成多少業務成本? 您應該將多少成本投資於此應用程式的高可用性?

可靠性指引

安全性

思考應用程式從設計和實作到部署與作業之整個生命週期的安全性。 Azure 平台可防範各種不同威脅,例如網路入侵和 DDoS 攻擊。 但您仍需要在應用程式和 DevOps 程序中建立安全性。

以下是部分需要考慮的安全性領域。

身分識別管理

請考慮使用 Azure Active Directory (Azure AD) 來驗證並授權使用者。 Azure AD 是完全受控的身分識別和存取管理服務。 您可以用它來建立僅存在於 Azure 中的網域,或用它來整合內部部署之 Active Directory 身分識別。 Azure AD 也整合了 Office365、Dynamics CRM Online 和眾多第三方 SaaS 應用程式。 對於消費者導向的應用程式,Azure Active Directory B2C 可讓使用者使用其現有的社交帳戶 (例如 Facebook、Google 或 LinkedIn) 進行驗證,或建立由 Azure AD 管理的新使用者帳戶。

如果您想要整合內部部署 Active Directory 環境與 Azure 網路,可行的方法有好幾個,端視您的需求而定。 如需詳細資訊,請參閱身分識別管理參考架構。

保護您的基礎架構

請控管您所部署之 Azure 資源的存取權。 每個 Azure 訂用帳戶都會與 Azure AD 租用戶有信任關係。 請使用 Azure 角色型存取控制 (Azure RBAC) 來為組織內的使用者授與正確的 Azure 資源權限。 若要授與存取權,請將 Azure 角色指派給某個範圍內的使用者或群組。 此範圍可以是訂用帳戶、資源群組或是單一資源。 對基礎架構的所有變更進行稽核

應用程式安全性

一般情況下,開發應用程式時的安全性最佳做法仍適用於雲端。 這些做法包括在所有地方使用 SSL、防範 CSRF 和 XSS 攻擊、防止 SQL 插入式攻擊等等。

雲端應用程式通常會使用具有存取金鑰的受控服務。 請永遠不要將這些存取金鑰簽入到原始檔控制。 您可以考慮將應用程式密碼儲存在 Azure Key Vault。

資料主權和加密

使用 Azure 資料服務時,請確保您的資料留在正確的地緣政治區域內。 Azure 的異地備援儲存體會在相同的地緣政治區域中使用配對區域的概念。

請使用 Key Vault 來保護加密金鑰和密碼。 藉由使用 Key Vault,您便可以使用硬體安全性模組 (HSM) 所保護的金鑰來加密金鑰和密碼。 許多 Azure 儲存體和 DB 服務都支援待用資料加密,包括 Azure 儲存體Azure SQL DatabaseAzure Synapse AnalyticsCosmos DB

安全性資源