配额管理最佳实践

本页面介绍了管理 Cloud Healthcare API 配额的最佳实践。如果您的 Google Cloud 项目具有（或可能具有）大量流量，并且您需要的配额超过 Cloud Healthcare API 默认提供的配额，请使用此页面。

Cloud Healthcare API 默认配额

默认的 Cloud Healthcare API 配额并非适用于所有使用场景，尤其是在您的 Google Cloud 项目有大量流量时。Cloud Healthcare API 不会自动增加配额。您必须规划和监控您的配额用量。

监控和查看配额的最佳实践

您可以通过多种方法查看配额用量。在估算和查看 Cloud Healthcare API 的配额时，我们建议您使用服务配额模型。 借助该模型，您可以根据以下条件准确评估您拥有的可用配额：

  • 是否存在管理员覆盖。在组织中被授予 Quota Administrator 角色的主帐号可以对组织内 Google Cloud 项目中的配额应用管理员替换项。管理员替换会取代默认限制和提供方替换。

  • 是否存在提供方替换值。服务所有者向服务的使用方授予提供方覆盖。Google Cloud 是 Cloud Healthcare API 服务的服务所有者。Google Cloud 提供的任何配额替换项都是提供方替换项。

  • 是否存在使用方替换值。向 Cloud Healthcare API 发出请求的用户是 Cloud Healthcare API 服务的使用方。您可以在各种情况下应用使用方替换项，例如作为费用控制措施来限制 Google Cloud 项目中的配额以防止预算超支。

如果您实施了上述任何替换项，则可以计算使用方配额限制，以便准确评估您的可用配额。

申请额外配额的最佳做法

Google Cloud 提供了申请更高配额的流程。如需了解我们如何处理配额增加请求，请参阅关于配额增加请求。

在申请更多配额之前，请确保您已实现以下两项：

这些实现可能会减少您需要的配额，原因如下：

  • 这两种实现都将负载峰值分散在几小时或几分钟内，而不是数秒内。
  • 两种实现方式都可以在 24 小时内有效地利用配额。如果显著超过默认配额的请求在 24 小时内保持不变，则可以为 Cloud Healthcare API 服务分配更大的资源池。额外资源分配仅由请求决定，并且要根据具体情况确定。
  • 一致的资源用量有助于 Google Cloud 更轻松地了解您的配额要求，并为您提供所需的配额。

为了有效地管理您的容量和配额，您需要了解组织的容量需求。如果您计划自己的容量要求，并且认为当您的 Google Cloud 项目在生产环境中使用时，需要增加大量配额，请向 Google Cloud Customer Care 申请增加配额。Customer Care 可用于在 Google Cloud 项目的测试和发布阶段帮助您分配和增加配额。

您无需拥有付费 Customer Care 服务即可申请增加配额。某些配额增加申请会在 2-3 个工作日内完成，但我们建议您留出更长时间的计划。如果您增加的配额较大，可能需要 10 个工作日或更长时间才能完成配额增加请求。在规划过程中，必须分配时间来回复客户服务，以解决有关请求的任何问题或待解决的问题。如果您确保您的初始配额增加请求足够详细，您或许可以减少等待请求完成所用的时间。

预测配额需求的最佳实践

在您的 Google Cloud 项目进入生产环境之前，请预测并规划您需要多少配额。规划配额要求可防止日后资源消耗出现意外限制。

以下部分介绍了规划配额时要考虑的事项。

预测所有数据存储区和客户端的总用量

