如何保持通过代理集成从API Gateway调用的AWS Lambda的温度

Question

我定义了一个lambda函数，该函数从具有代理集成的API Gateway调用。因此，我为它定义了一个渴望的资源路径：

并引用了我的lambda函数：

我的lambda能够处理类似GET /myresource，POST /myresource之类的请求。

我尝试过这种策略以保持温暖，如acloudguru中所述。它包括设置CloudWatch事件规则，该规则每5分钟调用一次lambda以使其保持温暖。不幸的是，它无法正常工作。

这是我所看到的行为：

• 经过一段时间，例如20分钟，我从API网关致电GET /myresource，大约需要15秒。后续请求持续约30ms。 CloudWatch事件无济于事...

• 让我们假设又长时间不调用网关了。如果我转到Lambda控制台并直接调用它（测试按钮），它会立即（不到1ms）用404响应（这是正常现象，因为我的lambda期望使用GET /myresource或POST /myresource）。

在执行完Lambda控制台后，我立即从API网关调用GET /myresource，仍然需要20秒钟左右。也就是说，尽管已从Lambda控制台调用了该功能，但该功能仍然很冷。这可能可以解释为什么CloudWatch事件在不设置方法/ resource-url的情况下调用lambda而不起作用。

那么，如何通过具有代理集成+ Lambda的API网关使这种特殊情况成为可能，以防止那些缓慢的首次请求？

Answer 1

截至目前（2019-02-27）[1]，定期的CloudWatch事件规则不能确定性地解决冷启动问题。但是定期的CloudWatch事件规则将减少冷启动的可能性。

原因是由Lambda服务器决定是否使用新的Lambda容器而不是现有的容器来处理传入的请求。有关如何重用Lambda容器的一些相关详细信息，请参见[1]

为了减少冷启动时间（而不是减少冷启动次数），您可以尝试以下方法吗？ 1.增加分配给该函数的内存，2.减小部署包的大小（例如，删除不必要的依赖项），以及3.使用诸如NodeJS，Python而不是Java，.Net的语言

[1]根据重塑会话，（https://www.youtube.com/watch?v=QdzV04T_kec的39:50），Lambda小组希望改善Lambda中的VPC冷启动延迟。

[2] https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/

Answer 2

关于CloudWatch事件击中的容器数量，非确定性lambda行为非常正确。我将遵循他的建议以缩短启动时间。

另一方面，我设法使CloudWatch事件正确到达了lambda函数，从而减少了（在许多情况下）冷启动的次数。

我只需要添加一个映射为“ /”且具有硬编码响应的附加控制器：

@Controller("/")
class WarmUpController {

    private val logger = LoggerFactory.getLogger(javaClass)

    @Get
    fun warmUp(): String {
        logger.info("Warming up")
        return """{"message" : "warming up"}"""
    }
}

使用此功能后，CloudWatch的默认（/）调用可以使容器大部分时间保持温暖。