这是来自许多“获得 AWS 认证!”网站的问题。此类问题的目的是确定您对 AWS 的了解是否足以通过认证获得官方认可。如果您只是向人们询问正确答案,那么您只是在学习答案……而不是实际知识!
如果您真的研究过 Auto Scaling 并考虑过,以下是您应该考虑的一些事情。我提供这些信息是希望您真正了解 AWS,而不仅仅是记住答案(这在现实世界中对您没有帮助)。
扩大/缩小与扩大/缩小
Auto Scaling 就是在需要时(例如在负载高峰期)启动额外的 Amazon EC2 实例,并在不再需要时终止它们,从而省钱。
由于正在添加和删除实例,这称为向外扩展和向内扩展。尽量避免使用诸如 Scaling Up 和 Scaling Down 之类的术语,因为它们表明实例正在变得越来越小(事实并非如此)。
每小时进行多次横向扩展和缩减
此陈述中的假设是不需要这样的缩放,这是正确的。 Amazon EC2 按小时收费,因此添加实例并在短时间内删除它们是浪费金钱。这称为抖动。
一般来说,快速向外扩展并缓慢地向内扩展是个好主意。当系统需要额外的容量(横向扩展)时,它会希望它能够相当快地满足需求。当它不再需要那么多容量时,可能值得在缩减之前等待,因为此后需求可能会很快再次增加。
因此,获得正确的警报以触发缩放操作并等待一段时间再尝试再次缩放非常重要。
在保持弹性的同时优化成本
当一个考题陈述优化时,它会暗示您的主要目标应该是成本最小化,即使其他选择可能更有意义。因此,您希望解决方案尽可能缩小,同时避免颠簸。
终止政策
当触发 Auto Scaling 策略以删除实例时,Auto Scaling 使用 termination policy 来确定要删除的实例。因此,这与问题无关,因为在保持弹性的同时优化成本只受实例数量的影响,而不是实际终止的实例。
CloudWatch 警报
CloudWatch 警报可以触发 Auto Scaling 操作,例如“平均 CPU 。具有较长时间段的规则意味着它将对长期变化而不是临时变化做出反应,这肯定有助于避免颠簸。但是,这也意味着 Auto Scaling 将需要更长的时间来响应需求变化。
冷却时间
来自Auto Scaling documentation:
Auto Scaling 冷却时间是 Auto Scaling 组的可配置设置,有助于确保 Auto Scaling 在之前的扩展活动生效之前不会启动或终止其他实例。在 Auto Scaling 组使用简单的扩展策略动态扩展后,Auto Scaling 等待冷却时间完成,然后再恢复扩展活动。
这非常有用,因为新启动的实例需要一些时间(例如启动、配置)才能承担一些应用程序工作负载。如果冷却时间太短,那么 Auto Scaling 可能会在第一个实例准备好之前启动其他实例。结果是会启动太多实例,这意味着一些实例需要在不久之后进行缩减,从而导致更多的抖动。
计划的操作
Auto Scaling 可以配置为使用计划操作,而不是根据指标触发 Scale In 和 Scale Out 操作。例如,在预计高峰期之前的早上 8 点增加实例的最小数量,并在使用量开始下降的下午 6 点减少最小数量。
计划的操作不太可能导致抖动,因为扩展是基于计划而不是经常变化的指标。
正确答案
正确答案是……我不会告诉你的!但是,通过阅读上述信息并尝试grok Auto Scaling 的工作原理,您有望更好地理解该问题并得出合适的答案。
这样,您将学到一些东西,而不是merely memorizing the answers。