【问题标题】:How to migrate to SQS trigger from Cloudwatch events?如何从 Cloudwatch 事件迁移到 SQS 触发器?
【发布时间】:2022-02-18 13:00:18
【问题描述】:

以最小的风险和停机时间将 Lambda 函数的调用从 Cloudwatch 事件迁移到事件源映射(触发器)的最佳方法是什么?

我们的应用程序使用 cloudwatch 事件规则以固定速率调用 Lambda,然后轮询 SQS 队列以获取消息,我们希望使用 SQS 触发器(ESM)自动调用 lambda。

集思广益:

选项 1. 将触发器和 cloudwatch 事件都连接到现有 Lambda,然后慢慢弃用事件规则。
选项 2. 使用具有事件源的重复 lambda 作为 SQS 队列并划分流量,稍后弃用原始 lambda。
选项 3. 添加额外的 SQS(订阅相同的 SNS)和使用触发器的 Lambda 对,稍后弃用原来的。 我相信许多团队可能已经进行过类似的迁移,任何见解都将不胜感激。

【问题讨论】:

  • 如果不对 lambda 源代码稍作调整,我不确定这些选项中的任何一个是否会起作用。我认为sqs.receive_messages 和 SQS 直接发送的事件之间的有效负载形状/结构存在差异
  • 是的,Lambda 代码需要重构。在选项 1 中,如果有任何这样的事情,我必须想办法根据有效负载(无论是它的事件还是消息)来反序列化对象。

标签: amazon-web-services aws-lambda amazon-sqs amazon-cloudwatch-events


【解决方案1】:

您的选项 2 以更简单的方式进行切换。

由于您有 CW 事件计划,因此您 lambda 最多可以每分钟执行一次,因为计划的最小精度为 1 分钟。

  1. 创建新的 lambda
  2. 将旧 lambda 的并发设置为零
  3. 为新的 lambda 启用 SQS 触发器
  4. 删除旧 lambda 中的事件计划触发器

【讨论】:

    猜你喜欢
    • 2022-01-27
    • 2018-05-30
    • 2020-06-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-08
    • 1970-01-01
    • 2016-07-07
    • 2020-11-11
    相关资源
    最近更新 更多