V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lvhuiyang
V2EX  ›  Amazon Web Services

AWS Lambda function 间接性超时

  •  1
     
  •   lvhuiyang ·
    lyu-huiyang · 308 天前 · 1425 次点击
    这是一个创建于 308 天前的主题,其中的信息可能已经有所发展或是发生改变。
    使用 Python + sqlalchemy 容器化部署在 AWS 一个 lambda 函数,来实现某些特殊存储业务的服务,用于提供给 Web Server 后端来调用。

    背景:目前部署在测试环境,因为测试环境流量不大,考虑到在一段时间没有调用 lambda 的时候可能会导致 “休眠”,于是添加一个 Amazon EventBridge 的 schedule 来每分钟调用一次 lambda 函数,同时在业务中也实现了一个 celery 定时任务每分钟调用一次。

    但是发现了一个奇怪的现象,在 lambda 函数没有做任何改动的前提下,调用会接歇性的超时。如果某段时间 100% 超时的话,我认为是 lambda 函数休眠了,需要冷启动花费时间。但是现状是每分钟都有请求保证其“不休眠”,而且并非请求 100% 超时,在某几分钟内有的请求超时,有的是正常的。统计图如下



    有没有比较懂的老哥解答一下,十分感谢 ~
    8 条回复    2024-01-03 19:13:04 +08:00
    Mithril
        1
    Mithril  
       307 天前   ❤️ 1
    你看一下 log ,看看是不是冷启动了。Log 里面会有 Init Duration 。
    不过就算你不停的 ping ,也不能保证它不会冷启动。如果那个可用区负载过高,你的 lambda 也可能被负载均衡搞出去,一样会冷启动。

    如果你对这冷启动的时间很敏感,可以试试 Provisioned Concurrency 。或者干脆就用 EKS ,不要用 Lambda 。
    Aygnh136
        2
    Aygnh136  
       307 天前   ❤️ 1
    就算你每秒都有请求,lambda 觉得自己需要扩容,或者超过最大持续时长了,都会开新的 lambda(需要冷起)
    无论如何 15 分钟都会有一次冷启的
    Aygnh136
        3
    Aygnh136  
       307 天前   ❤️ 1
    lambda 相当于执行你的代码之后,保留运行环境,并输出一个 handler(用于被调用),这个启动这个环境叫“冷启”。
    当 lambda 被调起时,会分配一个 handler (没有可用的会新起一个)执行并返回结果。
    它根据自己的设定(不同语言不同逻辑)来判断目前环境是否活跃,不活跃则释放。
    lambda 保留的运行环境有最大时间限制(即使活跃也会被销毁),一般是 15 分钟。
    我用的 node 至于 Python 的运行环境应该是同理。
    lvhuiyang
        4
    lvhuiyang  
    OP
       307 天前
    #1 @Mithril 非常感谢回复,看来我对 lambda 的冷启动理解有问题,查了下日志确实是大量 Init Duration

    对冷启动时间倒是不是很敏感,敏感的是因为超时带来的请求错误。通过日志看冷启动时间不超过 1s ,业务处理逻辑应该在 200 ms 以内,因此设置了 5s 的超时时间应该是足够的。但是错误率确实和超时时间有关,我再定位一下吧,总之十分感谢提供的信息

    日志查询 Init Duration:


    错误率确实和允许时常有关 :
    lvhuiyang
        5
    lvhuiyang  
    OP
       307 天前
    #2 #3 @Aygnh136

    明白了,我对 lambda 的理解确实有问题,我再去了解一下,十分感谢回复
    BeautifulSoap
        6
    BeautifulSoap  
       307 天前   ❤️ 1
    lz 你的 Lambda 的负载难道只有 1rps ? 如果大于 1rps 你这做法当然会出现冷启动的问题

    但再冷启动,11s 也太长了,Lambda 的冷启动时间撑死也就 2s~3s ,而 11s 的处理时间明显是程序内部哪里的问题,建议打 log 或者启用 xray 看看内部发生了什么
    lvhuiyang
        7
    lvhuiyang  
    OP
       306 天前
    #6 @BeautifulSoap 十分感谢回复,经过排查确实是我的程序内部逻辑问题:在 lambda 内部使用 sdk 调用 secretsmanager client 的 get_secret_value 时候默认未设置超时时间,导致有一定概率会卡住:

    ```python
    session = boto3.session.Session()
    client = session.client(
    service_name="secretsmanager",
    region_name=REGION_NAME,
    config=aws_client_config,
    )
    response = client.get_secret_value(SecretId=db_secret_id)
    ```

    虽然还不清楚在 lambda 内部使用 sdk 调用 secretsmanager client 会啥可能卡住,目前换了其他的方式来避免调用 secretsmanager client 之后,原来的问题解决了。
    BeautifulSoap
        8
    BeautifulSoap  
       306 天前   ❤️ 1
    @lvhuiyang 原来如此。其实不光是 ssm ,aws 的其他服务比如 dynamodb 之类通过 https 提供服务的都会出现可能性的超时。之前生产环境每几小时报错,查到后来发现是和 dynamodb 的通信超时了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5027 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 03:57 · PVG 11:57 · LAX 19:57 · JFK 22:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.