Práticas recomendadas para a taxa de transferência do carregamento de dados

Esta página descreve as práticas recomendadas para otimizar o débito de dados quando carrega dados para a Cloud Healthcare API. Estas recomendações destinam-se a profissionais técnicos com experiência na gestão do débito de dados para sistemas de grande escala.

Débito de dados

A taxa de transferência de dados é a quantidade de recursos, como recursos FHIR ou instâncias DICOM, ou bytes que a Cloud Healthcare API ingere a cada segundo.

Restrições de débito de dados

A lista seguinte descreve os motivos pelos quais o débito de dados pode estar restrito:

• Não planeou pedidos de grande volume que causam picos de tráfego.
• As restrições de largura de banda tornam mais lento o carregamento de grandes volumes de dados enviados num curto período de tempo.
• Várias transações simultâneas alteram o mesmo recurso da API Cloud Healthcare, o que provoca contenção de dados.
• Estão a ser feitos demasiados pedidos pequenos. Para mais informações, consulte o artigo Evite pedidos de importação e exportação pequenos.
• Demasiadas operações de longa duração (LROs) executadas em simultâneo e largura de banda limitada.
• Estão agendadas demasiadas LROs ao mesmo tempo, o que leva a falhas.

Repetir pedidos com falha

Se um cliente tentar novamente os pedidos de forma rápida e repetida após falhas, pode exceder as quotas da Cloud Healthcare API. As secções seguintes descrevem como repetir pedidos com falhas de forma eficiente.

Use a retirada exponencial com instabilidade e filas de repetição persistentes

A retirada exponencial com instabilidade introduzida é uma estratégia de processamento de erros padrão para aplicações de rede. Um cliente repete periodicamente os pedidos falhados com intervalos de tempo exponencialmente crescentes entre as repetições e um pequeno intervalo de tempo aleatório.

Certifique-se de que a implementação da retirada exponencial é idempotente para cada nova tentativa, especialmente se estiver a usar uma lógica personalizada para contornar as condições de falha. Consulte a secção 9.2.2 Métodos idempotentes na especificação HTTP para mais informações.

A maioria das linguagens de programação oferece bibliotecas para simplificar a implementação do recuo exponencial e de estratégias de repetição semelhantes. Para novas tentativas de longo prazo ou de vários processos, implemente uma fila de novas tentativas persistente. Esta fila pode repor o mecanismo de nova tentativa se exceder o tempo de recuo máximo.

Use a retirada exponencial ao tentar novamente estes pedidos:

• Operações que modificam um recurso FHIR ou um pacote de recursos FHIR.

• Pedidos LRO síncronos. Tentar novamente se ocorrer um erro quando o LRO é iniciado ou se o LRO falhar.

  As LROs têm erros únicos que podem exigir a implementação das seguintes estratégias de repetição:

  • Use um pacote separado para armazenar dados que falharam numa operação de importação ou criação.
  • Use pedidos síncronos para dados que não foram processados.

Exemplo de algoritmo de retirada exponencial

Um algoritmo de retirada exponencial repete os pedidos exponencialmente, aumentando o tempo de espera entre as repetições até um tempo de retirada máximo. O algoritmo seguinte implementa a retirada exponencial truncada com variância:

1. Envie um pedido para a Cloud Healthcare API.

2. Se o pedido falhar, aguarde 1 + random-fraction segundos e, em seguida, repita o pedido.

3. Se o pedido falhar, aguarde 2 + random-fraction segundos e, em seguida, repita o pedido.

4. Se o pedido falhar, aguarde 4 + random-fraction segundos e, em seguida, repita o pedido.

5. Continue este padrão, aguardando 2ⁿ + random-fraction segundos após cada nova tentativa, até um máximo de maximum-backoff vezes.

6. Após deadline segundos, pare de repetir o pedido.

Use os seguintes valores à medida que implementa o algoritmo:

