AWS Lambda+Step Functions迁移DynamoDB时遭遇超时问题

问题背景 #

迁移大体积DynamoDB旧表到新表时，采用LastEvaluatedKey分页读取，搭配Step Functions工作流循环调用Lambda处理。已将Lambda超时从30秒调至10分钟，迁移近一半数据后仍触发超时，相关信息如下：

Step Functions工作流定义 #

{
  "Comment": "DynamoDB Scan Workflow",
  "StartAt": "ScanDynamoDB",
  "States": {
    "ScanDynamoDB": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:**********:function:dynamo-table-migrator",
      "Next": "IsScanComplete"
    },
    "IsScanComplete": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.LastEvaluatedKey",
          "IsPresent": true,
          "Next": "ScanDynamoDB"
        }
      ],
      "Default": "Done"
    },
    "Done": {
      "Type": "Succeed"
    }
  }
}

Lambda超时错误信息 #

The cause could not be determined because Lambda did not return an error type. Returned payload: {"errorMessage":"2024-01-10T06:55:49.427Z 4730971c-c428-4692-aa23-4486932da4f2 Task timed out after 600.18 seconds"}

可能的触发原因 #

• 单批次数据量过载：Lambda单次调用中Scan的Limit设置过高，导致处理的条目数过多，加上写入新表的IO耗时累积，撑满10分钟超时上限。
• DynamoDB吞吐量瓶颈：旧表读吞吐量或新表写吞吐量不足，请求被限流等待，拉长了Lambda执行时间。
• Lambda资源配置不足：内存分配偏低，导致CPU、网络IO性能受限，数据处理速度跟不上，最终触发超时。

解决方案 #

1. 缩小单次处理的数据规模 #

在Lambda的Scan请求中降低Limit值，比如从默认的1MB（约数百条）调至更小的数值，确保单次调用能在超时时间内完成。同时添加日志记录每次处理的条目数和耗时，逐步找到最优的Limit配置。

2. 优化DynamoDB吞吐量 #

• 临时提升旧表读吞吐量和新表写吞吐量，避免限流等待，迁移完成后再调回原配置。
• 针对ProvisionedThroughputExceededException错误，在Lambda中添加指数退避重试逻辑，降低请求失败概率。

3. 调整Lambda资源参数 #

• 提高Lambda内存分配（内存与CPU、网络带宽正相关），比如从256MB升级到512MB或1GB，加快数据处理和读写速度。
• 将Lambda超时设为14分钟（Step Functions单任务最大超时为15分钟），预留缓冲时间。

4. 优化迁移逻辑 #

• 采用并行处理：通过Step Functions的Map状态拆分数据分片，并行调用Lambda处理；或使用DynamoDB的Parallel Scan功能，同时发起多个Scan请求处理不同数据段。
• 异步写入：将新表写入操作放入SQS队列，由独立Lambda异步处理，减少主迁移Lambda的执行时长。

5. 精准监控排查 #

在Lambda中添加详细日志，记录Scan耗时、写入耗时、处理条目数等指标，定位是读还是写环节拖慢了执行速度；同时通过CloudWatch监控Lambda执行时间、DynamoDB吞吐量和错误指标，快速锁定瓶颈。

内容的提问来源于stack exchange，提问作者levniko