多租用戶系統會在兩個或多個租用戶之間共享資源。 由於租使用者使用相同的共享資源，因此一個租用戶的活動可能會對另一個租用戶的系統使用產生負面影響。
問題說明
當您建置服務以由多個客戶或租用戶共享時，您可以將它建置為 多租使用者。 多租用戶系統的優點是資源可以在租用戶之間共用和共用。 這通常會導致成本降低並提高效率。 不過，如果單一租使用者使用系統中可用的資源數量不成比例，系統的整體效能可能會受到影響。 當某個租使用者的效能因為另一個租用戶的活動而降低時，就會發生嘈雜的鄰近問題。
請考慮具有兩個租使用者的範例多租用戶系統。 租使用者 A 的使用模式和租使用者 B 的使用模式重合。 在尖峰時間，租使用者 A 會使用系統的所有資源，這表示租使用者 B 所做的任何要求都會失敗。 換句話說，總資源使用量高於系統的容量：
到達第一個租使用者的要求可能會優先。 然後，另一個租使用者將遇到嘈雜的鄰居問題。 或者，這兩個租使用者可能會發現其效能受到影響。
即使每個個別租使用者耗用相對較少的系統容量，但許多租用戶的集體資源使用量會導致整體使用量達到尖峰時，也會發生嘈雜的鄰近問題：
當您有多個租使用者具有類似的使用模式，或尚未布建足夠的容量供系統上的集體負載使用時，就會發生此情況。
如何修正問題
當您共用單一資源時，嘈雜的鄰居問題是固有的風險，而且無法完全消除受到嘈雜鄰居影響的可能性。 不過，客戶端和服務提供者可以採取一些步驟，以減少吵雜的鄰居問題的可能性，或在觀察到它們時減輕其影響。
用戶端可以採取的動作
- 請確定您的應用程式會處理 服務節流，以減少對服務提出不必要的要求。 請確定您的應用程式遵循良好做法，重試 收到暫時性失敗回應的要求。
- 如果有的話，請購買保留容量。 例如，使用 Azure Cosmos DB 時，購買 保留的輸送量，以及使用 ExpressRoute 時， 針對對效能敏感的環境布建個別線路。
- 遷移至服務的單一租用戶實例，或具有更強隔離保證的服務層級。 例如，使用 服務匯流排、移轉至進階層，以及使用 Azure Cache for Redis 時，布建標準或進階層快取。
服務提供者可以採取的動作
- 監視系統的資源使用量。 監視整體資源使用量，以及每個租使用者所使用的資源。 設定警示以偵測資源使用量的尖峰，如果可能的話，請設定自動化，藉由 相應增加或相應放大來自動減輕已知問題。
- 套用資源控管。 請考慮套用原則，避免單一租用戶壓倒系統，並減少其他人可用的容量。 此步驟可能會透過節流模式或速率限制模式，採取配額強制執行的形式。
- 布建更多基礎結構。 如果您遵循分區化模式，或遵循部署戳記模式，此程式可能會牽涉到升級一些解決方案元件，或透過布建其他分區來相應放大。
- 讓租用戶購買預先布建或保留的容量。 此容量可讓租用戶更確定解決方案能充分處理其工作負載。
- 順暢處理租用戶的資源使用量。 例如，您可以嘗試下列其中一種方法：
- 如果您裝載解決方案的多個執行個體，請考慮在執行個體或縮放單位之間重新平衡租用戶。 例如，請考慮在多個戳記上放置具有可預測且類似使用模式的租使用者，以平整其使用量的尖峰。
- 請考慮您是否有背景處理程序或資源密集型工作負載，這些工作負載不區分時間。 在離峰時間以異步方式執行這些工作負載，以保留時間敏感工作負載的尖峰資源容量。
- 檢查下游服務是否提供控件，以減輕嘈雜的鄰近問題。 例如，使用 Kubernetes 時， 請考慮使用 Pod 限制，以及使用 Service Fabric 時， 請考慮使用內建治理功能。
- 限制租用戶可執行的作業。 例如，限制租使用者執行將執行非常大型資料庫查詢的作業，例如指定查詢的最大可傳回記錄計數或時間限制。 此動作可降低租用戶採取可能對其他租使用者造成負面影響之動作的風險。
- 提供服務品質 （QoS） 系統。 當您套用 QoS 時，您會優先處理某些進程或工作負載，再排定其他進程或工作負載的優先順序。 藉由將 QoS 納入您的設計和架構，您可以確保高優先順序的作業在資源有壓力時優先。
考量
在大部分情況下，個別租使用者不打算造成嘈雜的鄰近問題。 個別租使用者甚至可能不知道其工作負載對其他人造成嘈雜的鄰近問題。 不過，某些租使用者也可能利用共用元件中的弱點來個別攻擊服務，或藉由執行分散式阻斷服務 （DDoS） 攻擊。
無論原因為何，請務必將這些問題視為資源治理問題，以及套用使用量配額、節流和治理控件來減輕問題。
注意
請確定您告訴用戶端您套用的任何節流，或您服務上的任何使用量配額。 請務必可靠地處理失敗的要求，而且您套用的任何限制或配額並不感到驚訝。
如何偵測問題
從客戶端的觀點來看，嘈雜的鄰近問題通常會顯示為服務失敗的要求，或要求需要很長的時間才能完成。 特別是，如果相同的要求在其他時間成功，而且似乎隨機失敗，則可能有一個嘈雜的鄰居問題。 用戶端應用程式應該記錄遙測，以追蹤服務要求的成功率和效能，應用程式也應該記錄基準效能計量以供比較之用。
從服務的觀點來看，嘈雜的鄰近問題可能會以數種方式出現：
- 資源使用量尖峰。 請務必清楚瞭解一般基準資源使用量，以及設定監視和警示來偵測資源使用量的尖峰。 請確定您考慮可能會影響服務效能或可用性的所有資源。 這些資源包括伺服器 CPU 和記憶體使用量、磁碟 IO、資料庫使用量、網路流量，以及受控服務所公開的計量，例如要求數目和綜合和抽象效能計量，例如 Azure Cosmos DB 要求單位。
- 對租使用者執行作業時發生失敗。 特別是，尋找租使用者未使用大部分系統資源時發生的失敗。 這類模式可能表示租使用者是吵雜鄰居問題的受害者。 請考慮依租使用者追蹤資源耗用量。 例如，使用 Azure Cosmos DB 時，請考慮記錄每個要求所使用的要求單位，並將租使用者的標識元新增為遙測維度，以便匯總每個租使用者的要求單位耗用量。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- John Downs |首席軟體工程師
其他投稿人：
- 查德·基特爾 |首席軟體工程師
- Paolo Salvatori |適用於 Azure 的主要客戶工程師 FastTrack
- 丹尼爾·斯科特-倫斯福德 |合作夥伴技術策略師
- 阿森·弗拉基米爾斯基 | 適用於 Azure 的主要客戶工程師 FastTrack
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。