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