• Antes de cada nova tentativa, o tempo de espera é de min((2n + random-fraction), maximum-backoff), com n a começar em 0 e a ser incrementado em 1 para cada nova tentativa.

• Substitua random-fraction por um valor fracionário aleatório inferior ou igual a 1. Use um valor diferente para cada nova tentativa. A adição deste valor aleatório impede que os clientes fiquem sincronizados e enviem várias novas tentativas ao mesmo tempo.

• Substitua maximum-backoff pela quantidade máxima de tempo, em segundos, a aguardar entre novas tentativas. Os valores típicos são 32 ou 64 (2⁵ ou 2⁶) segundos. Escolha o valor que funciona melhor para o seu exemplo de utilização.

• Substitua deadline pelo número máximo de segundos para continuar a enviar novas tentativas. Escolha um valor que reflita o seu exemplo de utilização.

O cliente pode tentar novamente após atingir o tempo maximum-backoff usando o mesmo valor que o recuo. Por exemplo, se o maximum-backoff tempo for de 64 segundos, tente novamente a cada 64 segundos. Certifique-se de que o cliente não tenta novamente indefinidamente.

Implemente a limitação da taxa do lado do cliente com a modelação do tráfego

A limitação da taxa protege os sistemas de grande escala, impedindo que sejam sobrecarregados por pedidos excessivos. Se a limitação da taxa do lado do cliente não for suficiente, o sistema de quotas da Cloud Healthcare API pode restringir o débito de dados. Para mais informações, consulte o artigo Práticas recomendadas para a gestão de quotas.

Se tiver requisitos adicionais, como a entrega garantida em todas as novas tentativas, as estratégias em Tentar novamente pedidos falhados podem ser insuficientes. A modelagem de tráfego é uma técnica de limitação de taxa que mantém a taxa de pedidos do lado do cliente dentro das restrições de largura de banda. Isto distribui os picos de carga ao longo de horas ou minutos, o que melhora o débito. Quando a quota está limitada, a modelagem de tráfego pode alcançar um débito mais elevado do que usar apenas novas tentativas, porque evita a rejeição e acompanha as unidades de trabalho.

Pode implementar a modelação de tráfego para operações de criação, eliminação, atualização e eliminação (CRUD) síncronas, incluindo fhir.executeBundle.

Requisitos de formatação de tráfego

Para implementar a modelagem de tráfego, o seu sistema tem de implementar o seguinte:

• Uma fila de processamento suportada por armazenamento com redundância para evitar falhas de disco.
• Coordenou os trabalhadores para retirarem dados da fila de processamento.
• Deteção de utilização geral para ajustar o número de trabalhadores e a respetiva velocidade de processamento com base nos limites de quota.
• Recuperação de desastres para a fila de processamento com base no armazenamento. Se ocorrer um desastre, o seu sistema tem de conseguir limpar ou recuperar a fila.
• Redução das LROs durante as horas de pico. Para mais informações, consulte os artigos Planeie e use a quota de forma eficiente e Coloque em fila e faça a gestão de LROs.

Nos seguintes casos, a modelagem de tráfego pode ser necessária apenas para uma única fase do pipeline:

• Limitar o número de trabalhadores que extraem dados de um passo anterior do pipeline.
• Limitar cada trabalhador individualmente.
• Usar um coordenador do conjunto de trabalhadores para ajustar a taxa à qual as unidades de trabalho individuais, como consultas por segundo (QPS) ou bytes carregados por segundo, são processadas.

Implemente a limitação de taxa noutras áreas do seu sistema

Pode usar linguagens de programação e frameworks existentes para implementar a modelação do tráfego. Considere os seguintes projetos de código aberto e soluções pré-criadas:

• Limitação do lado do cliente no Apache Beam. Consulte o artigo Ajuste de escala automático horizontal para obter informações sobre como controlar a limitação através das flags numWorkers e maxNumWorkers.

• A classe RateLimiter Java do conjunto de bibliotecas Java principais do Google Guava.

