Práticas recomendadas para a taxa de transferência de ingestão de dados

Nesta página, descrevemos as práticas recomendadas para otimizar a capacidade de processamento ingerir dados na API Cloud Healthcare. Essas recomendações são para profissionais técnicos com experiência em gerenciar a capacidade de processamento de dados sistemas de grande escala.

Taxa de transferência de dados

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

Restrições de capacidade de dados

A lista a seguir descreve os motivos pelos quais a taxa de transferência de dados pode ser limitada:

• Você não planejou solicitações de grande volume que causam picos de tráfego.
• As restrições de largura de banda atrasam a ingestão de grandes volumes de dados enviados em um curto período.
• Várias transações simultâneas alteram a mesma API Cloud Healthcare recurso que causa a contenção de dados.
• Muitas solicitações pequenas estão sendo feitas. Para mais informações, consulte Evitar solicitações de importação e exportação pequenas.
• Muitas operações de longa duração (LROs, na sigla em inglês) são executadas simultaneamente e a largura de banda é limitada.
• Muitas LROs são programadas ao mesmo tempo, o que leva a falhas.

Tentar novamente solicitações com falha

Se o cliente logo e repete solicitações após falhas, pode exceder a API Cloud Healthcare cotas. As seções a seguir descrevem como repetir com eficiência as solicitações com falha.

Use a espera exponencial com filas de tentativas instáveis e persistentes

A espera exponencial com instabilidade introduzida é uma estratégia padrão de tratamento de erros para aplicativos de rede. Um cliente repete periodicamente solicitações com falha com atrasos exponencialmente crescentes entre as novas tentativas e um pequeno atraso aleatório.

Verifique se a implementação de espera exponencial é idempotente para cada nova tentativa, especialmente se você estiver usando uma lógica personalizada para ignorar e as condições de falha. Consulte 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 de backoff exponencial e estratégias de nova tentativa semelhantes. Para retenções de longo prazo ou de vários processos, implemente uma fila de repetição persistente. Essa fila pode redefinir o mecanismo de nova tentativa se você exceder o tempo máximo de espera.

Use a espera exponencial ao repetir estas solicitações:

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

• Solicitações LRO síncronas. Tente novamente se houver um erro quando a LRO for iniciada ou se ela falhar.

  Os LROs têm erros exclusivos que podem exigir a implementação das seguintes estratégias de nova tentativa:

  • Use um pacote separado para armazenar dados que falharam em uma operação de criação ou importação.
  • Usar solicitações síncronas para dados com falha no processamento.

Exemplo de algoritmo de espera exponencial

Um algoritmo de retirada exponencial repete solicitações exponencialmente, aumentando o tempo de espera entre novas tentativas até um tempo máximo de retirada. O algoritmo a seguir implementa a espera exponencial truncada com instabilidade:

1. Envie uma solicitação para a API Cloud Healthcare.

2. Se a solicitação falhar, aguarde 1 + random-fraction segundos e repita a solicitação.

3. Se a solicitação falhar, aguarde 2 + random-fraction segundos e repita a solicitação.

4. Se a solicitação falhar, aguarde 4 + random-fraction segundos e repita a solicitação.

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

6. Depois de deadline segundos, pare de repetir a solicitação.

Use os seguintes valores ao implementar o algoritmo:

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

• Substitua random-fraction por um valor fracionário aleatório menor ou igual a 1. Use um valor diferente para cada nova tentativa. Adicionar esse valor aleatório evita que os clientes sejam sincronizados e enviem muitas novas tentativas ao mesmo tempo.

• Substitua maximum-backoff pelo tempo máximo, em segundos, para aguardar entre as novas tentativas. Os valores típicos são 32 ou 64 (2⁵ ou 2⁶) segundos. Escolha o valor ideal para seu caso de uso.

• Substitua deadline pelo número máximo de segundos para continuar enviando novas tentativas. Escolher um valor que reflita seu caso de uso.