了解所有 Cloud Healthcare API 数据存储区的总用量，以及向您的 Google Cloud 项目发出请求的所有客户端的总用量。

  • 某些 Google Cloud 项目实现了多个 Cloud Healthcare API 用例。例如，您的 Google Cloud 项目可能会针对不同类型的数据使用多个 Cloud Healthcare API 数据集和数据存储区，从而增加总配额用量。
  • 配额按 Google Cloud 项目和区域实施。确保您在多个区域中准确测量所需的配额。如果您有多个 Google Cloud 项目，则可能需要更准确地跨项目测量。如需详细了解如何按区域规划配额，请参阅预测每个区域的用量。

  • Cloud Healthcare API 不会跨客户端、数据集或数据存储区对配额进行负载均衡。客户端必须确定是否实现优先级方案，以确保最关键的流量不会遇到 429 RESOURCE_EXHAUSTED 错误。

  • 所有 get、search、create、update 和 delete 方法共享一个配额，这意味着，如果非面向用户的应用用尽配额，面向用户的应用可能会遇到 429 RESOURCE_EXHAUSTED 错误。例如，您的 Google Cloud 项目中使用 create 请求将数据提取到 Cloud Healthcare API 中的应用可能会占用大量配额，并在面向用户的应用中导致 429 RESOURCE_EXHAUSTED 错误（用户正在执行 search 操作）。

预测每个区域的用量

Cloud Healthcare API 按每个 Google Cloud 项目和每个区域衡量配额。配额通常以分钟为单位进行计量，因此允许每秒中出现小峰值的请求，以平衡每分钟的配额。

如果您的 Google Cloud 项目使用多个区域，那么您可以按区域设置配额。

如果您的 Cloud Healthcare API 数据集位于 us 多区域位置，并且您希望申请更多配额，请在配额请求中注明该配额适用于“美国元区域”。us 多区域位置由以下子区域组成：

  • us-central1
  • us-east1
  • us-west1

如果您的 Cloud Healthcare API 流量正在使用任何 us- 子区域中的配额，在申请增加 us 多区域的配额时，请确保将这些子区域中的现有流量考虑在内。例如，如果您在 us-central1 和 us 中拥有数据集，并申请增加 us 的配额，请在请求中指定您在 us-central1 中的数据集。

有利于始终如一地保持小批量交易

以下场景说明了持续发送较少流量的重要性，而不是在各事务之间发送间隔更长的大量事务。

流量量的计算公式为 request payload * time = traffic volume。 高流量事务是指在较短的时间间隔内对 Cloud Healthcare API 发出的一个或多个请求，其中包含大量载荷。 如果在很短的时间间隔内发送大量请求，而不考虑载荷大小，一系列请求也可以被视为高容量请求。

假设客户端会收集大量事务，并在每 5 分钟的突发时间内将事务发送到 Cloud Healthcare API。会发生以下情况：

  1. 初始的流量爆发会在第一分钟内消耗配额（具体取决于分钟的结余），直到所有配额耗尽。
  2. 任何剩余的突发流量都会收到 429 RESOURCE_EXHAUSTED 错误。如果已配置，所有受影响的请求都会遇到指数退避算法。
  3. 遇到初始指数退避算法的部分请求会被重新安排在下一分钟重试。某些请求会在一分钟内尝试多次，然后在下一分钟重试。
  4. 如果请求量足够大，重试的请求可能会遇到 429 RESOURCE_EXHAUSTED 错误并再次出现指数退避算法。某些流量突发可能会在不同的时间遇到指数退避算法，并且尝试再次发送流量的尝试可能会在未来的同一分钟收敛。
  5. 如果请求量仍然较高，则系统会在下次突发流量时重试某些流量。由于现有积压请求增加了更多流量，因此问题变得更加严重。您的应用可能难以维护积压的请求，并以一致的方式将其发送到 Cloud Healthcare API。

此场景显示了了解每分钟流量的重要性。实现流量和退避算法，以防止网络拥塞，并确保您的应用不会遇到许多需要重试的故障。

查看 DICOM 和 FHIR 配额

如需查看与 FHIR 以及 DICOM 存储区和操作相关联的 Cloud Healthcare API 配额，请参阅配额限制。

配额管理资源

如需详细了解如何规划和管理配额，请参阅管理容量和配额。