共用方式為

多租使用者解決方案中計算的架構方法

  • 發行項

大部分雲端式解決方案是由某種類型的計算資源所組成，例如 Web 和應用層、批次處理器、排程作業，甚至是 GPU 和高效能計算 （HPC） 等特製化資源。 多租用戶解決方案通常受益於共用計算資源，因為基礎結構的租使用者密度較高，可降低營運成本和管理。 您應該考慮隔離需求和共用基礎結構的影響。

本文提供規劃多租用戶計算層時，解決方案架構設計人員必須考慮的考慮和需求指引。 這包括將多租戶模式應用於計算服務的一些常見模式，以及一些需要避免的反模式。

重要考慮和需求

多租使用者和您選取的隔離模型會影響計算資源的調整、效能、狀態管理和安全性。 在本節中，我們會檢閱規劃多租使用者計算解決方案時必須做出的一些重要決策。

規模

系統必須在不斷變化的需求下充分執行。 當租用戶數目和流量增加時，您可能需要增加資源的容量、跟上不斷增加的租用戶數目，以及維持可接受的效能率。 同樣地，當活躍用戶數目或流量減少時，您應該自動減少計算資源以降低成本，但應確保對使用者的影響降至最低。

如果您為每個租使用者部署專用資源，您可以彈性地獨立調整每個租用戶的資源。 在一種計算資源由多個租戶共用的解決方案中，如果您擴展這些資源，則所有這些租戶都可以利用這次擴展。 不過，當規模不足以處理其整體負載時，它們也都會遭受損失。 如需詳細資訊，請參閱 Noisy Neighbor 問題。

當您建置雲端解決方案時，您可以選擇 水平或垂直調整。 在租戶數量不斷增加的多租戶解決方案中，水平擴展通常可提供更大的彈性和更高的整體擴展能力上限。

應用程式通常直到負載運行時才會發現效能問題。 您可以使用完全受控的服務，例如 Azure Load Testing，以瞭解應用程式在壓力下的行為。

擴展觸發器

無論您使用哪種方法來調整，您通常需要規劃導致元件調整的觸發程式。 當您擁有共用元件時，請考慮使用資源之每個租使用者的工作負載模式，以確保布建的容量可以符合總所需的容量，並將遇到 Noisy Neighbor 問題之租用戶的機會降到最低，。 您也可以考慮租戶的數量來規劃您的擴充容量。 例如，如果您測量用來服務 100 個租戶的資源，則當您將更多租戶上線時，您可以規劃擴充資源，讓每個額外 100 個租戶的資源加倍。

州

計算資源可以是無狀態 ，也可以 具狀態。 無狀態元件不會維護請求之間的任何資料。 從可擴展性的觀點來看，無狀態元件通常很容易進行水平擴展，因為您可以快速新增新的工作者、實例或節點，而且立即開始處理請求。 如果您的架構允許，您也可以重新規劃指派給一個租用戶的實例，並將其配置給另一個租使用者。

可進一步細分具狀態資源，根據它們所維護的狀態類型。 持續性狀態 是需要永久儲存的數據。 在雲端解決方案中，您應該避免將持續性狀態儲存在計算層中。 請改用資料庫或記憶體帳戶等記憶體服務。 暫時性狀態 是暫時儲存的數據，其中包含唯讀記憶體內部快取，以及本機磁碟上暫存盤的儲存。

暫時性狀態通常有助於藉由減少後端記憶體服務的要求數目，來改善應用層的效能。 例如，當您使用記憶體內部快取時，您可能能夠提供讀取要求，而不需要連線到資料庫，也不需要執行您最近在服務另一個要求時所執行的密集查詢。

在延遲敏感應用程式中，快取凍結的成本可能會變得相當重要。 如果每個租戶需要快取不同的資料，多租戶解決方案可能會加劇此問題。 為了減輕此問題，某些解決方案會使用 工作階段親和性，以確保相同計算工作節點會處理特定使用者或租戶的所有要求。 雖然會話親和性可以改善應用層有效地使用其快取的能力，但也使得更難調整和平衡跨背景工作角色的流量負載。 需要仔細考慮這種取捨。 很多應用程式其實不需要啟用會話保持功能。

