優化調整和分割的建議
適用于此 Azure Well-Architected Framework 效能效率檢查清單建議：
| PE：05 | 優化調整和分割。 併入可靠且受控制的調整和資料分割。 工作負載的縮放單位設計是調整和分割策略的基礎。 |
|---|
本指南說明調整和分割工作負載的建議。 調整是能夠根據需求增加或減少配置給工作負載的資源。 資料分割牽涉到將工作負載分割成較小的可管理單位，以將資料和處理分散到多個資源。 未調整或分割區的工作負載可能會在高需求期間遇到效能不佳，且低需求期間使用量過低的容量。
定義
| 詞彙 | 定義 |
|---|---|
| 自動擴縮 | 功能，可根據預先定義的設定自動調整服務的容量限制，以視需要相應增加或減少。 |
| 容量 | 指定服務或功能的上限或最大容量。 |
| 用戶端親和性 (會話親和性) | 將要求從單一用戶端刻意路由傳送到單一伺服器實例，以協助確保會話管理一致。 |
| 分散式資料庫 (一致性) | 分散式資料庫中多個節點的資料統一性，可確保所有複本在指定時間點都有相同的資料。 |
| 關係資料庫 (一致性) | 將資料庫從一個有效狀態帶入另一個狀態的交易屬性，維護資料完整性。 |
| 一致性層級 | 設定，定義在分散式資料庫系統中複寫資料的方式和時機，判斷一致性與效能之間的取捨。 |
| 資料鎖定 | 用來防止同時更新相同資料的機制。 |
| 水平調整規模 | 調整方法，可新增指定類型的資源實例。 |
| 開放式並行存取 | 更新使用快照集進行更新之資料庫的方法，而不是傳統的鎖定機制。 |
| 資料分割 | 實際將資料分割成個別資料存放區的程式。 |
| 可擴縮性 | 工作負載能夠動態變更其容量限制，以因應不同需求層級。 |
| 縮放單位 | 可依比例調整的資源群組。 |
| 狀態親和性 | 在單一伺服器上儲存用戶端會話資料，讓相同的伺服器處理來自相同用戶端的後續要求。 |
| 垂直規模調整 | 將計算容量新增至現有資源的調整方法。 |
主要設計策略
調整和分割都有助於效能效率，方法是確保資源有效率地使用，而且工作負載可以處理不同的負載。 這些做法在應用程式需要有彈性且可適應變更需求的雲端環境中特別重要。 調整可確保您可以擴充工作負載容量，以符合增加的需求。 資料分割可讓您有效率地分割工作或資料，以處理這些成長的需求。 這兩個程式的基礎是工作負載的縮放單位設計。 它會決定工作負載應該如何成長和散發工作。 藉由納入調整和分割的可靠且受控制的方法，您可以避免潛在的工作負載效率不佳。
優化調整
優化調整是調整伺服器、實例或資源數目以符合工作負載變動需求的程式。 它可確保工作負載可以處理增加的流量或需求，而不會發生效能降低或停機時間。
選擇調整策略
選擇調整策略牽涉到決定垂直或水準方法，以根據工作負載的特定需求來增強工作負載的容量。 選取正確的策略可確保資源有效率地調整，以符合工作負載需求，而不會過度使用或浪費。 若要選擇正確的調整策略，您必須瞭解垂直和水準調整的使用案例，以及它們如何符合工作負載的需求。
瞭解垂直調整。 使用垂直調整，您可以增加單一資源的容量，例如升級至較大的伺服器或實例大小。 當工作負載可以受益于單一實例內增加的處理能力、記憶體或其他資源時，垂直調整就很有用。 垂直調整適用于不容易分成較小部分的工作負載，或當應用程式架構不支援水準調整時。
瞭解水準調整。 使用水準調整，您可以新增更多實例或資源，以將工作負載分散到多部伺服器。 水準調整提供優點，例如改善的復原能力、增加的容量，以及處理增加的流量或工作負載需求的能力。 它適用于設計成在多個節點上執行的雲端原生應用程式。 水準調整適用于可分割成個別執行的較小部分的工作負載。
瞭解工作負載。 垂直或水準調整的適用性取決於工作負載的特定特性和需求。 下列領域的一般效能監視和測試可協助優化一段時間的調整策略：
需求：考慮資源需求、延展性需求和工作負載限制等因素，瞭解工作負載的特定需求。
縮放單位：為預期一起調整的元件建立縮放單位設計。 例如，100 部虛擬機器可能需要兩個佇列和三個儲存體帳戶來處理額外的工作負載。 縮放單位為 100 部虛擬機器、兩個佇列和三個儲存體帳戶。 您應該獨立調整體驗容量使用波動的所有元件。
架構：評估應用程式架構的設計。 某些應用程式原本可能會設計成水準調整，而無狀態元件可以輕鬆地分散到多個實例。 其他應用程式可能有具狀態的元件或相依性，可讓垂直調整更適當。 評估工作負載的延展性和彈性需求。
設計要調整的基礎結構
設計要調整的基礎結構是建立架構的程式，可視需要新增或調整資源來處理增加的需求和工作負載。 它牽涉到規劃和實作可水準或垂直調整以容納成長的解決方案。 策略包括避免單一專案可能會成為瓶頸，並分離應用程式元件，以確保獨立延展性。 當您將工作負載設計為可調整時，它可以有效地將工作負載分散到多個資源，以防止瓶頸並最大化資源使用率。
避免單一。 您應該避免針對整個工作負載使用單一集中式資源。 相反地，將您的工作負載分散到多個資源，以取得更佳的延展性、容錯和效能。 探索一些特定的範例和設計考慮，以避免工作負載資源中的單一：
佇列型負載撫平：不要依賴單一佇列來處理訊息，而是考慮將工作負載分割到多個佇列，以分散處理負載。 它提供更佳的延展性和平行處理。
資料處理：單一模式通常會出現在資料處理案例中，其中處理不會展開。將長時間執行的工作分成較小的工作，以更妥善地將工作負載分散到多個資源，並利用平行處理原則。
設計模式：設計模式，例如 展開扇出/風扇 或 管道和篩選 ，有助於避免工作流程中的單一。 這些模式可讓處理工作分散到多個資源，並提升延展性和彈性。
分離元件。 分離應用程式元件是設計延展性的重要層面。 它牽涉到將應用程式細分為較小的獨立元件，這些元件可以根據特定的工作負載需求獨立運作和調整。 例如，如果某個元件因為需求增加而需要更多資源，您可以調整該元件，而不會影響其他元件。 此彈性可確保有效率的資源配置，並防止瓶頸。 藉由分離元件，您可以隔離失敗，並將整體應用程式的影響降到最低。 如果某個元件失敗，其他元件可以繼續獨立運作。
分離的元件更容易維護和更新。 您可以變更或更新一個元件，而不會影響其他元件，因為它們是獨立的。 請遵循下列指導方針來分離應用程式元件以進行延展性：
區分考慮：識別應用程式的責任和功能。 根據責任的特定工作，將責任分成個別的元件。 例如，您可能有個別的元件來進行使用者驗證、資料處理和 UI。
鬆散結合：設計元件以透過定義完善的介面和通訊協定彼此通訊。 此設計可減少元件之間的相依性，並可讓您更輕鬆地取代或調整個別元件。
非同步通訊：使用非同步通訊模式，例如訊息佇列或事件驅動架構，進一步分離元件。 這些模式可讓元件以自己的步調獨立處理工作，以改善整體延展性。
微服務：請考慮實作微服務，這些微服務是小型的獨立服務，這些服務著重于特定商務功能。 每個微服務都可以獨立開發、部署和調整，以提供更大的彈性和延展性。
設計要調整的應用程式
當您調整工作負載時，應該設計應用程式來分散負載。 只是因為您可以在基礎結構層級新增更多複本，並不表示您的應用程式可以使用複本。 設計要調整的應用程式是建構應用程式，以便透過將其工作負載分散到資源，以處理增加的需求。 盡可能避免需要單一實例的用戶端親和性、資料鎖定或狀態親和性的解決方案。 您想要將用戶端或進程路由傳送至具有可用容量的資源。 若要設計應用程式延展性，請考慮下列策略：
消除伺服器端會話狀態。 您應該盡可能將應用程式設計為無狀態。 針對具狀態應用程式，您應該使用伺服器外部的狀態存放區。 外部化會話狀態是將會話資料儲存在應用程式伺服器或容器之外的做法。 您可以將會話狀態外部化，以將會話資料分散到多部伺服器或服務，在分散式環境中啟用順暢的會話管理。 將會話狀態外部化時，請考慮下列事項：
評估您的會話需求。 瞭解需要儲存和管理的會話資料。 請考慮會話屬性、會話逾時，以及會話複寫或持續性的任何特定需求。 決定會話狀態的大小，以及讀取和寫入作業的頻率。
選擇解決方案。 選取符合效能和延展性需求的儲存體解決方案。 選項包括使用分散式快取、資料庫或會話狀態服務。 當您選擇時，請考慮資料一致性、延遲和延展性等因素。
設定您的應用程式。 更新您的應用程式以使用所選的會話狀態儲存體解決方案。 您可能需要變更應用程式的組態檔或程式碼，以連線到外部儲存體服務。
更新邏輯。 變更應用程式的會話管理邏輯，以儲存和擷取外部儲存體解決方案中的會話資料。 您可能需要使用儲存體解決方案提供的 API 或程式庫來管理會話狀態。
消除用戶端親和性。 用戶端親和性也稱為會話親和性或黏性會話。 當您消除用戶端親和性時，會將用戶端要求平均分散到多個複本或伺服器，而不會將所有要求從用戶端路由傳送至相同的複本。 此設定可藉由允許任何可用的複本處理要求，來改善應用程式的延展性和效能。
檢閱負載平衡演算法。 負載平衡演算法可能會導致意外和人工用戶端釘選，其中傳送太多要求至一個後端實例。 如果演算法設定為一律將相同使用者的要求傳送至相同的實例，就可能發生釘選。 如果要求彼此太類似，也可能會發生此情況。
消除資料鎖定。 資料鎖定可確保一致性，但效能有缺點。 這可能會導致鎖定擴大，並對並行、延遲和可用性造成負面影響。 若要消除資料鎖定，您應該實作 開放式平行存取。 非關係資料庫應該使用 開放式並行控制 ，並具有正確的 一致性層級。 您的資料分割策略也應該支援您的並行需求。
使用動態服務探索。 動態服務探索是在分散式系統中自動偵測和註冊服務的程式。 它可讓用戶端探索可用的服務，而不需要緊密結合至特定實例。 用戶端不應該能夠直接相依于工作負載中的特定實例。 若要避免這些相依性，您應該使用 Proxy 來散發和轉散發用戶端連線。 Proxy 可作為用戶端與服務之間的媒介，提供一層抽象概念，可讓服務加入或移除，而不會影響用戶端。
使用背景工作。 調整應用程式時，它可以處理增加的工作負載或較高的並行要求數目。 將大量工作卸載為背景工作，可讓主要應用程式處理使用者要求，而不需要大量資源作業。 請遵循下列步驟，將工作卸載為背景工作：
在您的應用程式中尋找可卸載的 CPU 密集和 I/O 密集工作。 這些工作通常牽涉到大量計算或與外部資源互動，例如資料庫或網路作業。
設計您的應用程式以支援背景工作。 將大量工作與主要應用程式邏輯分離，並提供啟動和管理背景工作的機制。
使用適當的技術或架構實作背景工作處理。 包含程式設計語言或平臺所提供的功能，例如非同步程式設計、執行緒或工作佇列。 在個別的工作或執行緒中包含大量作業，這些工作可以同時執行，或排程在特定間隔執行。
如果有許多背景工作，或工作需要大量時間或資源，則散發背景工作。 Competing Consumers Pattern (競爭取用者模式)提供了一個可能的解決方案。
設定縮放
設定調整是設定和調整參數，以根據工作負載需求動態配置資源的程式。 其中包含使用自動調整功能、瞭解服務調整界限，以及實作有意義的負載計量等策略。 適當的設定可確保應用程式可以回應不同的需求，同時將效率最大化。 當您設定調整時，請考慮下列策略：
搭配自動調整使用服務。 自動調整功能會自動調整基礎結構以符合需求。 使用平臺即服務 (PaaS) 內建的自動調整功能供應專案。 PaaS 上的調整容易是一個主要優點。 例如，相應放大虛擬機器需要個別的負載平衡器、用戶端要求處理和外部儲存狀態。 PaaS 供應專案會處理大部分的工作。
限制自動調整。 設定自動調整限制，以將可能導致不必要的成本的過度調整降到最低。 有時候您無法設定調整限制。 在這些情況下，您應該設定警示，以在元件達到最大縮放限制和過度調整時通知您。
瞭解服務調整界限。 當您瞭解服務調整限制、遞增和限制時，您可以在選取服務時做出明智的決策。 調整界限會決定您選擇的服務是否可以處理預期的工作負載、有效率地調整，以及符合應用程式的效能需求。 要考慮的調整界限包括：
調整限制：調整限制是位置或服務可以處理的最大容量。 請務必瞭解這些限制，以協助確保服務可以容納預期的工作負載，並處理尖峰使用量，而不會降低效能。 每個資源都有上限。 如果您需要超出規模限制，您應該分割工作負載。
縮放增量：服務會依定義的遞增進行調整。 例如，計算服務可能會依實例和 Pod 進行調整，而資料庫可能會依實例、交易單位和虛擬核心進行調整。 請務必瞭解這些遞增，以優化資源配置，並防止資源 Flapping。
調整限制：某些服務可讓您相應增加或相應放大，但限制自動反向調整的能力。 您必須手動調整規模，或可能需要重新部署新的資源。 這些限制通常是保護工作負載。 相應減少或相應縮小可能會影響工作負載的可用性和效能。 服務可能會強制執行某些限制或限制，以協助確保工作負載有足夠的資源可有效地運作。 這些限制可能會影響資料一致性和同步處理，特別是在分散式系統中。 服務在相應增加或相應放大期間可能會有處理資料複寫和一致性的機制，但可能無法提供相應減少或縮小的相同層級支援。
使用有意義的負載計量。 調整應該使用有意義的負載計量作為調整觸發程式。 有意義的負載計量包括簡單的計量，例如 CPU 或記憶體。 它們也包含更進階的計量，例如佇列深度、SQL 查詢、自訂計量查詢和 HTTP 佇列長度。 請考慮使用簡單和進階負載計量的組合作為調整觸發程式。
使用緩衝區。 緩衝區是未使用的容量，可用來處理需求尖峰。 設計良好的工作負載計畫，適用于非預期的工作負載尖峰。 您應該新增緩衝區來處理水準和垂直縮放的尖峰。
防止 flapping。 Flapping 是迴圈條件，會在某個縮放事件觸發相反的縮放事件時發生，建立連續的來回調整動作。 例如，如果 相應縮小可減少實例數目，可能會導致剩餘實例中的 CPU 使用量增加，並觸發向外延展事件。 相應放大事件接著會導致 CPU 使用量下降，重複程式。
請務必在向外延展和相應縮小閾值之間選擇適當的邊界，以避免 Flapping。 您可以藉由設定提供 CPU 使用量顯著差異的臨界值，來防止頻繁和不必要的相應縮小和相應放大動作。
使用部署戳記。 有一些技術可讓您更輕鬆地調整工作負載。 您可以使用 部署戳記 模式，藉由新增一或多個縮放單位，輕鬆地調整工作負載。
風險：雖然調整可藉由調整容量以符合需求來協助將成本優化，但可能會導致高需求期間的整體成本增加。
測試調整
測試調整牽涉到模擬受控制環境中的各種工作負載案例，以評估工作負載如何回應不同層級的需求。 這有助於確保工作負載有效率地調整，在各種負載期間將效能效率最大化。
您必須確保工作負載在真實世界中有效率地調整。 請務必在鏡像生產設定的環境中執行負載和壓力測試。 這些測試是在非生產環境中執行，可讓您評估垂直和水準調整策略，並判斷哪一個最能有效地優化效能。 以下是測試調整的建議方法：
定義工作負載案例。 識別您需要測試的主要工作負載案例，例如增加使用者流量、並行要求、資料量或資源使用量。
使用類似生產環境的測試環境。 根據基礎結構、組態和資料，建立與生產環境非常類似的個別測試環境。
設定效能計量。 定義要測量的效能計量，例如回應時間、輸送量、CPU 和記憶體使用率，以及錯誤率。
開發測試案例。 開發模擬不同工作負載案例的測試案例，逐漸增加負載，以評估各種層級的效能。
執行和監視測試。 使用定義的測試案例執行測試，並在每個負載層級收集效能資料。 監視工作負載行為、資源耗用量和效能降低。
分析和優化調整。 分析測試結果，以找出效能瓶頸、延展性限制或改善的領域。 優化設定、基礎結構或程式碼，以增強延展性和效能。 調整需要一段時間才能完成，因此請測試調整延遲的效果。
位址相依性。 尋找潛在的相依性問題。 在工作負載的某個區域中調整或分割可能會導致相依性發生效能問題。 工作負載的具狀態部分，例如資料庫，是相依性效能問題最常見的原因。 資料庫需要仔細設計才能水準調整。 您應該考慮量值，例如 開放式並行 存取或資料分割，以對資料庫啟用更多輸送量。
調整後重新測試。 在實作優化之後重複延展性測試，以驗證改善，並協助確保工作負載可以有效率地處理預期的工作負載。
取捨：考慮工作負載的預算條件約束和成本效益目標。 垂直調整可能會牽涉到較高的成本，因為需要更大型且更強大的資源。 水準調整可使用較小的實例來節省成本，這些實例可以根據需求新增或移除。
資料分割工作負載
資料分割是將大型資料集或工作負載分割成較小、更容易管理的部分的程式，稱為分割區。 每個分割區都包含資料或工作負載的子集，通常分別儲存或處理。 資料分割可啟用平行處理並減少爭用。 將工作負載分成較小的單位，可讓應用程式獨立處理每個單位。 結果是更妥善地使用資源和更快速的處理時間。 資料分割也可協助將資料分散到多個存放裝置，減少個別裝置上的負載並改善整體效能。
瞭解資料分割
您使用的特定資料分割方法取決於您擁有的資料或工作負載類型，以及您使用的技術。 分割的一些常見策略包括：
水準資料分割：在此方法中，資料集或工作負載會根據特定準則來分割，例如值範圍或特定屬性。 每個分割區都包含符合所定義準則的資料子集。
垂直資料分割：在此方法中，資料集或工作負載會根據特定屬性或資料行來分割。 每個分割區都包含資料行或屬性的子集，允許更有效率地存取所需的資料。
功能分割：在此方法中，資料或工作負載會根據需要執行的特定功能或作業來分割。 每個分割區都包含特定函式所需的資料或元件，可啟用優化的處理和效能。
規劃資料分割
請務必考慮資料分佈、查詢模式、資料成長，以及資料分割時的工作負載需求等因素。 適當的規劃和設計是協助確保資料分割的有效性，並將效能效率最大化的必要條件。 如果您以事後方式處理資料分割，則因為您已經有即時工作負載可維護，所以更具挑戰性。 您可能需要變更資料存取邏輯、將大量資料分散到分割區，以及在資料散發期間支援繼續使用。
實作資料分割
決定要使用的分割類型時，請務必分析資料的特性、存取模式、並行需求和延展性目標。 每種資料分割類型都有自己的優點和考慮。 以下是每種資料分割類型需要考慮的一些因素：
當您想要將資料分散到多個資源或伺服器，以取得更佳的延展性和效能時，水準資料分割就適合使用。 當工作負載可以在每個分割區上獨立平行處理時有效。 當多個使用者或進程必須能夠同時存取或更新資料集時，請考慮水準資料分割。
當經常存取某些屬性或資料行時，垂直資料分割是適當的，而其他屬性或資料行則較不常存取。 垂直資料分割可將不必要的資料擷取降至最低，以有效率地存取所需的資料。
當不同的函式需要不同的資料子集，而且可以獨立處理時，功能資料分割就適用。 功能分割可讓每個分割區將特定作業放在一起，以優化效能。
測試和優化資料分割
測試資料分割配置，以確認策略的有效性和效率，讓您可以進行調整以改善效能。 測量因素，例如回應時間、輸送量和延展性。 比較結果與效能目標，並找出任何瓶頸或問題。 根據分析，找出潛在的優化機會。 您可能需要跨分割區轉散發資料、調整資料分割大小，或變更資料分割準則。
資料扭曲：資料分割可能會導致資料扭曲，其中，某些分割區相較于其他人會收到不成比例的資料量或工作負載。 資料扭曲可能會導致效能不平衡，並增加特定分割區上的競爭。
查詢效能：設計不佳的資料分割配置可能會對查詢效能造成負面影響。 如果查詢需要跨多個分割區存取資料，可能需要在分割區之間進行額外的協調和通訊，進而增加延遲。
Azure 指導
優化調整規模。 Azure 具有基礎結構容量，可支援垂直和水準調整。 Azure 服務有不同的效能層級，稱為 SKU。 SKU 可讓您垂直調整。 許多 Azure 資源都支援自動調整或其他就地調整選項。 某些資源支援進階計量或自訂輸入，以支援微調調整行為。 Azure 中大部分的調整實作都可以設定限制，並支援警示變更所需的可檢視性。
Azure 監視器 可讓您監視應用程式和基礎結構中的各種計量和條件。 您可以使用監視器，根據預先定義的規則引發自動化調整動作。 例如，在Azure Kubernetes Service (AKS) 中，您可以使用監視器來啟用水準 Pod 自動調整， (HPA) 和叢集自動調整。 使用監視器的監視和警示功能，您可以有效地在 Azure 中調整規模，並協助確保應用程式和基礎結構可以動態調整以符合需求。
您也可以在 Azure 中建置自訂自動調整。 您可以在 [監視] 中針對沒有自動調整功能的資源使用警示。 這些警示可以設定為查詢型或計量型，而且可以使用Azure 自動化來執行動作。 自動化提供跨 Azure、雲端和內部部署環境裝載和執行 PowerShell 和 Python 程式碼的平臺。 其提供功能，例如視需要部署 Runbook 或依排程、執行歷程記錄和記錄、整合式秘密存放區和原始檔控制整合。
設計要調整的應用程式：以下是 Azure 協助應用程式調整設計的一些方式;
消除資料鎖定：在 Azure SQL 資料庫中，您可以啟用優化鎖定，以改善需要嚴格一致性之資料庫的效能。
使用背景工作：Azure 提供實作背景工作的服務和指引。 如需詳細資訊，請參閱 背景工作。
實作負載平衡：Azure 提供不需要用戶端親和性的負載平衡器。 這些負載平衡器包括Azure Front Door、Azure 應用程式閘道和Azure Load Balancer。
分割工作負載：Azure 為不同的資料存放區提供各種資料分割策略。 這些策略可藉由將資料分散到多個分割區，協助改善效能和延展性。 如需詳細資訊，請參閱 資料分割策略。
相關連結
效能效率檢查清單
請參閱一組完整的建議。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應