• O módulo ratelimiter do Python.

Para o controlo de fluxo, use a biblioteca de cliente Pub/Sub de alto nível.

Escolha entre o processamento assíncrono e síncrono

Uma camada de proxy do lado do cliente que envolve pedidos à Cloud Healthcare API, mostrada em Resolver erros em várias camadas, também pode controlar a limitação em serviços que usam a Cloud Healthcare API. Consoante o tipo de restrição de tráfego necessário, use uma destas opções:

Assíncrono

Use o processamento assíncrono para colocar pedidos em fila e controlar os trabalhadores. Uma camada de proxy escreve os pedidos recebidos na fila e devolve respostas 200 OK após cada pedido ser colocado em fila. Esta opção funciona melhor para pedidos de gravação, mas pode ser usada para pedidos de leitura numa estrutura LRO se os clientes puderem receber resultados de leitura.

Síncrono

O processamento síncrono oferece um mecanismo de feedback simples se uma unidade de trabalho depender da conclusão de uma unidade anterior. Uma camada de proxy atrasa os pedidos de saída com base em limites de QPS ou de débito de bytes, e o cliente bloqueia e aguarda a resposta da camada de proxy.

A camada de proxy pode ajustar a respetiva limitação de taxa com base no número de instâncias ou pode coordenar com um processo de controlador que ajusta o limite de taxa a cada poucos segundos. Para que a camada de proxy acompanhe o número de instâncias e os respetivos limites de taxa, cada instância de proxy pode ler regularmente um ficheiro ou fazer uma chamada de procedimento remoto (RPC) com os limites de taxa codificados.

O processamento síncrono tem, por vezes, as seguintes desvantagens:

• Os recursos nas camadas de proxy e cliente estão indisponíveis enquanto o cliente bloqueia e aguarda uma resposta. Isto pode levar a erros, tempos limite e um débito de dados inferior, o que dificulta o dimensionamento.

• Se o cliente e a camada de proxy se desligarem, é necessário mais trabalho para garantir que os dados foram modificados conforme pedido.

Use o Cloud Tasks

Use o Cloud Tasks para transferir pedidos para uma fila. O Cloud Tasks define e monitoriza automaticamente as seguintes Google Cloud quotas:

• Tamanho máximo da sequência e concorrência máxima de pedidos através do objeto RateLimits
• Limites de novas tentativas através do objeto RetryConfig

Consulte o artigo Crie filas para criar filas no Cloud Tasks. O recurso Queue mostra as opções que pode definir numa fila. Por exemplo, pode usar o objeto RetryConfig para implementar a retirada exponencial. Consulte as bibliotecas cliente do Cloud Tasks para bibliotecas específicas de idiomas.

Quando usar o Cloud Tasks, tenha em atenção o seguinte:

• O Cloud Tasks não garante a entrega exatamente uma vez. Na entrega exatamente uma vez, todos os pedidos que contenham dados duplicados são reconhecidos como duplicados e ignorados pelo servidor. Para mais informações, consulte o artigo After Lambda: exactly once processing in Dataflow, Part 1.
• O tamanho máximo da tarefa pode ser muito inferior ao tamanho máximo do pacote FHIR na Cloud Healthcare API. Para mais informações, consulte as quotas e os limites do Cloud Tasks e as quotas e os limites da Cloud Healthcare API.
• O Cloud Tasks tem problemas e limitações.

Combine pacotes FHIR com limitadores de taxa

As novas tentativas de pacotes FHIR com retirada exponencial e limitadores de taxa ajudam a manter um débito de dados elevado e a gerir picos de carga.

Um cliente pode enviar pacotes FHIR em lote e de transação para o Cloud Tasks, que envia os pedidos no pacote para a Cloud Healthcare API. Se o limitador de taxa estiver cheio ou acima da quota porque atingiu o tamanho máximo da fila e ficou sem espaço em disco, o cliente pode implementar o recuo exponencial para colocar os pacotes em fila.

