问题描述
我已经阅读了几乎整个文档，甚至超出了 AWS AS API 的范围，以了解所有 AS 内容.
I have read pretty much the entire documentation even beyond on the AWS AS API to understand all the AS stuff.
但是我仍然想知道(因为我想先从某人那里找到这个，所以我还没有真正使用过 API)我的场景是否适用于 AS.
However I am still wondering (without having actually used the API yet since I wanna find this out first from someone) if my scenario is viable with AS.
假设我在一个 AS 组中设置了一堆工作服务器，每个服务器都在处理一项工作，突然到了(我不知道，平均 CPU 大于或在另一种情况下小于 80%)扩展的时间或向下.
Say I got a bunch of work servers setup within an AS group all working on a job each and suddenly it comes the time (I dunno say, AVG CPU is greater than or in another case less than 80%) to scale up or down.
我主要担心的是失去目前正在进行的工作.也许这可以用一个例子更好地解释:
My main worry is the loss of a currently in progress job. Maybe this would be better explained with an example:
- 我启动了 5 个作业服务器，上面有 5 个作业
- 一项作业完成并在 Amazon API 中触发缩减触发器
- 亚马逊开始缩小规模
- 我丢失了一台当前正在运行作业的作业服务器(完成 90% 必须重新启动)
考虑到这一点，对我来说是只使用 Amazon Spot Instance/EC2 API 并管理自己的扩展更好，还是我对 Amazon API 如何判断服务器终止有什么遗漏?
With this in mind is it better for me to just use the Amazon Spot Instance/EC2 API and just manage my own scaling or is there something I am missing about how the Amazon API judges server terminations?
老实说，我更愿意根据 SQS 等待量而不是服务器上的一些健康数据来衡量:
To be honest I rather scale to SQS waiting amount than some health figure on the servers:
- 每等待 100 条消息，集群容量就会增加 20%
但这对于 AS 来说似乎也不太可行.
But this doesn't seem to be too viable with AS either.
AWS AS API 是否不是正确的解决方案，还是我遗漏了一些有关其工作原理的重要信息?
So is the AWS AS API not the right solution or am I missing some vital info about how it works?
谢谢，
推荐答案
经过一番搜索，我发现有两种可接受的方式来管理 AS API 或一般用于作业的 AS:
After some searching I found that there are two accepted ways to manage AS API or AS in general for jobs:
一种方法是直接从工作人员内部操纵服务器的健康状况.这是很多站点所做的并且很有效，当您的工作人员检测到系统中没有更多工作或冗余时，它会将其所在的服务器标记为不健康.通过这种方式，AS API 出现并在一段时间后自动将其关闭.
One method is to manipulate the health of a server directly from within the worker itself. This is what quite a few sites do and it is effective, when your worker detects no more jobs or redundancy in the system it marks the server it is on as unhealthy. This way the AS API comes along and automatically takes it down after a period of time.
因此，使用此方法，您将根据一段时间内的 SQS 队列大小制定扩展策略(例如，每 5 分钟的 SQS 消息超过 100 添加 2 个服务器；每 10 分钟的 SQS 消息超过 500网络容量增加 50%).缩减将由代码处理，而不是由活动策略处理.
So with this method you would have a scale up policy based on your SQS queue size over a period of time (say for every 5 mins of SQS messages being over 100 add 2 servers; every 10 mins of SQS messages being over 500 double network capacity by 50%). The scale down would be handled by code instead of an active policy.
这种方法也适用于零集群，因此您可以在不使用集群时将其一直关闭到没有服务器，从而使其具有成本效益.
This method would work with zero clusters too so you can down your cluster all the way to no servers when it's not being used making it quite cost effective.
优点:
- 易于设置
- 使用 AWS API 函数
- 可能是最快的设置
- 使用 AWS 托管 API 为您管理集群大小
缺点:
- 不使用完整的 AWS API 很难管理，即在创建新服务器时，如果不执行所有实例 ID 的完整 API 命令返回，就无法恢复它的实例 ID.如果您想要对集群进行自我控制，AWS AS API 在其他情况下会妨碍您并让您的生活变得更加艰难
- 依靠亚马逊了解什么最适合您的钱包.您依赖 Amazon API 来正确扩展，这对许多人来说是一个优势，但对某些人来说却是一个劣势.
- worker 必须包含您的一些服务器池代码，这意味着该 worker 不是通用的，并且不能在不更改配置的情况下立即移动到另一个集群.
考虑到这一点，还有第二个选择，DIY.您可以使用 EC2 Spot 实例和按需实例 API 根据您的自定义规则制作您自己的 AS API.这很容易解释:
With this in mind there is a second option, DIY. You use the EC2 Spot Instance and on Demand Instance API to make your own AS API based around your custom rules. This is pretty simple to explain:
- 你有一个 cli 脚本，当运行开始时，比如 10 个服务器
- 您有一个 cronjob，当检测到满足某些条件时，服务器会关闭或更多
优点:
- 轻松干净地管理您的终端
- 可以制作通用工作者
- 服务器池可以开始管理多个集群
- 您可以制定规则以及从 AWS 上的指标中获取数据并将其与比较和时间范围结合使用以了解事情是否应该发生变化.
缺点:
- 难以获得多区域(对 SQS 来说还不错，因为 SQS 是单个区域)
- 难以处理区域容量和工作量方面的错误
- 您必须依靠自己的服务器正常运行时间和自己的代码来确保 cronjob 正常运行，并按其应有的方式供应服务器，并在需要的时候将它们分解.
因此，对于最终用户来说，这似乎是一场更舒适的战斗.我个人仍在考虑这两者，并创建了一个小型自托管服务器池，它可以为我工作，但同时我很想尝试让它在 AWS 自己的 API 上工作.
So really it seems to be a battle of which is more comfortable for the end user. I personally am mulling the two still and have created a small self hosted server pooler that could work for me but at the same time I am tempted to try and get this to work on AWS' own API.
希望这对人们有所帮助，
Hope this helps people,
请注意，使用这两种方法中的任何一种，您仍然需要一个函数来预测您应该如何出价，因此您需要在您的现货类型(EC2 类型)上调用出价历史 API 并计算如何出价.
Note with either of these methods you will still require a function on your side to predict how you should bid, as such you will need to call the bid history API on your spot type (EC2 type) and compute how to bid.
另一个另一种自动检测系统冗余的方法是检查 SQS 队列的空响应指标.这是您的工作人员 ping 队列但未收到响应的次数.如果您在工作期间在应用中使用排他锁，这将非常有效.
Another Another way to automatically detect redundancy in a system is to check the empty responses metric for your SQS queue. This is the amount of times your workers have pinged the queue and received no response. This is quite effective if you use an exclusive lock in your app for the duration of the worker.
这篇关于用于作业服务器的 Amazon Auto Scaling API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！