博客

Cloud Run min实例：最小化无服务器的冷启动

  • Post author:
  • Post category:其他


图片

作者：Kelsey Hightower；Vinod Ramachandran

无服务器最为优异的一点在于其按需付费的操作模型，可以让用户将服务规模缩减为零。但是对于某些应用程序来说，无服务器对于他们来说没那么重要的原因也在于其模型可以按需缩减为零。这是因为对于这些应用来说，一旦服务器的规模缩减为零，再次唤醒是的第一个操作请求很有可能会被延迟，这也是很多人常说的“启动税”。所谓的“启动税”对于无服务器来说很新颖的一个词语，顾名思义，如果应用程序没有收到流量，那么就没有服务器在运行。

不久前，谷歌对外宣布Cloud Run（托管无服务器计算平台）的min实例，这项重要的新功能可以极大地提高应用程序的性能。可以让那些对延迟非常敏感的应用程序也能够从Cloud Run上获益，至于如何获益，下文我们将深入介绍。


减少冷启动

通过使用Cloud Run min实例，用户可以配置一组数量最小、处于待机状态并随时准备提供流量的Cloud Run实例，从而帮助应用减少冷启动而更快的开始服务请求。

要使用Cloud Run的新的min实例功能，只需使用简单的gcloud命令或UI配置Cloud Run服务的min实例数。 

$ gcloud beta run deploy --image gcr.io/cloudrun/hello --min-instances=3 helloservice

配置完成后，最小实例将准备就绪，随时准备魏应用程序提供服务，从而最大程度地减少了应用程序的冷启动，这样，即使您的应用对延迟非常敏感也可以在Cloud Run上运行。


  • 重用自举逻辑

除了最大程度地减少冷启动，Cloud Run min实例还可以帮助用户减少关键操作的引导时间，例如打开数据库连接或将文件从Cloud Storage加载到内存中。通过减少引导时间，min实例有助于进一步减少请求延迟，因为您只需要运行一次引导逻辑，然后在多个请求中利用它来配置min实例数。

参考下面的golang无服务器功能，该功能说明如何运行一次引导逻辑，并在min实例中重用它：


  • 一次运行引导逻辑，然后在min实例中重复使用
     

  • package main
import (      "fmt"    
  "log"    
  "net/http"
 )
 func init() {
   setupDBConnection(dbName)
   }
   
 func handler(w http.ResponseWriter, r *http.Request) {
           fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])
    }
  func main() {
      fmt.Println("Processing your serverless request")
      http.HandleFunc("/", handler)
      log.Fatal(http.ListenAndServe(":8080", nil))
   }


以更低的成本发挥无服务器的优势

除了设置min实例数之外，Cloud Run min实例还允许您使用节流的CPU对其进行配置，因此您可以以更低的成本利用这个功能。这样既可以利用无服务器的效率和成本优势，同时将对延迟敏感的工作负载转移到无服务器。


运行中的Cloud Run min实例

我们讨论了Cloud Run min实例可以带来的好处，以及如何使用该功能，但是它在现实生活中如何工作以及为什么要使用它？ 传统上，无服务器平台迎合了从缩放到零受益的应用程序，但是由于引导期间的冷启动延迟而在初始响应时间上做出了一定的权衡。这对于从头开始构建的应用程序是可以接受的，并且可以完全控制源代码及其在运行时的行为。但是，人们需要使用一整类应用程序，而传统的无服务器方法并不适合这些应用程序。

可以考虑使用诸如Prometheus之类的自定义控制平面来收集度量，并使用Open Policy Agent（OPA）来制定策略决策。这些控制平面通常需要在初始启动期间进行高级配置并需要一些引导程序，并且不能忍受额外的延迟。 例如，在启动OPA时，通常会从远程源获取策略并将其缓存，以加快将来的策略决策速度。在典型的无服务器环境中，控制平面（例如OPA）在扩展到零并再次备份以处理策略请求时会受到性能影响，因为它位于关键用户事务的请求路径中。Cloud Run min实例可以直接解决这个问题。现在，我们可以确保每个请求将由OPA的“热”实例处理，而不必缩放为零，也不必在每个请求之间重新引导策略引擎。让我们看看实际情况。

在以下部分中，我们将OPA部署为作为中央控制平面运行，并使最小的实例满足我们的性能要求。我们将OPA服务器配置为在运行时从Cloud Storage存储桶中提取策略捆绑包，查询该查包将允许针对“ / health” HTTP路径的http GET请求。

这是OPA政策的例子👇 

package http.example.authzdefault allow = false
allow {
    input.method == "GET"
    input.path == "/health"

}