Evite que a fila do limitador de taxa fique cheia monitorizando estes recursos:

• Quotas de operações FHIR na Cloud Healthcare API
• Quotas do limitador de velocidade
• Erros do limitador de velocidade

Se a fila do limitador de taxa ficar cheia, o seu sistema tem de alertar um humano e impedir que o cliente envie pedidos.

Use ligações HTTP persistentes (keep-alive reutilizáveis)

Por predefinição, a Cloud Healthcare API abre uma nova ligação TCP para cada pedido CRUD. Isto requer um TCP handshake, o que pode causar sobrecarga e degradar o desempenho. Para melhorar o desempenho, use o HTTP keep-alive para manter a ligação TCP aberta para vários pedidos.

Para usar HTTP keep-alive em HTTP/1.1, defina o cabeçalho Connection como keep-alive:

Connection: keep-alive

O HTTP/2 usa uma ligação TCP para pedidos sequenciais e simultâneos, o que evita automaticamente a sobrecarga.

A biblioteca Python requests usa o keep-alive HTTP por predefinição. Se estiver a usar o Node.js, defina keepAlive como true quando criar um objeto http.Agent e, em seguida, transmita o objeto no seu pedido.

Use uma framework de testes

Uma estrutura de testes garante que o seu código funciona e ajuda a fazer o seguinte:

• Prepare-se para picos de tráfego súbitos numa aplicação ou num pipeline.
• Teste se o recuo exponencial e a limitação da taxa do lado do cliente melhoram o desempenho. Os testes podem mostrar se estas implementações criam um registo pendente de tarefas que têm de ser processadas separadamente.
• Separe e controle o tráfego de alta prioridade. Por exemplo, se um utilizador estiver à espera de uma resposta, a carga de trabalho nas tarefas de processamento em segundo plano pode ser reduzida para garantir que a experiência do utilizador não é degradada.
• Teste estratégias de colocação em fila síncronas e assíncronas para regular o fluxo de tráfego ou teste se a camada de proxy processa o feedback negativo.
• Planeie a recuperação de desastres. Normalmente, isto requer a reposição do tráfego de entrada ou a utilização de filas para retomar o tráfego após o fim do desastre.

Utilize o Cloud Monitoring

Use o Cloud Monitoring para monitorizar os seus ambientes de teste e de produção. Siga estas recomendações:

• Integre o Cloud Tasks com outros Google Cloud serviços de registo e monitorização, como os registos de auditoria da nuvem.
• Crie métricas personalizadas com a API Cloud Monitoring para acompanhar métricas importantes, como novas tentativas, tamanhos das filas e antiguidade das filas.
• Crie objetivos ao nível do serviço (SLOs) e indicadores do nível de serviço (SLIs) para os seus ambientes. Consulte a Introdução aos SLIs para ver recomendações.
• Crie políticas de alertas com o Google Cloud Observability. As políticas de alerta enviam-lhe notificações sobre problemas, como se o seu sistema estiver sob stress ou exigir intervenção humana.
• Crie manuais de procedimentos operacionais para que os administradores do sistema saibam o que fazer se uma política de alerta enviar uma notificação.

• Use os manuais de procedimentos operacionais num ambiente de teste para responder aos seguintes cenários:

  • Atrasos causados pela limitação de taxa
  • Rejeição causada pela ultrapassagem dos limites de quota
  • Picos de tráfego recebido

Evite 429 Resource Exhausted operation_too_costly erros

Fazer milhares de atualizações paralelas todos os dias a um recurso FHIR pode causar conflitos de bloqueio, latência e impedir a conclusão das transações. As transações que não podem ser concluídas podem criar um atraso de 429 Resource Exhausted operation_too_costly erros:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to lock contention while executing transactional bundle. Resource type: FHIR_RESOURCE_TYPE",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

No erro, "custo" refere-se à utilização de recursos e à taxa de transferência de dados, não aos custos de faturação.

