Práticas recomendadas para a gestão de quotas

Esta página descreve as práticas recomendadas para gerir a quota da Cloud Healthcare API. Use esta página se o seu Google Cloud projeto tiver, ou puder ter, um grande volume de tráfego e precisar de mais quota do que a Cloud Healthcare API oferece por predefinição.

Quotas predefinidas da Cloud Healthcare API

As quotas predefinidas da API Cloud Healthcare não foram concebidas para todos os exemplos de utilização, especialmente se o seu Google Cloud projeto tiver um grande volume de tráfego. A Cloud Healthcare API não aumenta automaticamente a quota. Tem de planear e monitorizar a utilização da quota.

Práticas recomendadas para monitorizar e ver a quota

Existem vários métodos para ver a utilização da quota. Ao estimar e ver a quota da Cloud Healthcare API, recomendamos que use o modelo de quota de serviço. O modelo permite-lhe avaliar com precisão a quota disponível que tem com base nos seguintes critérios:

  • Se existe uma substituição de administrador. Um principal com a função de administrador de quotas numa organização pode aplicar uma substituição de administrador à quota emGoogle Cloud projetos na organização. Uma substituição do administrador substitui os limites predefinidos e as substituições do produtor.

  • Se existe uma substituição do produtor. Um proprietário do serviço concede uma substituição do produtor a um consumidor de um serviço. Google Cloud é o proprietário do serviço da API Cloud Healthcare. Qualquer substituição de quota que Google Cloud forneça é uma substituição do produtor.

  • Indica se está presente uma substituição do consumidor. Uma pessoa que faz pedidos à API Cloud Healthcare é um consumidor do serviço da API Cloud Healthcare. Pode aplicar substituições de consumidor para várias situações, como limitar as quotas no seuGoogle Cloud projeto como uma medida de controlo de custos para evitar exceder o seu orçamento.

Se tiver alguma destas substituições em vigor, pode calcular o limite da quota de consumidor para obter uma avaliação precisa da sua quota disponível.

Práticas recomendadas para pedir quota adicional

Google Cloud tem procedimentos para pedir um valor de quota mais elevado. Para saber como são processados os pedidos de ajuste de quota, consulte o artigo Acerca dos ajustes de quota.

Antes de pedir quota adicional, certifique-se de que implementou ambos os seguintes elementos:

Estas implementações podem reduzir a quantidade de quota necessária pelos seguintes motivos:

  • Ambas as implementações distribuem os picos de carga ao longo de várias horas ou minutos, em vez de segundos.
  • Ambas as implementações usam a quota de forma eficiente durante um período de 24 horas. Se os pedidos que excedem significativamente a quota predefinida forem consistentes durante um período de 24 horas, podem ser atribuídos conjuntos maiores de recursos ao serviço Cloud Healthcare API. A atribuição adicional de recursos só é feita mediante pedido e é determinada caso a caso.
  • A utilização consistente de recursos facilita a compreensão dos seus requisitos de quota e o fornecimento da quota de que precisa. Google Cloud

Para gerir a sua capacidade e quota de forma eficaz, tem de conhecer os requisitos de capacidade da sua organização. Se estiver a planear os seus requisitos de capacidade e achar que vai precisar de um grande aumento da quota quando o seu projeto estiver em produção, peça um aumento ao Google Cloud apoio técnico. Google Cloud O apoio técnico ao cliente pode ajudar a atribuir e aumentar a quota durante as fases de teste e implementação do seu Google Cloud projeto.

Não precisa de ter um serviço de apoio ao cliente pago para pedir um aumento de quotas. Algumas solicitações de aumento da quota são concluídas no prazo de 2 a 3 dias úteis, mas recomendamos que planeie um período mais longo. Se o aumento da quota for significativo, a conclusão do pedido de aumento da quota pode demorar 10 dias úteis ou mais. Parte do seu planeamento tem de envolver a atribuição de tempo para responder ao apoio ao cliente de modo a resolver quaisquer dúvidas ou problemas pendentes sobre o pedido. Se garantir que o seu pedido inicial de aumento da quota é suficientemente detalhado, pode reduzir o tempo de espera pela satisfação do pedido.

Práticas recomendadas para antecipar as necessidades de quota

Antes de o seu Google Cloud projeto entrar em produção, antecipe e planeie a quantidade de quota de que vai precisar. O planeamento dos requisitos de quota evita limitações inesperadas do consumo de recursos mais tarde.

As secções seguintes explicam o que deve ter em consideração ao planear a quota.

Antecipe a utilização total de todos os arquivos de dados e clientes