您也可以將數據儲存在外部快取中，例如 Azure Cache for Redis。 外部快取已針對低延遲數據擷取進行優化，同時讓狀態與計算資源隔離，因此可以個別調整和管理它們。 在許多解決方案中，外部快取可讓您改善應用程式效能，同時讓計算層保持無狀態。

重要

當您使用記憶體內部快取或其他維護狀態的元件時，請避免在租用戶之間洩漏數據。 例如，請考慮在所有快取索引鍵前加上租使用者識別符號，以確保每個租戶的資料都是隔離的。

隔離

當您設計多租戶計算層時，通常會有許多選項可以考慮租戶之間的隔離等級，包括部署 供所有租戶使用的共用計算資源、每個租戶的專用計算資源，或在這些極端之間的某些選項。 每個選項都有取捨。 為了協助您決定最適合您解決方案的選項，請考慮您的隔離需求。

您可能擔心租戶的邏輯隔離，以及如何分隔套用至每個租戶的管理責任或政策。 或者，您可能需要針對特定租使用者部署不同的資源組態，例如部署特定的虛擬機 SKU 以符合租使用者的工作負載。

無論您選取哪一個隔離模型，請務必確認即使元件無法使用或故障，租用戶數據仍會保持適當隔離。 請考慮使用 Azure Chaos Studio 作為您常規自動化測試流程的一部分，故意引入模擬真實世界中斷的故障，並確認您的解決方案不會在租用戶之間洩漏資料，且即使在壓力下也能正常運作。

要考慮的方法和模式

自動調整

Azure 計算服務提供不同的功能來調整您的工作負載。 許多計算服務都支援自動調整，這需要您考慮何時應該調整，以及最小和最大規模層級。 調整可用的特定選項取決於您所使用的計算服務。 請參閱下列範例服務：

部署戳記模式

如需如何使用 部署戳記模式 來支援多租使用者解決方案的詳細資訊，請參閱 概觀。

計算資源匯總模式

計算資源整合模式 藉由共用基礎計算資源，幫助您在計算基礎結構上達到更高密度的使用者。 藉由共用計算資源，您通常能夠降低這些資源的直接成本。 此外，您的管理成本通常較低，因為要管理的元件較少。

不過，計算資源整合會增加 Noisy Neighbor 問題的可能性。 任何租使用者的工作負載可能會耗用大量可用的計算容量。 您通常可以藉由確保您適當地調整解決方案，以及套用配額和 API 限制等控件，以避免耗用超過其容量公平份額的租用戶來降低風險。

視您使用的計算服務而定，此模式會以不同的方式達成。 請參閱下列範例服務：

  • Azure App Service 和 Azure Functions：部署代表主控伺服器基礎結構的共用 App Service 方案。
  • Azure Container Apps：部署共用 環境。
  • Azure Kubernetes Service （AKS）：使用多租使用者感知應用程式部署共用 Pod。
  • 虛擬機：為所有租使用者部署單一虛擬機集。

每個租使用者的專用計算資源

您也可以為每個租使用者部署專用的計算資源。 專用資源藉由確保每個租用戶的計算資源與其他租用戶隔離，從而降低 Noisy Neighbor問題的風險。 它也可讓您根據每個租使用者的需求，為每個租用戶的資源部署不同的組態。 不過，專用資源通常成本較高，因為資源的租戶密度較低。

視您使用的 Azure 計算服務而定，您需要部署不同的專用資源，如下所示：

  • Azure App Service 和 Azure Functions：為每個租使用者部署個別的 App Service 方案。
  • Azure Container Apps：為每個租使用者部署個別的環境。
  • Azure Kubernetes Service （AKS）：為每個租使用者部署專用叢集。
  • 虛擬機：為每個租使用者部署專用的虛擬機。

半隔離的計算資源

半隔離的方法需要您在隔離組態中部署解決方案的各個層面，同時共用其他元件。

當您使用 App Service 和 Azure Functions 時，您可以為每個租使用者部署不同的應用程式，而且您可以在共用的 App Service 方案上裝載應用程式。 此方法可降低計算層的成本，因為 App Service 方案代表計費單位。 它也可讓您將不同的組態和原則套用至每個應用程式。 不過，此方法會引入 吵雜鄰居問題的風險。