Um erro 429 Too Many Requests nem sempre indica um problema de quota. O erro pode ocorrer quando o servidor FHIR da API Cloud Healthcare deteta uma contenção excessiva de bloqueios nos registos da base de dados. Isto pode acontecer devido a muitas operações num pacote FHIR ou a uma combinação de operações CRUD.

Considere o seguinte cenário:

1. Um pacote de transações FHIR que atualiza um recurso Patient e outros recursos FHIR bloqueia o recurso Patient até a transação terminar.

2. Vários pacotes FHIR tentam atualizar o recurso Patient em paralelo e ocorre uma contenção de bloqueio. As respostas de erro incluem um campo diagnostics com o texto Resource type: PATIENT.

   Pode tentar atualizar o recurso Patient novamente com retirada exponencial, mas os períodos de contenção de bloqueio longos podem levar a tempos limite, débito reduzido e aumento da utilização de recursos.

3. O servidor FHIR da Cloud Healthcare API acaba por detetar um atraso de transações e liberta carga devolvendo erros operation_too_costly. Isto limita o tráfego e evita mais erros.

   Os erros operation_too_costly limitam todas as operações CRUD de FHIR no seu projetoGoogle Cloud , o que afeta todas as aplicações associadas ao seu projeto.

Resolva problemas de erros 429 Too Many Requests

Para resolver problemas de erros 429 Too Many Requests, pesquise no Cloud Logging. Os erros que contêm operation_too_costly indicam contenção de bloqueios. Se os erros forem causados pelo esgotamento de recursos, verifique se existem problemas de quota.

Se ocorrer uma limitação, os pacotes de transações podem falhar devido a níveis elevados de contenção de bloqueios e produzir o seguinte erro:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to cumulative heavy load or lock contention in this project while executing transactional bundle, please see https://cloud.google.com/healthcare-api/docs/troubleshooting#fhir_transaction_bundle_heavy_load for more information",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

Para resolver o problema do erro, aceda ao link FHIR transactional bundle aborted due to cumulative heavy load no campo diagnostics.

Evite pacotes grandes

O erro 429 Too Many Requests é mais provável com pacotes de transações grandes. Os pacotes de qualquer tamanho podem criar gargalos de débito. Teste diferentes pacotes para encontrar o tamanho ideal.

Os pacotes grandes com novas tentativas podem ter retornos de desempenho decrescentes e são mais suscetíveis a ter várias falhas. Os clientes devem implementar lógica adicional para gerir o subconjunto de recursos FHIR que falharam numa transação.

Os conjuntos de lotes podem encontrar erros 429 Too Many Requests e 413 Request Entity Too Large e gargalos de débito se forem grandes ou tiverem um QPS elevado.

Evite usar pacotes grandes com milhares de transações. Em vez disso, faça o seguinte:

• Use conjuntos de transações mais pequenos que suportem a consistência dos dados. Se os recursos FHIR não dependerem uns dos outros, atualize-os separadamente. Por exemplo, um recurso FHIR pode não depender da versão específica de outro recurso no mesmo pacote.
• Use algum processamento em lote em pacotes e evite pedidos individuais. O processamento em lote pode melhorar o desempenho, mas os lotes grandes podem causar erros e degradar a taxa de transferência de dados. Os conjuntos de lotes de tamanho semelhante têm menos contenção porque não mantêm bloqueios nas atualizações de recursos FHIR.

Os pequenos conjuntos de transações evitam a contenção porque só têm alguns bloqueios de cada vez e terminam rapidamente. Isto ajuda a evitar um atraso de transações acumuladas.

Débito de LRO

Consulte o artigo sobre Débito de dados LRO.

Opções de armazenamento de dados FHIR

Se o volume de dados FHIR for pequeno a moderado, use o fhir.create para armazenar dados. Para armazenar grandes volumes de recursos FHIR, use o fhir.executeBundle ou o fhirStores.import. Para obter informações sobre cada método, consulte as opções de importação de FHIR.