O cliente pode tentar novamente após atingir o tempo maximum-backoff usando a mesma como a espera. Por exemplo, se o tempo de maximum-backoff for de 64 segundos, tentar novamente a cada 64 segundos. Verifique se o cliente não tenta indefinidamente.

Implementar a limitação de taxa do lado do cliente com a modelagem de tráfego

A limitação de taxa protege sistemas em grande escala, impedindo que eles sejam sobrecarregados por solicitações excessivas. Se a limitação de taxa do lado do cliente não for suficiente, o sistema de cotas da API Cloud Healthcare poderá restringir o throughput de dados. Para mais informações, consulte Práticas recomendadas para o gerenciamento de cotas.

Se você tiver outros requisitos, como entrega garantida em novas tentativas, as estratégias em Repetir solicitações com falha podem ser insuficientes. Modelagem de tráfego é uma técnica de limitação de taxa que mantém a taxa de solicitações do lado do cliente dentro das limitações de largura de banda. Isso distribui picos de carga entre horas ou minutos, o que melhora a capacidade de processamento. Quando a cota é restrita, a modelagem de tráfego pode alcançar uma capacidade maior do que usando apenas novas tentativas, porque evita oposição e rastreia unidades de worker.

É possível implementar a modelagem de tráfego para operações síncronas de criação, exclusão, atualização e exclusão (CRUD), incluindo fhir.executeBundle.

Requisitos da modelagem de tráfego

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

• Uma fila de processamento com suporte de armazenamento com redundância para evitar falhas no disco.
• Workers coordenados para extrair da fila de processamento.
• Em geral, use a detecção para ajustar o número de workers e a velocidade de processamento deles. com base nos limites de cota.
• Recuperação de desastres para a plataforma com suporte fila de processamento. Se ocorrer um desastre, o sistema precisa ser capaz de limpar ou recuperar a fila.
• Redução de LROs durante os horários de pico. Para mais informações, consulte Planejar e usar a cota de maneira eficiente e Enfileirar e gerenciar LROs.

Nos casos a seguir, a modelagem de tráfego pode ser necessária apenas para um único fase do pipeline:

• Limitação do número de workers que recebem pull de uma etapa anterior do pipeline.
• Limitar cada worker individualmente.
• Usar um coordenador de pool de workers para ajustar a taxa em que unidades de trabalho individuais, como consultas por segundo (QPS) (bytes ingeridos por segundo) são processados.

Implementar a limitação de taxa em outras áreas do sistema

É possível usar linguagens de programação e frameworks para implementar a modelagem de tráfego. Considere os seguintes projetos de código aberto e soluções pré-criadas:

• Limitação no lado do cliente no Apache Beam. Consulte Escalonamento automático horizontal para saber mais sobre como controlar a limitação usando os parâmetros numWorkers e maxNumWorkers.

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

• O ratelimiter do Python mais tarde neste módulo.

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

Escolher entre processamento assíncrono e síncrono

uma camada de proxy do lado do cliente que une solicitações para a API Cloud Healthcare; mostrado em Solucionar erros em várias camadas, também pode controlar a limitação entre serviços que usam a API Cloud Healthcare. Dependendo tipo de modelagem de tráfego necessário, use uma destas opções:

Assíncrono

Usar o processamento assíncrono para enfileirar solicitações e controlar workers. Uma camada de proxy grava as solicitações recebidas na fila e retorna respostas 200 OK depois que cada solicitação é colocada na fila. Isso funciona melhor para solicitações de gravação, mas pode ser usado para solicitações de leitura em uma estrutura LRO se os clientes puderem receber resultados de leitura.

Síncrona

O processamento síncrono oferece um mecanismo de feedback simples se uma unidade de o trabalho depende do término de uma unidade anterior. Uma camada de proxy atrasa solicitações de saída com base em limites de capacidade de processamento de QPS ou bytes, e o cliente bloqueia e aguarda o proxy a resposta da camada.

