如何保持Google Cloud Functions的温暖?

时间:2018-08-10 09:00:10

标签: google-cloud-functions firebase-hosting serverless next.js

我知道这首先错过了使用Cloud Functions的意义,但是在我的特定情况下,我正在使用Cloud Functions,因为这是将Next.js与Firebase Hosting桥接的唯一方法。我不需要使其具有成本效益,等等。

话虽如此,Cloud Functions的冷启动时间简直难以忍受,而且还不能投入生产,对于我的样板,平均大约需要10到15秒(WTF?)。

我当然看过Google(https://www.youtube.com/watch?v=IOXrwFqR6kY)的这段视频,该视频讨论了如何减少冷启动时间。简而言之:1)修剪依赖关系; 2)依赖关系版本在Google网络上缓存的尝试与错误; 3)延迟加载。

但是,嘿,1)我可以裁剪的依赖项太多了。 2)真是无用的建议!我怎么知道哪个版本的缓存更多? 3)只有太多依赖项可以延迟加载。

另一种方法是避免全部冷启动。从本质上讲,我可以使(一个或唯一一个)云功能保持温暖是什么好方法?

6 个答案:

答案 0 :(得分:6)

对于所有“无服务器”计算提供商,总会有某种形式的冷启动成本无法消除。即使您能够通过ping通使单个实例保持活动状态,系统也可以启动任意数量的其他实例来处理当前负载。这些新实例将产生冷启动成本。然后,当负载减少时,不必要的实例将被关闭。

正如您所发现的,有很多方法可以使您的冷启动成本降至最低,但是无法消除这些成本。

如果您绝对要求热服务器处理24/7的请求,则需要管理自己的运行24/7的服务器(并支付运行24/7的服务器的费用)。如您所见,无服务器的好处是您无需管理或扩展自己的服务器,而只为使用的服务器付费,但是与项目相关的冷启动成本却不可预测。那是个权衡。

答案 1 :(得分:1)

您不是第一个提出问题的人;-)

答案是将远程服务配置为定期调用您的函数,以使单个|实例保持活动状态。

您的问题尚不清楚,但我认为您的Function提供了HTTP端点。在这种情况下,找到可配置为每x秒|分钟进行一次HTTP调用并将其指向您的Function的运行状况检查或cron服务。

您可能需要花些时间去寻找Goldilocks时期-并非经常是在浪费精力,不是死于这种情况的频率并不高-但这就是其他人所做的。

答案 2 :(得分:1)

使用Google Scheduler是一个明智的解决方案,但实际实现并非如此简单。请检查my article了解详情。函数示例:

return (
        ReactDOM.createPortal(
            <div id="portal_Game">
            <div><button onClick={jump}> JUMP </button></div>

gcloud cli命令的示例:

myHttpFunction: functions.https.onRequest((request, response) => {
  // Check if available warmup parameter.                                   
  // Use  request.query.warmup parameter if warmup request is GET.                                   
  // Use request.body.warmup parameter if warmup request is POST.                                   
  if (request.query.warmup || request.body.warmup) {
    return response.status(200).type('application/json').send({status: "success", message: "OK"});
  }
});
myOnCallFunction: functions.https.onCall((data, context) => {
  // Check if available warmup parameter.
  if (data.warmup) {
    return {"success": true};
  }
});

答案 3 :(得分:1)

云函数通常最适合仅执行一项(小)任务。我经常遇到想要在一个云功能中完成所有事情的人。老实说,这也是我开始开发云功能的方式。

考虑到这一点,您应该保持云函数代码的简洁和小巧,以便仅执行一项任务。通常,这将是一项后台任务、需要写入某处的文件或记录,或者必须执行的检查。在这种情况下,是否存在冷启动惩罚并不重要。

但如今,包括我自己在内的人们都依赖云函数作为API 网关云端点的后端。在这种情况下,用户访问一个网站,该网站向云功能发送后端请求以获取一些附加信息。现在云函数充当 API 并且用户正在等待它。

典型的云功能:

enter image description here

典型的云功能:

enter image description here

有几种方法可以解决冷启动问题:

  • 减少依赖和代码量。正如我之前所说,云函数最适合执行单个任务。这将减少在接收请求和执行代码之间必须加载到服务器的总包大小,从而显着加快速度。
  • 另一种更笨拙的方法是安排云调度程序定期向您的云函数发送预热请求。 GCP 有一个慷慨的免费层,它允许 3 个调度程序和 200 万次云函数调用(取决于资源使用情况)。因此,根据云函数的数量,您可以轻松地每隔几秒钟安排一次 http 请求。为清楚起见,我在这篇博文下方放置了一个片段,用于部署云函数和发送预热请求的调度程序。

如果您认为已经调整了冷启动问题,您还可以采取措施加快实际运行时间:

  • 我从 Python 切换到 Golang,这让我在实际运行时间方面实现了两位数的性能提升。 Golang 的速度与 Java 或 C++ 相当。
  • 在全局级别 (source) 声明变量,尤其是 GCP 客户端,例如存储、发布/订阅等。这样,您的云函数的未来调用将重用这些对象。
  • 如果您在一个云函数中执行多个独立的操作,您可以使它们异步。
  • 同样,干净的代码和更少的依赖也可以改善运行时。

片段:

# Deploy function
gcloud functions deploy warm-function \
  --runtime=go113 \
  --entry-point=Function \
  --trigger-http \
  --project=${PROJECT_ID} \
  --region=europe-west1 \
  --timeout=5s \
  --memory=128MB

# Set IAM bindings
gcloud functions add-iam-policy-binding warm-function \
  --region=europe-west1 \
  --member=serviceAccount:${PROJECT_ID}@appspot.gserviceaccount.com \
  --role=roles/cloudfunctions.invoker

# Create scheduler
gcloud scheduler jobs create http warmup-job \
  --schedule='*/5 * * * *' \
  --uri='https://europe-west1-${PROJECT_ID}.cloudfunctions.net/warm-function' \
  --project=${PROJECT_ID} \
  --http-method=OPTIONS \
  --oidc-service-account-email=${PROJECT_ID}@appspot.gserviceaccount.com \
  --oidc-token-audience=https://europe-west1-${PROJECT_ID}.cloudfunctions.net/warm-function

答案 4 :(得分:0)

您可以按照以下说明通过cron作业触发它:https://cloud.google.com/scheduler/docs/creating

答案 5 :(得分:0)

为了将冷启动降至最低,没有单一的解决方案,它是多种技术的结合。问题更多是如何使我们的Lambda如此之快,而我们并不在乎冷启动-我所说的启动时间在 100-500 ms 范围内。

如何使Lambda更快?

  1. 将程序包的大小保持尽可能小(删除使用了一部分的所有大型库)-将程序包的最大大小保持为20 MB。每次冷启动时,都会提取并解压缩该程序包。
  2. 仅在需要时尝试初始化应用程序。 Nodejs-https://gist.github.com/Rich-Harris/41e8ccc755ea232a5e7b88dee118bcf5
  3. 如果您对服务使用JVM技术,请尝试将它们迁移到Graalvm,从而将启动开销降至最低。
    • /proc/bus/input/devices
    • micronaut + graalvm
    • quarkus + graalvm
  4. 使用云基础架构配置来减少冷启动。

2020年,冷启动并不像几年前那样痛苦。我想说更多有关AWS的信息,但是我敢肯定,以上所有内容对于任何云提供商都适用。

在2019年底,AWS引入了Lambda并发配置-https://aws.amazon.com/about-aws/whats-new/2019/12/aws-lambda-announces-provisioned-concurrency/,您不需要必须非常关心变暖了。