Importe recursos FHIR

Considere o seguinte ao decidir se deve usar a importação FHIR:

• A importação de FHIR não limita o tamanho total dos dados que importa. Se um pacote FHIR exceder 50 MB, pode carregar os recursos FHIR para o Cloud Storage e importá-los. Evite importações simultâneas de latência elevada ou grandes, ou o débito de dados pode ser limitado.

• A importação de FHIR tem menos complexidade do que a utilização de FHIR bundles. Por exemplo, não tem de fazer o seguinte:

  • Divida pacotes grandes em pacotes mais pequenos
  • Gerir horários
  • Volte a tentar erros transitórios ao nível do recurso ou do pacote

• A importação de FHIR não aplica a integridade referencial. Para mais informações, consulte o artigo Integridade referencial da FHIR.

• Não use a importação de FHIR quando a atualização dos dados for uma prioridade elevada. As importações podem ser rápidas, mas podem sofrer atrasos de horas ou dias.

• As importações FHIR têm um melhor desempenho quando existem poucos LROs no seu Google Cloud projeto.

• A importação de FHIR pode atingir um elevado débito de dados se a sua aplicação conseguir processar erros e falhas em massa num subconjunto de recursos.

Use pacotes FHIR

Use pacotes FHIR em vez da importação FHIR nos seguintes casos:

• É demasiado caro, em termos de custos de faturação ou largura de banda da rede, criar um pipeline para armazenar dados no Cloud Storage e importá-los.

• A integridade referencial tem de ser aplicada.

• A validação do perfil FHIR tem de ser aplicada.

• Tem de enviar notificações do Pub/Sub quando os recursos FHIR são armazenados. A importação de FHIR não suporta notificações do Pub/Sub.

• A atualidade dos dados é uma prioridade e os dados têm de ser carregados em segundos ou minutos. No entanto, mesmo num sistema bem arquitetado, o débito de dados pode ser limitado pelo seguinte:

  • Atrasos a montante no processamento de pipelines. Os pipelines podem precisar de mais tempo para preparar os dados antes de poderem ser carregados.
  • Recuos, novas tentativas e camadas de proxy de modelação de tráfego.

Os pacotes FHIR têm as seguintes limitações:

• A quota e a faturação são aplicadas a cada operação no pacote como se cada operação fosse executada de forma independente. Por exemplo, se um pacote tiver 10 operações POST, 5 operações GET e 1 operação DELETE, a quota e a faturação aplicadas ao pacote são as mesmas que se essas operações fossem executadas de forma independente.

• Os pacotes de transações grandes têm maior probabilidade de ter conflitos de transações que resultam em contenção de bloqueios. Para mais informações, consulte o artigo Evite erros 429 Resource Exhausted operation_too_costly.

• Os conjuntos de lotes podem melhorar o débito de dados, mas não têm capacidades de consistência transacional, como a integridade referencial.

• Os conjuntos de lotes grandes podem ter um débito reduzido. Para mais informações, consulte o artigo Evite pacotes grandes.

Opções de armazenamento de dados DICOM

Pode usar os seguintes métodos para alcançar um elevado débito de dados quando envia dados de um sistema de arquivo e comunicação de imagens (PACS) para a API Cloud Healthcare:

O adaptador DICOM da Cloud Healthcare API de código aberto que usa o protocolo DICOM message service element (DIMSE)

O adaptador otimiza o débito de dados quando sincroniza um PACS com a Cloud Healthcare API. Antes da sincronização, execute testes de desempenho e verifique se o adaptador consegue manter o débito de dados máximo.

Use este adaptador se não conseguir carregar ficheiros DICOM para o Cloud Storage através do Serviço de transferência de armazenamento ou de outra opção de transferência. Por exemplo, pode não conseguir cumprir estes requisitos do serviço de transferência de armazenamento:

