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

Esta página descreve as práticas recomendadas para otimizar o throughput de dados ao ingerir dados na API Cloud Healthcare. Essas recomendações são para profissionais técnicos com experiência em gerenciamento de taxa de transferência de dados para sistemas em 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 diminuem a ingestão de grandes volumes de dados enviados em um curto período.
  • Várias transações simultâneas mudam o mesmo recurso da API Cloud Healthcare, o 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 um cliente tentar novamente as solicitações rapidamente e repetidamente após falhas, ele poderá exceder as cotas da API Cloud Healthcare. As seções a seguir descrevem como repetir solicitações com falha de maneira eficiente.

Use a espera exponencial com instabilidade e filas de repetição 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 em cada nova tentativa, principalmente se você estiver usando uma lógica personalizada para ignorar 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 espera exponencial e estratégias de nova tentativa semelhantes. Para repetição 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 tentar essas 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.
    • Use solicitações síncronas para dados que não foram processados.

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 2n + 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 (25 ou 26) segundos. Escolha o valor ideal para seu caso de uso.

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

O cliente pode tentar novamente após atingir o tempo maximum-backoff usando o mesmo valor do backoff. Por exemplo, se o tempo maximum-backoff for de 64 segundos, tente 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 gerenciamento de cota.

Se você tiver outros requisitos, como entrega garantida em novas tentativas, as estratégias em Repetir solicitações com falha podem ser insuficientes. A 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 restrições de largura de banda. Isso espalha os picos de carga por horas ou minutos, o que melhora a capacidade. Quando a cota é limitada, a modelagem de tráfego pode alcançar um throughput maior do que usando apenas as novas tentativas, porque evita o pushback e rastreia as unidades de trabalho.

É 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 de ajuste da programação

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.
  • Use a detecção geral 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 fila de processamento com suporte de armazenamento. 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 forma eficiente e Enfileirar e gerenciar LROs.

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

  • Limitar o número de workers que extraem 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, na sigla em inglês) ou bytes ingeridos por segundo, são processadas.

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:

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 envolve solicitações para a API Cloud Healthcare, mostrada em Processar erros em várias camadas, também pode controlar o throttling em serviços que usam a API Cloud Healthcare. Dependendo do tipo de modelagem de tráfego necessário, use uma destas opções:

Assíncrono
Use o processamento assíncrono para enfileirar solicitações e controlar workers. Uma camada de proxy grava as solicitações de entrada na fila e retorna respostas 200 OK depois que cada solicitação é enfileirada. Isso funciona melhor para solicitações de gravação, mas pode ser usado para solicitações de leitura em um framework de LRO se os clientes puderem receber resultados de leitura.
Síncrona

O processamento síncrono fornece um mecanismo de feedback simples se uma unidade de trabalho depender da conclusão de uma unidade anterior. Uma camada de proxy atrasa as solicitações de saída com base em QPS ou limites de taxa de transferência de bytes, e o cliente bloqueia e aguarda a resposta da camada de proxy.

A camada de proxy pode ajustar o 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 rastreie o número de instâncias e os limites de taxa, cada instância de proxy pode ler regularmente um arquivo ou fazer uma chamada de procedimento remoto (RPC) com os limites de taxa codificados.

O processamento síncrono às vezes tem as seguintes desvantagens:

  • Os recursos nas camadas de cliente e proxy ficam indisponíveis enquanto o cliente bloqueia e aguarda uma resposta. Isso pode levar a erros, timeouts e redução da taxa de transferência de dados, 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 de burst e simultaneidade máxima de solicitações usando o objeto RateLimits
  • Tentar novamente os limites 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 conferir as bibliotecas específicas da linguagem.

Ao usar o Cloud Tasks, considere o seguinte:

Combinar pacotes FHIR com limitadores de taxa

A repetição de tentativas de pacotes FHIR com espera 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 solicitação CRUD. Isso requer um handshake TCP, que pode causar sobrecarga e prejudicar o desempenho. Para melhorar o desempenho, use o keep-alive 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.

A biblioteca requests do Python usa o keep-alive HTTP por padrão. Se você estiver usando o Node.js, defina keepAlive como true ao criar um objeto http.Agent e transmita 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.
  • Teste se o backoff exponencial e a limitação de taxa do lado do cliente melhoram a performance. Os testes podem mostrar se essas implementações criam um backlog de tarefas que precisam ser tratadas separadamente.
  • Separe e controle o tráfego de alta prioridade. Por exemplo, se um usuário estiver esperando por uma resposta, a carga de trabalho em tarefas de processamento em segundo plano poderá ser reduzida para garantir que a experiência do usuário não seja degradada.
  • Teste estratégias de fila síncrona e assíncrona para regular o fluxo de tráfego ou teste se a camada de proxy processa 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 os ambientes de teste e produção. Siga estas recomendações:

  • Integre o Cloud Tasks a outros serviços de monitoramento e geração de registros do Google Cloud, como os registros de auditoria do Cloud.
  • Crie métricas personalizadas com a API Cloud Monitoring para acompanhar as principais métricas, como reexecuções, tamanhos de fila e idade 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 alerta 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 teste para responder aos seguintes cenários:

    • Atrasos causados pela limitação de taxa
    • Pushback causado por limites de cota excedentes
    • Picos de tráfego de entrada

