Azure 上 SaaS 工作負載的計算
您的軟體即服務 （SaaS） 應用程式必須在計算平台上執行。 如同您架構中的其他元件，它必須符合商務需求，並根據您的商務模型設計。 計算平台的選擇是重要的設計決策。 您的決策會影響客戶隔離、效能和復原能力，而您的計算平臺會影響整個 SaaS 解決方案的規模和成長方式。
本文說明選擇裝載模型的考慮、該模型的作業層面，以及如何優化技術選項，以協助您符合服務等級協定（SLA）和服務等級目標（SLA）。
選取計算平臺
為 SaaS 工作負載選擇正確的計算平臺很重要，但豐富的可用選項可能會讓選擇感覺壓倒性。 最佳平臺取決於應用程式架構、規模、效能需求和租用戶隔離模型等因素。 一個應用程式的最佳選擇可能不是另一個應用程式。
設計考量
裝載模型。 Azure 提供各種裝載模型，主要是基礎結構即服務 （IaaS） 和平臺即服務 （PaaS），每個模型都有自己的優點和取捨。 評估應用程式的需求，並選擇最適合的模型。
IaaS 提供虛擬機（VM）並完全控制它們，包括網路和記憶體。 不過，它需要管理和修補，這在操作上可能很密集。 範例包括虛擬機擴展集和 Azure Kubernetes Service （AKS） 叢集。
PaaS 可讓您部署應用程式，而不需管理基礎結構。 其中包含自動調整和負載平衡的內建功能。 範例包括 Azure App 服務 和 Azure Container Apps。
相較於 IaaS，PaaS 服務提供較少的控制，如果您的應用程式需要特定設定，這可能會造成問題。 例如，您的應用程式可能會在 PaaS 服務不支援的作業系統上執行。
工作負載類型。 某些平臺針對特定工作負載特製化，而其他平臺則多用途。 例如，App Service 是針對 Web 應用程式所設計，而 AKS 則是更一般用途。 它可以裝載 Web 應用程式、AI 工作負載和批次計算工作。
開發小組專業知識。 如果小組缺乏新平台的經驗，則大型變更可能會很困難。 評估小組的技能，並符合您的平臺需求。 從簡單的平台開始，並逐漸發展您的架構，而不是直接跳至更進階的選項。
例如，如果您要建置容器化應用程式，請從 Container Apps 開始輕鬆管理。 當您的需求變得更複雜時，您可以在一段時間后深入了解平臺時，轉換至 AKS。
管理額外負荷。 計算平臺會平衡額外負荷和控制。 從您的小組轉移的更多管理責任意味著對平臺的控制較少。
例如，IaaS 提供對 VM 的高控制，但會產生顯著的額外負荷。 如果您的應用程式部署在客戶的環境中，您可能會有有限的管理作業存取權。 評估這些取捨是否可接受且可行。
效能需求。 藉由將 CPU、記憶體、網路模型化，包括頻寬和延遲、GPU 和可用性需求來瞭解應用程式的效能需求。 您也應該考慮未來的成長。 使用這項資訊來選擇適當的計算資源，例如 VM 的數位和大小。 您可能也需要選取支援特定 VM 系列的特定區域，以符合特殊需求。
可靠性需求。 請考慮計算平臺的可靠性功能，並確保它們符合您的可靠性目標。 您可能需要使用特定服務層級來擁有解決方案的多個實例，或跨可用性區域部署，以提高可靠性。
如需 定義可靠性目標，請參閱 RE：04 建議。
應用程式安全性和合規性。 評估每個計算平台的安全性功能和 合規性認證 ，以確保它們符合您的需求。 例如，如果您需要監視和篩選傳出流量，您可能需要選擇特定的計算服務或階層。
設計建議
| 建議 | 優點 |
|---|---|
| 藉由估計 CPU、記憶體、網路和 GPU 縮放維度來評估計算效能需求。 執行負載測試以收集更精確的數據，以通知您的模型化練習。 |
這些工作可協助您為計算平臺選取適當的重設大小，並在系統負載增加時適當調整。 |
| 評估小組的熟練程度，並從最不複雜的平台開始，以符合您需求或小組已經熟悉的平台開始。 | 您可以選擇熟悉的計算平臺，以確保作業更順暢，並避免過度負擔您的小組。 |
| 在您的設計中具有彈性。 針對一個解決方案，您可以逐一查看，以適應不斷演變的商務和技術需求。 | 彈性可讓您更輕鬆地適應一段時間的變更和改進。 您可以有效地回應不斷演進的商務和技術需求。 |
| 評估總擁有成本 （TCO），包括操作解決方案的成本。 | 您清楚瞭解成本，這對規劃定價模式和確保符合成本效益的作業至關重要。 |
| 評估您是否需要使用特定計算平臺，因為您的技術堆疊。 某些計算平臺更適合特定程式設計語言、工具和作業系統。 努力使用原生支援您技術選擇的平臺。 | 您可以避免重新設計架構的成本，這可能包括移轉至新的平臺。 |
| 評估平臺的可靠性功能，並將雲端服務提供者的保證納入 SLO。 | 您可以規劃可靠性功能，並在可用時使用可用性區域，以降低當地語系化數據中心中斷的風險。 |
租用模型和隔離
您的 SaaS 商務模型會決定您為客戶裝載資源，或是在客戶的環境中管理資源。 大部分的 SaaS 提供者會代表客戶裝載資源，這可讓您彈性地進行計算平台設計。 有效地隔離客戶工作負載，以將成本效益優化，而不會影響客戶體驗或效能。
設計考量
規劃您的租用模型。 您的租用模型會決定客戶之間的資源分享，並受到您的商務和定價模式的影響。 相較於完全多租使用者模型，單一租使用者模型每個客戶的成本較高。 您的定價應該反映這些差異。
客戶需求。 某些客戶可能有數據落地、效能保證或安全性合規性的特定需求。 如果這些需求需要比平常更高的隔離等級，請考慮如何反映商務模型中成本的增加。
嘈雜的鄰居問題。 在租用戶之間共享資源時，請注意吵雜的鄰近問題。 計算資源受到影響最大。 如需詳細資訊，請參閱 Noisy 芳鄰反模式。
當您選擇租用模型時，請平衡資源分享的成本節省與保證客戶效能的需求。 過度共享資源或允許過度耗用量可能會降低客戶體驗。
取捨：效能和成本。 在客戶之間共用資源可能符合成本效益，但如果某些客戶使用的資源超出預期，此方法可能會降低其他客戶的效能。 若要避免這種情況，請實作適當的資源控管，以確保租使用者使用量保持在預期的限制內。
設計建議
| 建議 | 優點 |
|---|---|
| 評估計算平台的隔離功能，以確保其符合您的租用模型需求。 | 您可以先確認重要設定，以避免重新作業平臺。 |
| 強制執行隔離模型。 請小心共用的資源，例如本機磁碟快取、系統記憶體和外部快取，因為它們在租用戶之間若未正確管理，可能會意外洩漏數據。 針對高隔離需求，請在計算平臺和應用程式中強制執行隔離。 |
強式隔離可降低跨租用戶數據外泄的風險，這是嚴重的安全性事件。 |
| 使用客戶層級計量的可見度來實作資源治理和監視。 主動監視每個客戶的資源耗用量，以偵測並減輕嘈雜的鄰近問題。 |
您可以藉由監視資源耗用量及提早減輕問題，防止問題影響其他客戶。 |
設定延展性和成本效益
您的客戶可以使用您的應用程式搭配不同的效能配置檔。 他們預期應用程式能夠處理使用者需求增加、大規模數據和複雜的工作負載，而不會影響速度和效能。 不論系統架構管理數億或數百萬使用者，都必須確保延展性和最佳效能，同時平衡效能需求和成本。
如需成本管理的詳細資訊，請參閱 Azure 上 SaaS 工作負載的計費和成本管理。
設計考量
水平和垂直調整策略。 水平和垂直縮放方法可用於處理增加的負載。 您使用的方法取決於應用程式跨多個實例進行調整的能力。
- 水平調整牽涉到新增更多計算節點實例。 您的架構需要負載平衡器，才能將連入流量分散到多部伺服器或實例。
- 垂直調整牽涉到在單一伺服器上增加資源，例如 CPU 和記憶體。 針對不需要像是快取等外部狀態存放區的具狀態應用程式，請使用此方法。 垂直調整可能會導致短暫的服務中斷，而且在單一伺服器上具有資源限制。
請參閱PE：05調整和分割的建議。
自動調整。 系統需要有效率地處理不同層級的需求。 隨著使用者流量的增加，您的應用程式資源需要相應增加以維持效能。 當需求減少時，資源會相應減少以控制成本，而不會影響用戶體驗。 CPU 使用率、一天中的時間或傳入要求等因素會引導這些調整。 自動調整可協助平衡效能和成本，並降低高需求對其他租用戶的影響。
如需可靠的調整，請參閱 RE：06 建議。
容量規劃和計算配置。 將新客戶上線到您的 SaaS 工作負載會耗用資源容量。 即使您以垂直或水準方式調整，您最終仍會在解決方案的延展性中達到限制，例如網路或記憶體限制。
設計建議
| 建議 | 優點 |
|---|---|
| 選擇水平縮放比例與垂直縮放比例。 水平調整通常較不複雜、更可靠，且比垂直調整更具成本效益。 | 水平調整通常更簡單、更可靠且符合成本效益，這可讓您調整為比垂直縮放比例更高的程度。 |
| 執行負載測試。 | 模擬使用方式可協助您在部署至生產環境之前找出瓶頸和調整閾值。 |
| 定義用於部署新戳記的調整臨界值，而不是水準或垂直調整。 針對符合成本效益的調整，而不遺失效能，請盡可能將您的租用戶壓縮到最少的資源上。 |
您更準備好處理超出您目前基礎結構的成長。 |
| 盡可能實作自動調整。 設定自動調整規則，以準確地反映應用程式的負載。 | 您可以視需要增加和減少資源，將效能和成本優化。 |
| 監視及評估客戶使用模式。 | 您知道何時調整基礎結構以提升效能或將成本優化。 |
| 盡可能實作快取機制。 | 您可以降低計算層的潛在處理負載。 |
| 使用 成本警示。 | 警告可協助您儘早偵測高使用量和控制成本問題。 |
| 針對具有長期承諾且保證整個期間計算使用率的客戶使用 Azure 保留 。 | 您將保留容量的成本效益最大化。 |
用於復原的設計
計算層的復原在整體復原策略中扮演重要角色。 您的應用程式應該能夠自動且順暢地容忍和復原常見失敗，而不會對使用者造成影響。
設計考量
可靠性需求。 設定明確的可靠性需求。 這些需求包括內部目標或 SLA，以及客戶承諾，或 SLA，通常指定運行時間目標，例如每月 99.9%。
如需 定義可靠性目標，請參閱 RE：04 建議。
部署策略。 雲端資源會部署在特定地理區域中。 在 Azure 中，可用性區域是區域內隔離的數據中心集合。 如需復原功能，請跨多個可用性區域部署應用程式。 跨區域或雲端提供者部署可增強復原能力，但會增加成本和作業複雜性。
請參閱使用可用性區域和區域的 RE：05 建議。
無狀態工作負載。 若要部署復原的應用程式，您通常需要在不同的位置執行備援複本。 對於需要維護會話狀態的具狀態工作負載而言，這項工作可能會很困難。 目標是盡可能建置無狀態工作負載。
設計建議
| 建議 | 優點 |
|---|---|
| 處理 應用程式中的 暫時性錯誤。 | 您可以透過快速從次要問題復原來增加可用性。 |
| 選擇無狀態應用程式。 如果您的應用程式需要具狀態，請使用外部狀態儲存機制，例如快取來儲存狀態。 | 您可以防止實例無法使用所造成的狀態遺失，例如在錯誤負載平衡期間或中斷期間。 |
| 使用可用性區域。 | 您可以藉由減少當地語系化的數據中心中斷來增加復原能力。 |
| 當有業務理由這樣做時，請設計多區域架構。 | 您符合高運行時間需求，並支援不同區域中的使用者。 |
| 執行 混亂工程。 | 您可以進一步了解失敗點的位置，並在發生中斷之前加以修正。 |
| 限制多個戳記共用的元件使用。 | 您可以消除單一失敗點，並減少中斷的潛在影響區域。 |
其他資源
多租用戶是設計 SaaS 工作負載的核心商務方法。 這些文章提供有關計算平台考慮的詳細資訊：
後續步驟
瞭解 SaaS 工作負載的網路考慮。