• Montar um sistema de ficheiros em cada máquina que aloja agentes no seu conjunto de agentes para obter dados de origem.
• Se transferir dados a um intervalo regular em vez de um carregamento em lote único, tem de medir as alterações ao tamanho dos dados ao longo do tempo para determinar o que mudou.
• Maximizar o desempenho da transferência de agentes.
• Pagar e atribuir armazenamento do Cloud Storage.
• Validar transferências de dados para o Cloud Storage.
• Remover recursos do Cloud Storage depois de importar dados para a Cloud Healthcare API e corrigir quaisquer erros de importação.
• Agendar intervalos de carregamento em lote com base na rede e na capacidade de armazenamento de um sistema clínico.

Recomendamos que use o serviço de transferência de armazenamento para um único carregamento em lote para preencher um armazenamento DICOM. A utilização regular do serviço de transferência de armazenamento requer trabalho adicional, como um pipeline de importação síncrono. Para mais informações, consulte o artigo Detalhes da transferência do sistema de ficheiros do Serviço de transferência de armazenamento.

dicomStores.import

Use este método para armazenar grandes volumes de dados DICOM.

DICOMweb Store Transaction

Use este método para armazenar dados DICOM de forma programática.

Faça a gestão da quota para otimizar o débito de dados

As secções seguintes descrevem como gerir e planear a quota para otimizar a taxa de transferência de dados. Para ver práticas recomendadas gerais sobre a gestão de quotas, consulte o artigo Práticas recomendadas de gestão de quotas.

Planeie a quota para tráfego previsível

Planeie os requisitos de quota analisando primeiro o tráfego diário típico da sua aplicação cliente. Mesmo que o tráfego seja previsível, planeie uma quota superior à que precisa em média. Isto ajuda a evitar erros e oferece uma margem de segurança contra picos de tráfego ou aumentos ocasionais na utilização diária.

O diagrama seguinte mostra pedidos à Cloud Healthcare API que são consistentes em tamanho e enviados em padrões previsíveis:

Figura 1. O carregamento agregado da API por hora em conjuntos de dados e repositórios de dados num Google Cloud projeto

.

Planeie a quota para pedidos de grande volume

Evite agendar grandes trabalhos em lote durante as horas de pico. Para mais informações, consulte o artigo Privilegie as transações de baixo volume de forma consistente.

O diagrama seguinte mostra um padrão de tráfego previsível. No entanto, um pedido em lote de grande volume durante um período de pico de tráfego excede a quota disponível. Isto pode causar erros 429 Resource Exhausted para todos os pedidos no seu projeto.

Figura 2. Uma distribuição irregular da utilização de recursos causada por uma tarefa em lote grande durante as horas de pico.

Se o seu sistema tiver uma quota de flexibilidade adicional, os pequenos picos de tráfego não causam erros nem fazem com que as cargas de pico previsíveis encontrem erros. Os pequenos picos têm de ser distribuídos por muitas lojas de dados, aplicações e outros clientes que geram carga no projeto Google Cloud .

Para evitar que uma única tarefa em lote grande cause picos de tráfego, consulte a secção Evite pacotes grandes.

Peça quota adicional

Para manter um elevado débito de dados e evitar erros 429 Resource Exhausted, consulte as práticas recomendadas nesta página, especialmente a secção Gerir a quota para otimizar o débito de dados. Estas práticas recomendadas garantem que a sua aplicação cliente é robusta e pode ser dimensionada com as alterações no volume de pedidos. É improvável que a solicitação de quota adicional sem implementar as práticas recomendadas impeça erros a longo prazo.

Se implementar as práticas recomendadas e ainda precisar de mais quota, consulte o artigo Práticas recomendadas para pedir quota adicional.

Recursos de débito de carregamento de dados

Para mais informações sobre o débito da ingestão de dados, consulte o artigo Faça a gestão do tráfego e do carregamento para as suas cargas de trabalho no Google Cloud.