Evitar erros 429 Resource Exhausted operation_too_costly

Fazer milhares de atualizações paralelas por dia em um recurso FHIR pode causar contensão de bloqueio, latência e impedir que as 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, "custo" se refere ao uso de recursos e ao volume de dados, não aos custos de faturamento.

Um erro 429 Too Many Requests nem sempre indica um problema de cota. O erro pode ocorrer quando o servidor FHIR da API Cloud Healthcare detecta uma contenção de bloqueio excessiva nos registros do 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 tentam atualizar o recurso Paciente em paralelo, e ocorre uma disputa 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 tempo 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 outros erros.

    Os erros operation_too_costly limitam todas as operações CRUD do FHIR no seu projeto do Google Cloud, o que afeta todos os aplicativos conectados a ele.

Resolver erros 429 Too Many Requests

Para resolver problemas de erros 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.

Se a limitação ocorrer, os pacotes de transações poderão falhar devido a níveis altos de contenção de bloqueio 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 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 throughput. 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.

Os pacotes em lote podem encontrar erros 429 Too Many Requests e 413 Request Entity Too Large e gargalos de throughput se forem grandes ou tiverem 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 os recursos do 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 alguns 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 acúmulo de transações.

Capacidade de processamento de LRO

Consulte Taxa de transferência de dados de 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 se vai usar a importação FHIR:

  • A importação FHIR não limita o tamanho total dos dados que ela importa. Se um pacote FHIR exceder 50 MB, faça upload dos recursos FHIR para o Cloud Storage e importe-os. 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 FHIR não impõe integridade referencial. Para mais informações, consulte Integridade referencial do FHIR.

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

  • As importações de FHIR têm melhor desempenho quando há poucos LROs no seu projeto do Google Cloud.

  • A importação FHIR pode alcançar uma alta taxa de transferência 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 do 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 eles 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 da ingestão.
    • 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.

  • Os pacotes de transações grandes têm mais probabilidade de ter conflitos de transação que levam à contenção de bloqueio. Para mais informações, consulte Prevenir erros de 429 Resource Exhausted operation_too_costly.

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

  • Os pacotes de lote grandes podem ter uma capacidade reduzida. Para saber mais, consulte Evite pacotes grandes.

Opções de armazenamento de dados DICOM

É possível usar os seguintes métodos para alcançar um alto volume de dados ao enviar dados de um sistema de arquivamento e comunicação de imagens (PACS, na sigla em inglês) para a API Cloud Healthcare:

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

O adaptador otimiza a taxa de transferência de dados ao sincronizar um PACS com 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 estes 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 do agente.
  • Pagar e alocar armazenamento do 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 transferência em lote com base na capacidade de rede e armazenamento de um sistema clínico.

Recomendamos o uso do Serviço de transferência do Cloud Storage para uma única carga em lote para preencher uma loja DICOM. O uso regular do Serviço de transferência de armazenamento requer trabalho extra, 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 esse 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 as práticas recomendadas gerais de gerenciamento de cota, consulte Práticas recomendadas de gerenciamento de cota.

Planejar a cota para tráfego previsível

Planeje seus requisitos de cota analisando primeiro o tráfego diário normal do aplicativo cliente. 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:

Comparação do uso da cota entre horários de pico e normais.
Figura 1. A carga horária agregada da API em conjuntos de dados e armazenamentos de dados em um projeto do Google Cloud.

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 Dar preferência a transações de baixo volume de forma consistente.

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 no seu projeto.

Comparação do uso de cota entre horários de pico e normais com um pico mais alto.
Figura 2. Uma distribuição irregular do uso de recursos causada por um job em lote grande durante os horários de pico.

Se o sistema tiver uma cota de flexibilidade adicional, pequenos picos de tráfego não vão causar erros nem cargas de pico previsíveis. Os pequenos picos precisam ser distribuídos entre muitos armazenamentos de dados, aplicativos e outros clientes que geram 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. Solicitar cota extra sem implementar as práticas recomendadas não vai 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 ingestão de dados, consulte Gerenciar o tráfego e a carga das suas cargas de trabalho no Google Cloud.