A camada de proxy pode ajustar o limite 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 o camada de proxy para rastrear o número de instâncias e sua taxa , cada instância de proxy pode ler regularmente um arquivo ou criar com os limites de taxa codificados.

Às vezes, o processamento síncrono tem as seguintes desvantagens:

• Recursos no cliente e as camadas de proxy fiquem indisponíveis enquanto o cliente bloqueia e aguarda uma resposta. Isso pode causar erros, tempos limite e menos dados a capacidade de processamento, dificultando o escalonamento.

• Se a camada de cliente e proxy se desconectar, será necessário mais trabalho para garantir que os dados foram modificados conforme solicitado.

Usar o Cloud Tasks

Use o Cloud Tasks para transferir solicitações para uma fila. O Cloud Tasks define e monitora automaticamente as seguintes cotas do Google Cloud:

• Tamanho máximo do burst e simultaneidade máxima de solicitação usando o objeto RateLimits
• Limites de novas tentativas usando o objeto RetryConfig

Consulte Criar filas para criar filas no Cloud Tasks. O recurso Queue mostra as opções que podem ser definidas em uma fila. Por exemplo, é possível usar o objeto RetryConfig para implementar a espera exponencial. Consulte Bibliotecas de cliente do Cloud Tasks para bibliotecas específicas da linguagem.

Ao usar o Cloud Tasks, considere o seguinte:

• O Cloud Tasks não garante a entrega exatamente uma vez. No envio exatamente uma vez, todas as solicitações com dados duplicados são reconhecidas como duplicatas e ignoradas pelo servidor. Para mais informações, consulte Além da arquitetura Lambda: processamento único no Dataflow, parte 1.
• O tamanho máximo da tarefa pode ser muito menor do que o tamanho máximo do pacote FHIR na API Cloud Healthcare. Para mais informações, consulte Cotas e limites do Cloud Tasks e Cotas e limites da API Cloud Healthcare.
• O Cloud Tasks tem problemas e limitações.

Combinar pacotes FHIR com limitadores de taxa

A repetição de tentativas de pacotes FHIR com backoff exponencial e limitadores de taxa ajuda a manter uma alta taxa de transferência de dados e a gerenciar picos de carga.

Um cliente pode enviar pacotes FHIR de lote e transação para o Cloud Tasks, que envia as solicitações no pacote para a API Cloud Healthcare. Se o limitador de taxa estiver cheio ou com cota excedente porque atingiu o tamanho máximo da fila e ficou sem espaço em disco, o cliente poderá implementar a espera exponencial para colocar os pacotes na fila.

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

• Cotas de operação FHIR na API Cloud Healthcare
• Cotas do limitador de taxa
• Erros do limitador de taxa

Se a fila do limitador de taxa ficar cheia, seu sistema precisará alertar uma pessoa e impedir que o cliente envie solicitações.

Usar conexões HTTP persistentes (sinal de atividade reutilizável)

Por padrão, a API Cloud Healthcare abre uma nova conexão TCP para cada CRUD. Isso requer um handshake TCP, que pode causar sobrecarga e prejudicar o desempenho. Para melhorar o desempenho, use sinal de atividade HTTP para manter a conexão TCP aberta para várias solicitações.

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

Connection: keep-alive

O HTTP/2 usa uma conexão TCP para solicitações sequenciais e simultâneas, o que evita a sobrecarga automaticamente.

O Python requests usa o sinal de atividade HTTP por padrão. Se estiver usando Node.js, defina keepAlive para true ao criar um objeto http.Agent e, em seguida, transmitir o objeto na solicitação.

Usar um framework de teste

Um framework de teste garante que o código funcione e ajuda você a fazer o seguinte:

