什么能使云运行实例在连续加载的情况下不被重用？

Question

上下文：

我的Spring应用程序在CloudSQL上运行时，最大实例设置为1:它通过push接收一个常量的pubsub消息流，并根据消息有效负载对相关的CloudSQL实例进行0到5的写入。通常，它每秒处理20到40条消息。延迟/响应-时间变化在50到60秒之间，可能是由于某些资源争用引起的。

为了提高吞吐量/减少资源争用，我希望对每个应用程序实例的连接池大小以及云运行应用程序的并发性和最大实例参数进行实验。

据我所知，由于Spring，我的应用程序的冷启动时间相对较高，大约为30-40秒。这对于如何使用此服务是可以接受的。

问题：

当将spring引导应用程序部署到云端运行时遇到问题，最大实例设置为大于1的值：

• 实例启动，成功处理单个请求，然后不再生成日志。
• 这种情况每分钟发生几次，使我相信实例会启动(冷启动)，处理单个请求，死亡，然后重新开始。它们不像文档中所描述的那样被重用，当我将max-实例设置为1. 关于并发的官方文档时也是如此。
• 相反，我希望启动3个容器实例，然后根据最大并发性设置进行每个请求。

最大的可计费容器时间-实例=3：

​

• 如图所示，一旦部署了带有max- instances =3的新版本，实例的数量就会剧烈波动。
• CPU和内存使用情况的图表也如下所示。
• 没有错误日志。和以前一样，在max-instace=1中，有警告指出没有足够的实例来处理请求(HTTP 429)。
• 没有超过CloudSQL实例的连接限制
• 请求的处理时间少于10/s。

最后，这是用于部署的命令：

 gcloud beta run deploy my-service --project=[...] --image=[...] --add-cloudsql-instances=[...] --region=[...] --platform=managed --memory=1Gi --max-instances=3 --concurrency=3 --no-allow-unauthenticated

是什么导致了这种行为？

Answer 1

几个月前，在私人Alpha中，我进行了测试，并观察到了同样的行为。经过与Google团队的讨论，我了解到实例“以防万一”是多余的:一个实例崩溃，一个实例被抢占，流量突然增加，……

这的权衡是，您将有更多的冷启动，您的最大实例值。更糟的，您将为此而被收取费用，因为这不是一个问题，因为Cloud有一个巨大的免费层，可以解决此类故障。

深入日志(您可以在BigQuery中创建云运行日志接收器，然后请求它们)，即使上面的实例比最大实例多，在同一时间只有最大实例是活动的。我不太清楚。使用您的参数，这意味着，如果在同一时间内有5个实例，则只有3个在同一时间点服务流量。

这部分没有文档化，因为它不断发展，以便在过度供应和缺乏资源(和429个错误)之间找到最佳的平衡。

@Steren @AhmetB你能确认或纠正我吗？

Answer 2

当Cloud快速接收和处理请求时，它会预测它需要多少个实例，并尝试扩展到相应的数量。如果出现突然的请求突发，云运行将实例化更多的实例作为响应。这样做是为了适应超出当前服务范围的可能更多的网络请求，并试图考虑到现有实例完成加载请求所需的时间长度。根据文档，当容器实例达到峰值时，容器实例的数量可能会超过最大实例值。

您提到了将max-实例设置为1，它运行良好，但后来您提到，它实际上生成了429 s，并将其设置为1。看到429 s的行为以及实例的尖峰可能表明流量没有被流畅地处理。

同样值得注意的是，由于您提到的冷启动时间，当实例为第一个请求提供服务时，按设计，并发请求的数量实际上很难设置为1。一旦事情完全就绪，只有应用您选择的并发设置。

对于Max实例设置和并发性，您选择3和3有什么具体原因吗？另外，当max实例设置为1时，并发性是如何设置的？也许您可以尝试进一步改进并发性 (最大值80)和/or 最大实例 (上限可达1000)，看看它是否删除了429 s。