amazon-web-services - 确定性地创建和标记 EC2 实例

Question

我正在创建 3 个 EC2 实例，然后迭代并标记每个实例。
有时标签请求会失败，尽管实例后来似乎正在运行。

这可能是时间问题吗？创建实例后，我应该在标记它之前等待几秒钟吗？是否有确定性的方法来等待它开始？

Answer 1

更新 20140512
AWS 同时在 Troubleshooting API Request Errors 上添加了更详细的文档。 , 包括一个地址为 Eventual Consistency 的部分，这基本上证实了我在下面的初始答案中的分析:

The Amazon EC2 API follows an eventual consistency model, due to the distributed nature of the system supporting the API. This means that the result of an API command you run that affects your Amazon EC2 resources might not be immediately visible to all subsequent commands you run. [...]

[...] For example, [...] if you run a command to modify or describe the resource that you just created, its ID might not have propagated throughout the system, and you will get an error responding that the resource does not exist.

To manage eventual consistency, you can do the following:

• Confirm the state of the resource before you run a command to modify it. Run the appropriate Describe command using an exponential backoffalgorithm to ensure that you allow enough time for the previouscommand to propagate through the system. [...]

• Add wait time between subsequent commands, even if a Describe command returns an accurate response. Apply an exponential backoffalgorithm starting with a couple of seconds of wait time, and increasegradually up to about five minutes of wait time.

[emphasis mine]

请注意 : 大多数 AWS SDKs同时自动应用这些建议，包括调整默认重试策略或添加自定义实现的选项 - 参见 Error Retries and Exponential Backoff in AWS如果需要，有关如何自己实现的指导。

更新 20130719
AWS API 的最终一致性设计越来越多地被各种大型 AWS 用户遇到，他们自然需要更深入地研究并相应地解决它，例如，请参阅以下文章:

Dealing with Eventual Consistency in the AWS EC2 API (作者 Martin Englund，Cloud Foundry)

Dealing with the Inconsistent EC2 API (by Aaron Staley, PiCloud)

初步答复
正如已经 commented通过@datasage，AWS API 显然需要被普遍视为 eventually consistent仅 - 这在第一次遇到时肯定是出乎意料的，但事后看来，对于大规模服务(即工程响应)来说，这实际上并不太令人惊讶。操作权衡以解决 CAP theorem .
另请参阅我对 Alex Ciminian 问题的评论 Implementing idempotency for AWS Spot Instance Requests ，他在那里讨论了关于类似一致性问题的测试结果:

Interesting issue - [...] I've encountered various similar API delays inthe context of the Bamboo AWS Plugin and concluded that the AWS APIneeds to the treated as being eventually consistent only across theboard; e.g., I've even encountered cases where I received a resourceid from a create call, could tag the resource based on its id but notdescribe it thereafter still, because it supposedly doesn't exist(yet).

我在这里描述的内容似乎表明，每个 API 操作实际上都完全由 AWS 独立操作(不仅跨外部可见的服务，甚至在像 EC2 这样的单个服务中)，因此可能会受到最终一致性的影响，并且必须得到相应的对待。

有关上述案例的详细信息，您可能需要查看 Frequent polling of AWS API causes throttle limit ，在这里我总结了我们通过 AWS SDK for Java 中可用但有限的重试/退避功能改进处理的分析和方法。 - 解决方案几乎是理想的，但它目前似乎大大改善了情况。
同样，重新设计的 AWS SDK for PHP 2引入了专用的“Waiter”对象，允许您轮询资源直到它处于所需状态以解决问题，请参阅 Quick Start 中的 Waiters 部分。详情:

One of the high-level abstractions provided by the SDK is the conceptof “waiters”. Waiters help make it easier to work with eventuallyconsistent systems by providing an easy way to wait on a resource toenter into a particular state by polling the resource. [...] Any@method tag that starts with “waitUntil” will utilize a waiter.

$client->waitUntil('BucketExists', array('Bucket' => 'my-bucket'));