• Prepare-se para picos de tráfego repentinos em um aplicativo ou pipeline.
• Testar se a espera exponencial e a limitação de taxa do lado do cliente para melhorar o desempenho. Os testes podem mostrar se essas implementações criam uma ou pendências de tarefas que precisam ser tratadas separadamente.
• Separar e controlar o tráfego de alta prioridade. Por exemplo, se um usuário estiver esperando a carga de trabalho das tarefas de processamento em segundo plano pode ser reduzida para garantir que a experiência do usuário não seja prejudicada.
• Teste estratégias de fila síncronas e assíncronas para regular o fluxo de tráfego ou teste se a camada de proxy lida com o pushback.
• Planeje a recuperação de desastres. Isso geralmente requer a redefinição do tráfego de entrada ou o uso de filas para retomar o tráfego após o fim do desastre.

Usar o Cloud Monitoring

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

• Integrar o Cloud Tasks a outros Serviços de geração de registros e monitoramento do Google Cloud, como os Registros de auditoria do Cloud.
• Crie métricas personalizadas com a a API Cloud Monitoring para rastrear as principais métricas, como novas tentativas, tamanhos de fila e tempo da fila.
• Crie objetivos de nível de serviço (SLOs) e indicadores de nível de serviço (SLIs) para seus ambientes. Consulte Introdução aos SLIs para conferir recomendações.
• Crie políticas de alertas usando a Google Cloud Observability. As políticas de alerta notificam você sobre problemas, como se o sistema estiver sob estresse ou precisar de intervenção humana.
• Crie playbooks operacionais para que os administradores do sistema saibam o que fazer se uma política de alertas enviar uma notificação.

• Use os playbooks operacionais em um ambiente de preparo para responder às cenários a seguir:

  • Backlogs causados pela limitação de taxa
  • Dificuldade causada pelo limite de cota excedido
  • Picos de tráfego de entrada

Evitar erros 429 Resource Exhausted operation_too_costly

Fazer milhares de atualizações paralelas todos os dias em um recurso FHIR pode causar contenção de bloqueios e latência e impede e transações sejam concluídas. As transações que não podem ser concluídas podem criar um acúmulo de erros 429 Resource Exhausted operation_too_costly:

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, "cost" se refere ao uso de recursos e à capacidade de processamento de dados, e não aos custos de faturamento.

Um erro 429 Too Many Requests nem sempre indica um problema de cota. O pode ocorrer quando o servidor FHIR da API Cloud Healthcare detecta bloqueio excessivo contenção de registros de banco de dados. Isso pode acontecer devido a muitas operações em um pacote FHIR ou uma combinação de operações CRUD.

Pense no seguinte cenário:

1. Um pacote de transações do FHIR que atualiza um recurso "Paciente" e outros recursos do FHIR bloqueia o recurso "Paciente" até que a transação seja concluída.

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

   É possível tentar atualizar o recurso de paciente com espera exponencial, mas períodos longos de contenção de bloqueio podem levar a tempos limite, redução de throughput e aumento do uso de recursos.

3. O servidor FHIR da API Cloud Healthcare eventualmente detecta um atraso de transações e de carga, retornando erros operation_too_costly. Isso limita o tráfego e evita mais erros.

   Os erros operation_too_costly limitam todas as operações FHIR CRUD na sua Projeto do Google Cloud, que afeta todos os aplicativos ao seu projeto.

Resolver erros 429 Too Many Requests

Para resolver problemas de 429 Too Many Requests, pesquise no Cloud Logging. Erros que contêm operation_too_costly indicam contenção de bloqueio. Se os erros forem causados pelo esgotamento de recursos, verifique se há problemas de cota.

Em caso de limitação, os pacotes de transação podem falhar devido a níveis altos de contenção de bloqueio e produzir este 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 erro, acesse o 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. Pacotes de qualquer tamanho podem criar gargalos de capacidade de processamento. Teste diferentes pacotes para encontrar o tamanho ideal.

Os pacotes grandes com novas tentativas podem ter retornos de desempenho cada vez menores e são mais suscetíveis a várias falhas. Os clientes precisam implementar outra lógica para gerenciar o subconjunto de recursos FHIR que falharam em uma transação.

