估计SQS处理时间和负载

Question

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

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

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

按流程，我的意思是：

• 阅读SQS消息->
• 从该SQS消息中获取S3位置->
• 呼叫S3客户端->
• 读取该文件->
• 添加一些其他字段->
• 将此文件中的数据发布到AWS Kinesis Firehose。

将对队列中的每个SQS消息进行类似的处理。 S3文件的大小很小，小于0.5 KB。

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

Answer 1

  

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

测试它！ 从小范围开始，然后进行数学运算以从那里进行推断。使您的测试环境尽可能接近生产环境。

• 在单个主机和单个线程上，数学很简单：
  • 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实例来处理所需工作量的问题。