扩缩策略设计的最佳实践

合并扩缩策略

许多客户选择将不同类型的扩缩策略组合到一个实例集中，以提高 AppStream 2.0 中自动扩缩的功能和灵活性。例如，您可以配置一个计划扩缩策略，以便在预计用户开始工作日的上午 6:00 增加实例集的最小值，并在用户停止工作之前的下午 4:00 减少实例集的最小值。您可以将此计划扩缩策略与目标跟踪或分布扩缩策略相结合，以保持特定的利用率水平，并在白天进行缩减或扩展以应对高峰使用量。当紧急需要容量时，计划扩缩和目标跟踪扩缩的组合有助于减少利用率级别急剧增加所产生的影响。

避免扩缩期间的流失

考虑一下您的实例集是否会因为您的使用案例而经历高度的流失。当大量用户在短时间内开始然后结束会话时，就会发生流失。当许多用户同时访问实例集中的某个应用程序几分钟就退出，可能会发生这种情况。

在这种情况下，您的实例集大小可能会远低于所需的容量，因为当用户结束会话时，实例就会结束。分步扩缩策略添加实例的速度可能不足以抵消流失，因此，您的实例集会停留在一定的大小。

您可以通过检查实例集的 CloudWatch 指标来识别流失情况。如果您的实例集的待处理容量不为零，而所需容量没有变化（或变化很小），则表明可能会出现高流失率。要考虑高流失情况，请使用目标跟踪扩缩策略并选择目标利用率，让（100 — 目标利用率百分比）在 15 分钟内大于流失率。例如，如果您的实例集中有 10% 将因用户流失而在 15 分钟内结束会话，请将容量利用率目标设置为 90% 或更低，以抵消高流失率。

了解最大配置速率

为大量用户管理 AppStream 2.0 实例集的客户应考虑配置速率限制。此限制将影响向某个实例集添加实例或向 AWS 账户 中的所有实例集添加实例的速度。

有两个限制需要考虑：

• 对于单个实例集，AppStream 2.0 的最大配置速率为每分钟 20 个实例。

• 对于单个 AWS 账户，AppStream 2.0 的配置速率为每分钟 60 个实例（爆发可达到每分钟 100 个实例）。

如果并行扩展的实例集超过三个，则账户配置速率上限将在这些实例集之间分摊（例如，并行扩展的六个实例集每个每分钟最多可以配置 10 个实例）。此外，还要考虑给定流式处理实例在响应扩展事件时完成配置所需的时间。对于未加入 Active Directory 域的实例集，这通常为 15 分钟。对于加入 Active Directory 域的实例集，这可能需要长达 25 分钟的时间。

考虑到这些限制，请看下面的例子：

• 如果您想将单个实例集从 0 扩展到 1000 个实例，则需要 50 分钟（每分钟 1000 个实例/20 个实例）才能完成配置，然后还需要 15-25 分钟才能使所有实例可供最终用户使用，总共需要 65-75 分钟。

• 如果您想同时将三个实例集从 0 扩展到 333 个实例（AWS 账户 完成），则所有实例集需要大约 17 分钟（每分钟 999/60 个实例）才能完成配置，然后再花 15 分钟使这些实例可供最终用户使用，总共需要 32-42 分钟。

利用多个可用区

在该区域中选择多个可用区进行实例集部署。当您为实例集选择多个可用区时，您的实例集能够添加实例以响应扩展事件的可能性就会增加。CloudWatch 指标 PendingCapacity 是评估大型实例集部署中实例集可用区设计的优化程度的起点。PendingCapacity 的持续高值可能表明需要扩展水平（跨可用区）扩展。有关更多信息，请参阅监控 Amazon AppStream 2.0 资源。

例如，如果自动扩缩尝试预配置实例以增加实例集的大小，而选定的可用区容量不足，则自动扩缩将改为在您为实例集指定的其他可用区中添加实例。有关可用区和 AppStream 2.0 设计的更多信息，请参阅本文档中的可用区。

监控容量不足错误指标

“容量不足错误”是 AppStream 2.0 实例集的 CloudWatch 指标。这一指标制定因缺少容量而被拒绝的会话请求的数量。

当您更改扩缩策略时，创建一个可以在出现任何容量不足错误时通知您的 CloudWatch 警报会很有帮助。这使您能够快速调整扩展策略，优化用户的可用区。管理指南提供了监控您的 AppStream 2.0 资源的详细步骤。