Azure Container Apps 可讓您將多個應用程式部署至共用環境，然後使用 Dapr 和其他工具來個別設定每個應用程式。

Azure Kubernetes Service （AKS） 和 Kubernetes 更廣泛地為多租使用者提供各種選項，包括：

  • 租使用者特定命名空間，用於租使用者特定資源的邏輯隔離，這些資源會部署到共用叢集和節點集區。
  • 共用叢集上的租戶特定節點或節點池。
  • 可能使用相同節點集區的租戶特定 Pod。

AKS 也可讓您套用 Pod 層級的管理策略，以減輕名為 Noisy Neighbor 的 問題。 如需詳細資訊，請參閱 應用程式開發人員在 Azure Kubernetes Service （AKS）中管理資源的最佳做法。

請務必注意 Kubernetes 叢集中的共用元件，以及這些元件可能會受到多租用戶的影響。 例如，Kubernetes API 伺服器是在整個叢集中使用的共享服務。 即使您提供租戶特定的節點集區來隔離租戶的應用程式工作負載，API 伺服器也可能遇到來自租戶的大量請求造成的競爭。

要避免的反模式

嘈雜鄰居反模式

當您部署租戶之間共用的元件時，Noisy Neighbor 問題 是潛在風險。 請確定您包含資源控管和監視，以降低租用戶計算工作負載受到其他租用戶活動影響的風險。

跨租用戶數據外洩

如果計算層未正確處理，則可能會導致跨租用戶數據外洩。 這通常不是您在 Azure 上使用多租使用者服務時必須考慮的事項，因為Microsoft在平台層提供保護。 不過，當您開發自己的多租使用者應用程式時，請考慮是否有任何共享資源（例如本機磁碟快取、RAM 和外部快取）是否可能包含另一個租使用者無意中檢視或修改的數據。

前端繁忙反模式

若要避免 忙碌前端反模式，請避免前端層執行許多工作，這些工作可由架構的其他元件或層處理。 當您為多租用戶解決方案建立共用前端時，此反模式特別重要，因為忙碌的前端會降低所有租用戶的體驗。

相反地，請考慮使用佇列或其他傳訊服務來使用異步處理。 此方法也可讓您根據不同租使用者的需求，套用 服務品質 （QoS） 控制。 例如，所有租使用者可能會共用一般前端層，但 支付較高服務等級的租使用者， 可能有一組較高的專用資源來處理其佇列訊息的工作。

無彈性或規模不足

多租戶解決方案通常會經歷突發的擴展模式。 共用元件特別容易發生此問題，因為突發負荷的範圍較大，而且當您擁有更多具有不同使用模式的租戶時，影響更大。

請確定您充分利用雲端的彈性和規模。 請考慮您是否應該使用 水平或垂直擴展，並使用自動擴展來自動處理負載尖峰。 測試您的解決方案，以瞭解它在不同負載層級下的行為。 請確保您包括在生產階段中預期的負荷量以及成長預期。 您可以使用完全受控的服務，例如 Azure Load Testing，以瞭解應用程式在壓力下的行為。

沒有快取反模式

沒有快取反模式 是解決方案的效能受到影響時，因為應用層會重複要求或重新計算跨要求重複使用的資訊。 如果您擁有可以在租戶之間或單一租戶內部之間共享的數據，將其快取可能是有意義的，以減少對後端或資料庫層的負載。

不必要的狀態性

「無快取」反模式的結果是，您也應該避免將不必要的狀態儲存在計算層中。 明確說明您維護狀態的位置和原因。 具有狀態的前端或應用層可以降低擴展能力。 有狀態計算層通常也需要會話親和性，這可能會降低您在工作者或節點之間有效負載平衡流量的能力。

請考慮您在計算層中維護的每一項狀態的取捨，以及這些取捨是否會影響您在租戶的工作負載模式變更時進行調整或成長的能力。 您也可以將狀態儲存在外部快取中，例如 Azure Cache for Redis。

貢獻者

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主要作者：

  • Azure FastTrack 資深客戶工程師 Dixit Arora
  • John Downs |首席軟體工程師

其他參與者：

後續步驟

檢閱計算服務的服務特定指引：