Amazon SNS消息的预期SLA(服务级别协议)是什么？

Question

我正在尝试评估SNS是否正在构建一个实时应用程序,并且需要在传递消息时快速转换时间<2秒.

由于我位于亚太地区,我在新加坡有一个SNS,在位于Us-east-1的Lambda有一个订户.

鉴于此设置,我运行了一个代码,试图找出调用lambda的延迟并进行零处理并记录时间.有人可能会说你在这种情况下也考虑了lambda调用延迟.这是真的.我需要调用Lambda并执行并在<2秒内回复.

我发送了23914条消息,其中我有平均653.520毫秒的传输+ lambda调用.峰值大约600995毫秒(约10分钟),这是像pubsub这样的技术的潜在延迟. lambda在<653毫秒内发送和接收大约20117条消息,这意味着3797个数据包或15%的消息比平均时间多.

2958条消息或12.36%消息需要1秒才能执行.调用和执行379条消息或1.59%需要超过2秒(这意味着1.6%的消息不能被视为实时且必须被忽略)超过10秒的82条消息64条消息超过20秒直到~45秒后延迟是10分钟.我有3包,延迟10分钟.

困扰我的是,我的消息中大约2%(如果你也包括处理时间)不能实时处理一小部分~24K消息.

在我试图呈现的比例计算中,要求我每月处理大约2160亿条消息.在这种规模上,我担心我将无法实时处理43亿条消息.

鉴于这种经验,我不确定SNS的扩展程度.那些#of不到实时的消息(读取> 2秒延迟)会更多吗？还是会减少？

现在可能有人质疑我的互联网连接可靠性,我在EC2上重新做了这个实验并得到了非常相似的结果.

事实上,在同一时间内匹配的时间延迟类型.

具体问题

1. 什么是SLA到SNS的性能？
2. 间接地:这些SLA如何转换为AWS Lambda服务？
3. 有关这些延误可能发生在何处的任何理由？

Answer 1

这里发生的情况很可能是 Lambda 函数受到限制。并发 Lambda 调用的默认限制为 100 。如果您发送了 20K 条消息，则可能超出了该限制，尽管 lambda 的运行时间很短。当您的 lambda 函数在执行 SNS 请求时受到限制时，该请求将进入重试队列并重新执行最多 3 次，这种情况通常会在很长一段时间内（最多一个小时）发生。

您可以在该函数的 CloudWatch 指标中查看限制数量（不幸的是，您在 6 个月的 CloudWatch 保留发布之前运行了测试）。