Pacotes em lote podem encontrar 429 Too Many Requests e 413 Request Entity Too Large. erros e gargalos de capacidade de processamento se forem grandes ou têm um QPS alto.

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

• Use pacotes de transações menores que oferecem suporte à consistência de dados. Se FHIR os recursos não dependem 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 lotes em pacotes e evite solicitações individuais. O agrupamento pode melhorar o desempenho, mas lotes grandes podem causar erros e degradar a capacidade de dados. Os pacotes de lote de tamanho semelhante têm menos contenção porque não mantêm bloqueios nas atualizações de recursos do FHIR.

Pacotes de transações pequenas evitam a contenção porque mantêm apenas alguns bloqueios por vez e terminam rapidamente. Isso ajuda a evitar um backlog de transações empilhadas.

Capacidade de processamento de LRO

Consulte Capacidade de dados da LRO.

Opções de armazenamento de dados FHIR

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

Importar recursos de FHIR

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

• A importação FHIR não limita o tamanho total dos dados que ela importa. Se um pacote FHIR exceder 50 MB: é possível fazer upload dos recursos FHIR para o Cloud Storage e importá-los. Evite importações grandes ou de alta latência simultâneas, ou a taxa de transferência de dados pode ser limitada.

• A importação do FHIR é menos complexa do que o uso de pacotes FHIR. Por exemplo, não é preciso fazer o seguinte:

  • Partir pacotes grandes em pacotes menores
  • Gerenciar programações
  • Repetir erros temporários no nível do recurso ou do pacote

• A importação de FHIR não impõe a integridade referencial. Para mais informações, consulte Integridade referencial do FHIR.

• Não use a importação FHIR quando a atualização de dados for de alta prioridade. As importações podem ser rápidas, mas podem atrasar por horas ou dias.

• As importações de FHIR funcionam melhor quando há poucas LROs no projeto do Google Cloud.

• A importação FHIR pode alcançar um alto volume de dados se o aplicativo puder processar erros e falhas em massa em um subconjunto de recursos.

Usar pacotes FHIR

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

• É muito caro, em custos de faturamento ou largura de banda de rede, criar um pipeline para armazenar dados no Cloud Storage e importá-los.

• A integridade referencial precisa ser aplicada.

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

• É necessário enviar notificações do Pub/Sub quando os recursos FHIR são armazenados. A importação de FHIR não oferece suporte a notificações do Pub/Sub.

• A atualização de dados é uma prioridade, e os dados precisam ser ingeridos em segundos ou minutos. No entanto, mesmo em um sistema bem projetado, o throughput de dados pode ser limitado por:

  • Atrasos upstream nos pipelines de processamento. Os pipelines podem precisar de mais tempo para preparar os dados antes que eles possam ser ingeridos.
  • Backoffs, novas tentativas e camadas de proxy de modelagem de tráfego.

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

• A cota e o faturamento são aplicados 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 cota e o faturamento aplicados ao pacote serão os mesmos que se essas operações tivessem sido executadas de forma independente.

• Grandes pacotes de transação têm maior probabilidade de ter conflitos de transação que causar uma contenção de bloqueio. Para mais informações, consulte Evitar erros 429 Resource Exhausted operation_too_costly.

• Os pacotes em lote podem melhorar a taxa de transferência de dados, mas não têm recursos de consistência transacional, como integridade referencial.

• Pacotes em lote grandes podem ter a capacidade reduzida. Para saber mais, consulte Evite pacotes grandes.

Opções de armazenamento de dados DICOM

Use os métodos a seguir para alcançar uma alta capacidade de processamento de dados ao enviar dados de um sistema de arquivamento e comunicação de imagens (PACS, na sigla em inglês) para o API Cloud Healthcare:

O adaptador DICOM da API Cloud Healthcare de código aberto usando o protocolo de elemento de serviço de mensagem DICOM (DIMSE)