该策略打包在策略捆绑包中，并上传到Cloud Storage存储桶。但是首先，我们需要引导一些依赖项，如本教程中有关引导过程的所示。为了使事情简单，我们利用了一个辅助脚本。 

  $ git clone https://github.com/kelseyhightower/min-instances-tutorial.git

切换到min-instances-tutorial目录 

 $ cd min-instances-tutorial

在部署OPA Cloud Run实例之前，我们需要执行以下任务：

  • 创建一个OPA服务帐户

  • 创建一个Cloud Storage存储桶以容纳OPA策略捆绑包

  • 将OPA策略捆绑（bundle.tar.gz）上传到Cloud Storage

  • 向OPA服务帐户授予访问OPA捆绑软件的权限 

    $ ./bin/bootstrap Creating the open-policy-agent service account …
Creating the GCS bucket to hold the OPA policy bundle…
Creating gs://opa-policies-hightowerlabs/…
Created GCS bucket opa-policies-hightowerlabs
Copying the OPA policy bundle (bundle.tar.gz) to gs://opa-policies-hightowerlabs…
Copying file://bundle.tar.gz [Content-Type=application/x-tar]…
/ [1 files][  280.0 B/  280.0 B]                                                
Operation completed over 1 objects/280.0 B.                                      
Granting read permission on to the open-policy-agent service account
Tutorial bootstrapping complete.
Service account email and bucket name written to .env
Service Account: open-policy-agent@hightowerlabs.iam.gserviceaccount.com

Bucket Name: opa-policies-hightowerlabs

至此，主机OPA的所有依赖项均已就绪，准备使用“ gcloud”命令部署OPA。存储桶名称和服务帐户电子邮件地址存储在上一步中运行的引导脚本创建的“ .env”文件中。 

$ source .env

创建open-policy-agent Cloud Run实例： 

 $ gcloud beta run deploy open-policy-agent \  --concurrency 80 \
  --cpu 2 \
  --image gcr.io/hightowerlabs/opa:0.24.0-min-instances \
  --memory '2G' \
  --min-instances 1 \
  --no-allow-unauthenticated \
  --platform managed \
  --port 8181 \
  --region us-west1 \
  --service-account ${SERVICE_ACCOUNT} \
  --set-env-vars="BUCKET_NAME=${BUCKET_NAME}" \

  --timeout 300

输出如下👇表示已经成功引导了环境 

Deploying container to Cloud Run service [open-policy-agent] in project [hightowerlabs] region [us-west1]✓ Deploying… Done.                                                                                                          

  ✓ Creating Revision…                                                                                                      
  ✓ Routing traffic…                                                                                                        
  ✓ Setting IAM Policy…                                                                                                     
Done.                                                                                                                         
Service [open-policy-agent] revision [open-policy-agent-00018-bim] has been deployed and is serving 100 percent of traffic.

Service URL: https://open-policy-agent-6bn2iswfgq-uw.a.run.app

现在，当OPA服务器首次启动时，它将从Cloud Storage中下载策略捆绑包并对其进行缓存。但是多亏了min实例，这只发生了一次。

图片

现在，我们准备测试做出一项政策决定。我们可以卷曲地做到这一点。

检索open-policy-agent云运行URL 

$ OPA_URL=$(gcloud run services describe open-policy-agent \--platform managed \
--region us-west1 \
--format json 
\

jq -r '.status.url')

通过提供一组输入来查询OPA服务器，并根据存储在Cloud Storage中的策略捆绑包检索策略决策 

$ curl -i "${OPA_URL}/v1/data/http/example/authz" \
-H "Authorization: Bearer $(gcloud auth print-identity-token)" \
-d '{"input": {"path": "/health","method": "GET"}}'

下面👇是反馈的结果 

HTTP/2 200 content-type: application/json
date: Thu, 29 Oct 2020 15:20:06 GMT
content-length: 25
server: Google Frontend

{"result":{"allow":true}}

现在，只需等待几分钟，就会发现OPA不会缩放为零，并且该进程将在后台冻结，仅在下一个请求到达实例时才会解冻。如果您想了解更多有关价格如何影响定价的信息，可以查看下方链接。

链接：

https://cloud.google.com/run/pricing

Cloud Run快速入门：

https://cloud.google.com/run/docs/quickstarts


编译自：Cloud Run min instances: Minimize your serverless cold start

电话：18651688484

邮箱合作：cloud@webeye.com

想了解更多，可扫描下方二维码留下您的问题

我们会及时与您联系

图片
图片
图片