错误 429：配额指标“查询”超出配额并限制“每个用户每分钟的查询数”答案

【问题标题】：Error 429: Quota exceeded for quota metric 'Queries' and limit 'Queries per minute per user'错误 429：配额指标“查询”超出配额并限制“每个用户每分钟的查询数”
【发布时间】：2021-11-03 12:06:26
【问题描述】：

我们将服务从 GCP App Engine 迁移到 Cloud Run。此服务连接到 Cloud SQL。

其参数为：

每个容器的最大请求数：1
分钟实例：0
最大实例数：200

收到峰值后，我们多次遇到此错误：

Cloud SQL connection failed. Please see https://cloud.google.com/sql/docs/mysql/connect-overview for additional details: googleapi: Error 429: Quota exceeded for quota metric 'Queries' and limit 'Queries per minute per user' of service 'sqladmin.googleapis.com' for consumer 'project_number:370240628xxx'., rateLimitExceeded

Cloud SQL Admin API 中的配额Queries per minute per user 设置为 180。所以这显然是失败点。

我发现由于 Cloud Run 连接到 Cloud SQL 实例的方式而达到配额限制。正如this link 所说：

本机连接利用 Cloud SQL Auth 代理，该代理反过来向 Cloud SQL Admin API 发出请求。此 API - 与所有 GCP API 一样 - 具有限制配额，一旦达到，容器将无法启动。

同一网站上的教程建议使用 VPC 连接器而不是普通的 Cloud SQL 连接。但我看到 Google 的 docs 和其他 stackoverflow 帖子建议以某种方式添加 quotaUser 参数。

最佳解决方案是什么？我通常会选择 VPC，但由于这是一项付费服务，我显然会尽量避免这种情况。由于我已经为 Cloud Run 和 Cloud SQL 付费，我希望这两者能够连接起来而不会出现问题和额外费用。

感谢您的所有提示和帮助！

【问题讨论】：

您可以向支持人员开一张票并询问他们是硬限制还是软限制？它可以解决您的问题。
我知道这是我可以改变的限制。但这根本不可扩展。您可以在APIs & services 中找到并编辑此限制 --> Cloud SQL Admin API
正如 Arnaud（作者）在我引用的链接中提到的，它可能使用 Cloud SQL Auth 代理。诡异的。他通过使用 VPC 解决了这个问题。

标签： docker google-cloud-platform google-cloud-sql knex.js google-cloud-run

【解决方案1】：

每个容器的最大请求数：1
最少实例：0
最大实例：200

哇，这是一个奇怪的设置。

上面的意思是你有concureny=1。对于每个请求，您都会启动一个全新的容器。您的所有请求都启动缓慢。

您应该将max requests per container 增加到您的容器基于它运行的进程可以跟上的阈值，例如：512MB 的简单 Web 服务的 80 个请求/容器听起来不错。试试这个。

将并发数从 1 增加到 80，这意味着可以重复使用 1 个单个数据库连接，并且您不会达到其他限制。

ps。我不知道您可以为 SQL 连接指定 quotaUser 的任何方法，这是一个 unix socket 类型的连接。

【讨论】：

感谢您的回答，尽管我认为您的回答与这个问题无关。这更像是一个一般性的建议。我们有这个设置是有原因的，如果有这个选项，我希望它可以工作。
它没有 512MB；我从来没有这么说过。内存分配为2048Mi。
让我们知道您设置的原因，提供进一步的指导真的很容易。您也可以添加到您的帖子中，这是理解为什么它是硬限制的原因。您的请求的执行时间是多少？是否需要低延迟或可以适应一些延迟。我为什么要问？您可以为 DB 层设置一个高并发的 Cloud Run 服务，所有现有服务都可以使用该 Cloud Run 服务来访问数据库，如Cloud Run(frontend) -> Cloud Run (db layer) -> SQL.
我们将 Puppeteer 作为一个容器运行，为了避免各种崩溃和错误，我们决定始终为每个实例运行一个浏览器。每天有数千个请求，因此实例数量要高得多是有意义的。即使我将并发设置为更高的数字，如果我们的服务增长得更多，我们也会遇到同样的问题，这是意料之中的。我现在选择了 VPC，并创建了一个私有网络。现在连接不是通过公共 IP 和 API 建立的，而是在内部建立的。我认为这可能会解决问题，但还不确定。我们将在明天对其进行测试。
在 puppeteer 中启动页面的代码是什么？您是否探索过启动一个浏览器实例，并将每个请求放入它自己的页面选项卡中？

【解决方案2】：

简短说明：

我们通过使用允许我们创建内部网络的 VPC 无服务器连接器（VPC 网络 -> 无服务器 VPC 访问）解决了这个问题。

配额“每用户每分钟查询数”适用于 Cloud SQL Admin API。由于我们现在使用的是内部网络，因此我们不会遇到此 API 及其限制。

步骤：

注册一个新的VPC serverless connector。可以在VPC network -> Serverless VPC access中找到。我们选择“默认”网络，将 IP 地址范围设置为“10.8.0.0/28”和“e2-micro”作为实例类型。关于该地区，我们指定了“europe-west1”，因为我们的 Cloud Run 服务位于该地区。正如Google documentation 所说，VPC 的区域必须与您的服务的区域匹配才能工作。
您必须为您的 SQL 启用“私有 IP”。它可以在 SQL -> 连接中找到。我们选择了“默认”网络，并选择了谷歌为我们生成地址。 Google 需要几秒钟才能完成此过程。
然后，要设置这些设置，您必须按“保存”按钮，但要小心，因为接下来的过程需要几分钟才能完成（在我们的例子中是 7 分钟）
我们进入 SQL -> Overview 并复制了新生成的“私有 IP 地址”。
然后，我们将此地址用作 Cloud Run 中的环境变量作为 SQL_HOST。之前，SQL_HOST 变量是“连接名称”，其形式为“项目名称：欧洲西部3：数据库名称”。所以这被替换为“私有 IP”。

它起作用了，尽管我们认为 Google 应该默认这样做。 Cloud Run 应该是一项可以大规模扩展的服务，但您很快就会发现流量增加会导致问题。

更新：

我们最终创建了一个新的 VPC 网络，仅用于从 Cloud Run 服务连接到数据库。因此，我们将数据库和无服务器 VPC 连接器分配给这个新创建的网络，而不是“默认”。这样我们就可以轻松地修改我们希望允许的 IP 地址数量，而不会干扰网络中的其他机器。

【讨论】：