Compreenda a sua utilização total em todos os armazenamentos de dados da API Cloud Healthcare, e compreenda a utilização total de todos os clientes que fazem pedidos ao seuGoogle Cloud projeto.

  • Alguns Google Cloud projetos implementam vários exemplos de utilização da API Cloud Healthcare. Por exemplo, o seu Google Cloud projeto pode usar vários conjuntos de dados da API Cloud Healthcare e armazenamentos de dados para diferentes tipos de dados, o que aumenta a sua utilização total de quota.
  • As quotas são aplicadas por projeto doGoogle Cloude por região. Certifique-se de que tem medições precisas da quota necessária em várias regiões. Se tiver vários Google Cloud projetos, pode precisar de medições mais precisas em todos os projetos. Para mais informações sobre o planeamento da quota por região, consulte o artigo Antecipe a utilização por região.
  • A Cloud Healthcare API não equilibra a carga da quota entre clientes, conjuntos de dados nem repositórios de dados. O cliente tem de determinar se implementa um esquema de priorização para garantir que o tráfego mais crítico não encontra erros 429 RESOURCE_EXHAUSTED.

Antecipe a utilização por região

A Cloud Healthcare API mede as quotas porGoogle Cloudprojeto e por região. Normalmente, as quotas são medidas por minuto, o que permite que pequenos picos de pedidos por segundo sejam equilibrados numa escala por minuto.

Se o seu Google Cloud projeto usar várias regiões, pode definir quotas por região.

Se o seu conjunto de dados da Cloud Healthcare API estiver na localização us multirregional e quiser pedir uma quota adicional, indique no seu pedido de quota que a quota se destina à "metaregião dos EUA". A us localização multirregional é composta pelas seguintes sub-regiões:

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

Se já tiver tráfego da Cloud Healthcare API a usar a quota em qualquer uma das sub-regiões us-, certifique-se de que tem em conta o tráfego existente nessas sub-regiões quando fizer um pedido de aumento da quota para a multirregião us. Por exemplo, se tiver conjuntos de dados em us-central1 e us, e pedir um aumento da quota em us, especifique no seu pedido que tem conjuntos de dados em us-central1.

Privilegiar as transações de baixo volume de forma consistente

O cenário seguinte explica a importância de enviar quantidades menores de tráfego de forma consistente, em vez de enviar transações de volume elevado com um intervalo mais longo entre transações.

O volume de tráfego é calculado através da fórmula request payload * time = traffic volume. Uma transação de volume elevado é um ou mais pedidos à API Cloud Healthcare num curto intervalo que contêm uma carga útil grande. Uma série de pedidos também pode ser considerada de volume elevado se forem enviados muitos pedidos num curto intervalo, independentemente do tamanho da carga útil.

Suponhamos que um cliente recolhe transações de elevado volume e envia as transações para a Cloud Healthcare API num pico a cada cinco minutos. Ocorre o seguinte:

  1. O pico inicial de tráfego consome a quota no primeiro minuto (dependente das transferências de minutos) até que toda a quota seja esgotada.
  2. Qualquer tráfego de pico restante recebe erros 429 RESOURCE_EXHAUSTED. Se configurado, todos os pedidos afetados encontram um recuo exponencial.
  3. Uma determinada percentagem de pedidos que encontraram a retirada exponencial inicial é reagendada para serem tentados novamente no minuto seguinte. Alguns pedidos são tentados várias vezes num único minuto e, em seguida, são repetidos no minuto seguinte.
  4. Se o volume de pedidos for suficientemente elevado, os pedidos repetidos podem encontrar erros 429 RESOURCE_EXHAUSTED e um recuo exponencial novamente. Determinadas rajadas de tráfego podem encontrar um recuo exponencial em momentos diferentes, e as tentativas de enviar tráfego novamente podem convergir no mesmo minuto no futuro.
  5. Se o volume de pedidos continuar elevado, algumas partes do tráfego são repetidas quando o próximo aumento do tráfego começar. O problema é agravado porque é adicionado mais tráfego à fila de pedidos existente. A sua aplicação pode ter dificuldade em manter o registo pendente de pedidos e enviá-los de forma consistente para a Cloud Healthcare API.

Este cenário mostra a importância de conhecer o volume do seu tráfego por minuto. Implemente o volume de tráfego e as retiradas para evitar o congestionamento da rede e garantir que a sua aplicação não encontra muitas falhas que exijam novas tentativas.

Reveja as quotas DICOM e FHIR

Para ver as quotas da Cloud Healthcare API associadas a operações e lojas FHIR e DICOM, consulte os limites de quotas.