共用方式為

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

  • 發行項

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

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

重要考慮和需求

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

調整

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

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

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

在應用程式負載不足的情況下，通常會一直偵測不到效能問題。 您可以使用完全受控的服務，例如 Azure 負載測試，來瞭解應用程式在壓力下的行為。

調整觸發程式

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

州/省

計算資源可以是 無狀態，也可以是 可設定狀態。 無狀態元件不會維護要求之間的任何數據。 從延展性的觀點來看，無狀態元件通常很容易相應放大，因為您可以快速新增背景工作角色、實例或節點，而且可以立即開始處理要求。 如果您的架構允許，您也可以重新規劃指派給一個租用戶的實例，並將其配置給另一個租使用者。

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

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

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

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

重要

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

隔離

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

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

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

要考慮的方法和模式

Autoscale

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

部署戳記模式

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

計算資源匯總模式

計算 資源匯總模式 可藉由共用基礎計算資源，協助您達到更高密度的租用戶到計算基礎結構。 藉由共用計算資源，您通常能夠降低這些資源的直接成本。 此外，您的管理成本通常較低，因為要管理的元件較少。

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

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

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

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

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

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

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

半隔離的計算資源

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

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

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 和外部快取）是否可能包含另一個租使用者無意中檢視或修改的數據。

忙碌前端反模式

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

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

不彈性或調整不足

多租用戶解決方案通常受限於高載規模模式。 共用元件特別容易發生此問題，因為高載的範圍較高，而且當您擁有更多具有不同使用模式的租使用者時，影響更大。

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

沒有快取反模式

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

不必要的具狀態

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

請考慮您在計算層中維護之每個狀態的取捨，以及它會影響您在租使用者工作負載模式變更時調整或成長的能力。 您也可以將狀態儲存在外部快取中，例如 Azure Cache for Redis。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

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

其他投稿人：

下一步

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