估计 SQS 处理时间和负载

Question

我将使用 AWS SQS（常规队列，而不是 FIFO）来处理不同的客户端指标。

我预计每秒有大约 400 条消息（最坏情况）。我的 SQS 消息将包含文件的 S3 位置。

我创建了一个应用程序，它将监听我的 SQS 队列并处理来自它的消息。

我的意思是：

• 读取 SQS 消息 ->
• 从该 SQS 消息中获取 S3 位置 ->
• 调用 S3 客户端 ->
• 读取该文件 ->
• 添加一些额外的字段 —>
• 将此文件中的数据发布到 AWS Kinesis Firehose。

队列中的每条 SQS 消息都会有类似的过程。 S3 文件的大小很小，小于 0.5 KB。

如何计算我是否能够每秒处理这 400 条消息？我如何估计我的解决方案可以处理 x5 的数据增长？

Answer 1

如何计算我是否能够每秒处理这 400 条消息？我如何估计我的解决方案可以处理 x5 的数据增长？

测试一下！从小规模开始，然后进行数学推断。使您的测试环境尽可能接近生产环境。

• 在单个主机和单个线程上，数学很简单：
  • 1000 / AvgTotalTimeMillis = AvgMessagesPerSecond，或
  • 1000 / AvgMessagesPerSecond = AvgTotalTimeMillis

如何进行测试：

• 从单个线程和主机开始，并为您概述的每个步骤生成一些计时指标以及总时间。

  • 计算出您的平均/最大/最小时间，以及每秒转换为多少条消息
  • 在单个线程和主机上每秒 400 条消息将低于每条消息 3 毫秒。希望这表明您需要多个线程/主机。

• 扩大规模！

  • 既然您知道单个线程可以处理多少线程，那么请计算出单个主机可以有效处理多少线程（您需要进行试验）。尽可能考虑批处理消息 - SQS 提供批处理操作。
  • 使用数学计算您需要多少主机
  • 如果你需要这个数字的 5 倍，从那里往上走

• 在进行此数学运算时，考虑您正在使用的系统的任何限制：

  • 查看 SQS / S3 / Firehose / 等的限制。如果您打算使用 Lambda 而不是 EC2 来完成这项工作，它也有限制。确保您在这些限制范围内，如果您接近超过这些限制，请考虑联系 AWS 支持。

根据我的经验提出一些其他建议：

• 根据您的工作流程大纲和详细信息，使用 EC2 您可能可以在每个主机上处理相当数量的线程
• M5.large 应该绰绰有余 - 你可能会变小，因为性能瓶颈可能是网络 I/O 以获取和发送消息。
• 当您需要提高吞吐量时，请考虑使用自动扩缩来处理消息高峰，但请记住，自动扩缩可能需要几分钟才能启动。

Answer 2

确定这一点的唯一方法是创建一个反映您的场景的测试环境。

如果您的解决方案旨在并行处理消息，则应该可以扩展您的系统以处理几乎任何工作负载。

一个好的架构是使用 AWS Lambda 函数来处理消息。 Lambda 默认为 1000 个并发函数。因此，如果一个函数需要 3 秒来运行，它将持续支持每秒 333 条消息。您可以请求增加 Lambda 并发以处理更高的工作负载。

如果您使用的是 Amazon EC2 而不是 Lambda 函数，那么只需向外扩展并添加更多 EC2 实例和更多工作人员来处理您想要的任何工作负载。