O adaptador otimiza a capacidade de dados quando você sincroniza um PACS a API Cloud Healthcare. Antes da sincronização, execute testes de desempenho e verifique se o adaptador pode manter a capacidade máxima de dados.

Use esse adaptador se não for possível fazer upload de arquivos DICOM para o Cloud Storage usando o Serviço de transferência do Storage ou outra opção de transferência. Por exemplo, talvez você não consiga atender a essas Requisitos do Serviço de transferência do Cloud Storage:

• Ativação de um sistema de arquivos em cada máquina que hospeda agentes no pool de agentes para extrair dados de origem.
• Se você transferir dados em um intervalo regular em vez de um carregamento de lote único, será necessário medir as mudanças no tamanho dos dados ao longo do tempo para determinar o que mudou.
• Como maximizar a performance da transferência de agentes.
• Pagar e alocar armazenamento no Cloud Storage.
• Validar transferências de dados para o Cloud Storage.
• Remova os recursos do Cloud Storage depois de importar dados para a API Cloud Healthcare e corrija os erros de importação.
• Programação de intervalos de ingestão de lote com base na rede e na capacidade de armazenamento de um sistema clínico.

Recomendamos o uso do Storage Transfer Service para uma única carga em lote para preencher uma loja DICOM. Como usar o Serviço de transferência do Cloud Storage com frequência exige mais trabalho, como um pipeline de importação síncrono. Para mais informações, consulte Detalhes da transferência do sistema de arquivos do Serviço de transferência do Cloud Storage.

dicomStores.import

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

Transação de armazenamento do DICOMweb

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

Gerenciar a cota para otimizar a capacidade de dados

As seções a seguir descrevem como gerenciar e planejar a cota para otimizar a taxa de transferência de dados. Para conferir práticas recomendadas gerais sobre o gerenciamento de cotas, consulte Práticas recomendadas de gerenciamento de cotas.

Planejar a cota para tráfego previsível

Planeje seus requisitos de cota analisando primeiro as necessidades típicas o tráfego diário. Mesmo que o tráfego seja previsível, planeje uma cota maior do que a necessária, em média. Isso ajuda a evitar erros e oferece uma margem de segurança contra picos de tráfego ou aumentos ocasionais no uso diário.

O diagrama a seguir mostra solicitações para a API Cloud Healthcare que são consistentes em tamanho e enviadas em padrões previsíveis:

Planejar a cota para solicitações de grande volume

Evite programar jobs em lote grandes durante os horários de pico. Para mais informações, consulte Favorecer transações de baixo volume com frequência.

O diagrama a seguir mostra um padrão de tráfego previsível. No entanto, uma solicitação de lote de grande volume durante um período de pico de tráfego excede a cota disponível. Isso pode causar erros 429 Resource Exhausted para todas as solicitações em seu projeto.

Se o sistema tiver uma cota de flexibilidade adicional, pequenos picos de tráfego não causar erros ou gerar picos de cargas previsíveis encontrar erros. Os pequenos picos devem ser distribuídos entre vários repositórios de dados, aplicativos e outros clientes e produzindo carga no projeto do Google Cloud.

Para evitar que um único job em lote grande cause picos de tráfego, consulte Evitar pacotes grandes.

Solicitar cota adicional

Para manter uma alta taxa de transferência de dados e evitar erros 429 Resource Exhausted, consulte as práticas recomendadas nesta página, especialmente Gerenciar cota para otimizar a taxa de transferência de dados. Essas práticas recomendadas garantem que o aplicativo cliente seja robusto e possa ser escalonado com mudanças no volume de solicitações. É improvável que você solicite mais cota sem implementar as práticas recomendadas. para evitar erros a longo prazo.

Se você implementar as práticas recomendadas e ainda precisar de mais cota, consulte Práticas recomendadas para solicitar cota adicional.

Recursos de taxa de transferência de ingestão de dados

Para mais informações sobre a taxa de transferência de transferência de dados, consulte Gerenciar o tráfego e a carga das suas cargas de trabalho no Google Cloud.