本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 擴展政策設計的最佳做法
<a name="best-practices-for-scaling-policy-design"></a>

## 結合擴展政策
<a name="combine-scaling-policies"></a>

 許多客戶選擇將不同類型的擴展政策結合在一個叢集中，以提高 AppStream 2.0 版 Auto Scaling 的功能和靈活性。例如，您可以設定排程擴展政策，以便預期使用者開始工作日的上午 6:00，將叢集的最小值增加至少，並在使用者停止工作之前在下午 4:00 減少叢集的最小值。您可以將此排程的擴展政策與目標追蹤或步驟擴展政策結合使用，以維持特定的使用率層級，並在白天進入或縮小以處理尖峰使用量。排程擴展和目標追蹤擴展的結合，有助於在立即需要容量時減少使用率層級急劇增加的影響。

## 避免擴展流失
<a name="avoid-scaling-churn"></a>

 請考慮您的機隊是否可能因為您的使用案例而遭受高度流失。當大量使用者在短時間內開始然後結束工作階段時，就會發生流失。當許多使用者在登出之前，在短短幾分鐘內同時存取叢集中的應用程式時，可能會發生這種情況。

 在這種情況下，您的叢集規模可能會遠低於所需容量，因為使用者結束工作階段時，執行個體就會結束。步驟擴展政策可能無法快速新增執行個體以抵消客戶流失，因此，您的叢集卡在特定大小上。

 您可以通過檢查車隊的 CloudWatch 指標來識別流失率。您的叢集具有非零擱置容量而未變更 (或極少變更) 所需容量的期間，表示可能會發生高流失率。若要解決高流失情況，請使用目標追蹤擴展政策並挑選目標使用率，使 (100 — 目標使用率百分比) 在 15 分鐘內超過流失率。例如，如果有 10% 的叢集因使用者流失而在 15 分鐘內結束，請將容量使用率目標設定為 90% 或更低，以抵消高流失率。

## 瞭解最高佈建速率
<a name="understand-maximum-provisioning-rate"></a>

 為大量使用者管理 AppStream 2.0 叢集的客戶應考慮佈建速率限制。此限制將影響執行個AWS 帳戶體新增至叢集或.

 有兩個限制需要考慮：
+  對於單一叢集，以每分鐘 20 個執行個體的最高速率佈建 AppStream 2.0。
+  對於單一 AppStream 2.0 佈建AWS 帳戶，速率為每分鐘 60 個執行個體 (每分鐘突發 100 個執行個體)。

 如果 parallel 擴充超過三個叢集，則帳戶佈建速率限制會在這些叢集之間共用 (例如，六個 parallel 擴充叢集可以每分鐘佈建最多 10 個執行個體)。此外，請考慮指定串流執行個體完成佈建以回應擴展事件的時間量。對於未加入使用中目錄網域的叢集，通常為 15 分鐘。對於加入活動目錄網域的叢集，這可能需要長達 25 分鐘的時間。

 鑑於這些限制，請考慮下列範例：
+  如果您想要將單一叢集從 0 擴展到 1000 個執行個體，則需要 50 分鐘 (每分鐘 1000 個執行個體 /20 個執行個體) 才能完成佈建，然後再花 15 到 25 分鐘的時間讓使用者使用所有執行個體，總共 65-75 分鐘。
+  如果您想要同時將三個叢集從 0 擴展到 333 個執行個體 (中總共有 999 個執行個體AWS 帳戶)，則所有叢集大約需要 17 分鐘 (每分鐘 999/60 個執行個體) 才能完成佈建，然後再額外 15 分鐘讓使用者使用這些執行個體，總計 32-42 分鐘。

## 利用多個可用區域
<a name="utilize-multiple-availability-zones"></a>

 為您的叢集部署選擇區域中的多個 AZ。當您為叢集選取多個 AZ 時，您的叢集可以新增執行個體以回應擴展事件的可能性。此指 CloudWatch 標 PendingCapacity 是評估叢集 AZ 設計在大型叢集部署中如何最佳化的起點。的持續值較高 PendingCapacity 可表示需要延伸水平 (跨 AZ) 縮放。如需詳細資訊，請參閱[https://docs.aws.amazon.com/appstream2/latest/developerguide/monitoring.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/monitoring.html)。

 例如，如果 auto Scaling 嘗試佈建執行個體以增加叢集的大小，而選取的 AZ 容量不足，則 auto Scaling 會改為在您為叢集指定的其他 AZ 中新增執行個體。如需可用區域和 AppStream 2.0 設計的詳細資訊，請參閱本文件中的[**可用區域**](availability-zones.md)。

## 監視容量不足錯誤度量
<a name="monitor-insufficient-capacity-error-metrics"></a>

 「容量不足錯誤」是 AppStream 2.0 車隊的 CloudWatch 指標。此測量結果指定因容量不足而拒絕的階段作業要求數目。

 當您變更資源調整原則時，建立 CloudWatch 警示以在發生任何容量不足錯誤時通知您很有幫助。這可讓您快速調整擴展政策，以最佳化使用者的可用性。管理指南提供[https://docs.aws.amazon.com/appstream2/latest/developerguide/monitoring.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/monitoring.html)詳細步驟。