Práticas recomendadas para a capacidade de processamento 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.

Capacidade de processamento 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 da capacidade de processamento de dados

A lista a seguir descreve os motivos pelos quais a capacidade de processamento de dados pode ser restrita:

• 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 Evite pequenas solicitações de importação e exportação.
• 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 com eficiência as solicitações com falha.

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

Espera exponencial com a introdução da instabilidade uma estratégia padrão de tratamento de erros para aplicativos de rede. Um cliente repete a tentativa periodicamente solicitações com falha com atrasos exponencialmente crescentes entre novas tentativas e um atraso pequeno e 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 da espera exponencial e estratégias semelhantes de nova tentativa. Para novas tentativas de longo prazo ou de vários processos, implemente uma configuração persistente fila de novas tentativas. Essa fila pode redefinir o mecanismo de nova tentativa se você exceder o o tempo 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 de novo se ocorrer um erro quando a LRO for iniciada ou se a LRO falhar.

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

  • Use um pacote separado para armazenar dados com falha em uma operação de importação ou criaçã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 este padrão, esperando 2ⁿ + random-fraction segundos após cada Tente de novo, até maximum-backoff vez.

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 começando em 0 e incrementado em 1 para cada nova tentativa.

• Substitua random-fraction por um valor fracionário aleatório menor ou igual a 1. Usar 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, de espera. entre 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. Impeça que o cliente tente de novo indefinidamente.

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

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

Se você tiver requisitos adicionais, como entrega garantida em todas as 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 distribui picos de carga entre horas ou minutos, o que melhora a capacidade de processamento. 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 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 fazer 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.
• LROs reduzidos durante o horário de pico. Para mais informações, consulte Planejar e usar a cota com eficiência. e Colocar na fila e gerenciar LROs.

Nos casos a seguir, a modelagem de tráfego pode ser necessária apenas para um único fase 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 atuais para implementar modelagem. Considere os seguintes projetos de código aberto e modelos soluções:

• Limitação do lado do cliente no Apache Beam. Consulte Escalonamento automático horizontal para saber como controlar o estrangulamento usando as flags numWorkers e maxNumWorkers.

• A classe RateLimiter (link em inglês) do Java. do conjunto de bibliotecas Java do Google Guava.

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

Para 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 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 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 fornece um mecanismo de feedback simples se uma unidade de trabalho depender da conclusão de uma unidade anterior. Uma camada de proxy atrasa solicitações de saída com base em limites de capacidade de QPS ou bytes, e o cliente bloqueia e aguarda o proxy a resposta da camada.

A camada de proxy pode ajustar a limitação de taxa o número de instâncias ou pode se coordenar controlador que ajusta a limitação de taxa em intervalos de alguns 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.

O processamento síncrono às vezes 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 o cliente e a camada de proxy se desconectarem, será necessário mais trabalho para garantir os dados foram modificados conforme solicitado.

Usar o Cloud Tasks

Use o Cloud Tasks para descarregar 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
• Limites de novas tentativas usando o objeto RetryConfig

Consulte Criar filas para criar no Cloud Tasks. O 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 as bibliotecas de cliente do Cloud Tasks para bibliotecas específicas de linguagem.

Ao usar o Cloud Tasks, considere o seguinte:

• O Cloud Tasks não garante uma entrega exatamente uma vez. Em exatamente uma vez entrega, quaisquer solicitações que contenham dados duplicados serão reconhecidas como duplicadas e ignorada pelo servidor. Para mais informações, consulte Além da arquitetura Lambda: processamento único no Dataflow, parte 1 (em inglês).
• O tamanho máximo da tarefa pode ser muito menor 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 em lote e de transação para o Cloud Tasks. que envia as solicitações no pacote para a API Cloud Healthcare. Se o o limitador de taxa está cheio ou acima da cota porque atingiu o tamanho máximo da fila e ficar sem espaço em disco, o cliente pode implementar a espera exponencial para enfileirar os pacotes.

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 frequência ficar cheia, o 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 sinal de atividade 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 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

Uma estrutura de teste garante que seu código funcione e ajuda você a fazer o seguinte:

• Prepare-se para picos repentinos de tráfego 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.
• Testar estratégias de enfileiramento síncrona e assíncrona para regular o fluxo de tráfego ou para testar se a camada de proxy lida com ataques.
• Planejar a recuperação de desastres. Normalmente, isso exige a redefinição de mensagens tráfego ou usar filas para retomar no tráfego após o término 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.
• Criar 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 alertas notificam você sobre problemas como se o sistema está sob estresse ou requer intervenção humana.
• Crie playbooks operacionais para que os administradores do sistema sabem 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 429 Resource Exhausted operation_too_costly erros

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 FHIR que atualiza um recurso de paciente e outros recursos FHIR bloqueia o recurso Patient 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. Erro as respostas 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 detecta um backlog de transações e descartes de carga ao retornar operation_too_costly erros. 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 de 429 Too Many Requests

Para resolver problemas de 429 Too Many Requests, pesquise no Cloud Logging. Os 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 altos níveis 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 transações grandes. pacotes. Pacotes de qualquer tamanho podem criar gargalos de capacidade de processamento. Testar diferentes pacotes para encontrar o tamanho ideal.

Pacotes grandes com novas tentativas podem ter retornos de desempenho decrescentes e são ficam mais suscetíveis a várias falhas. Os clientes devem implementar lógica adicional 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ção menores compatíveis com a 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 lotes em pacotes e evite solicitações individuais. Lotes pode melhorar o desempenho, mas lotes grandes podem causar erros e prejudicar a capacidade de processamento de dados. Pacotes em lote de tamanho semelhante têm menos contenção porque não têm bloqueios em 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 de FHIR for pequeno a moderado, use fhir.create para armazenar dados. Para armazenar grandes volumes de recursos FHIR, use fhir.executeBundle ou fhirStores.import. Para informações sobre cada método, consulte Opções de importação de FHIR.

Importar recursos de FHIR

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

• A importação de FHIR não limita o tamanho total dos dados importação. Se um pacote FHIR exceder 50 MB, faça upload dos recursos FHIR para o Cloud Storage e importe-os. Evitar simultaneidade importações grandes ou de alta latência ou a capacidade de processamento de dados pode ser limitada.

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

  • Particionar pacotes grandes em outros 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 de FHIR.

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

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

• A importação de FHIR poderá alcançar uma alta capacidade de dados se o aplicativo conseguir lidar erros e falhas em massa em um subconjunto de recursos.

Usar pacotes FHIR

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

• É muito caro em termos de faturamento ou largura de banda da 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 FHIR não oferece suporte 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, a capacidade de processamento de dados pode ser limitada pelos seguintes fatores:

  • Atrasos upstream no processamento de pipelines. 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 foi 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.

• Pacotes em lote podem melhorar a capacidade de processamento de dados, mas não precisam capacidades de consistência, como integridade referencial.

• Pacotes em lote grandes podem ter a capacidade reduzida. Para mais informações, consulte Evitar 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 de elemento de serviço de mensagem 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, faça testes de desempenho e verifique se o adaptador pode sustentar a capacidade de pico da capacidade de dados.

Use esse adaptador se não for possível fazer upload de arquivos DICOM para o Cloud Storage usando Serviço de transferência do Cloud Storage ou outro 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:

• montar um sistema de arquivos em cada máquina que hospeda agentes no seu pool de agentes; para recuperar dados de origem.
• Se você transferir dados em um intervalo regular em vez de um carregamento único em lote, será preciso medir mudanças no tamanho dos dados ao longo do tempo para determinar o que mudou.
• Como maximizar o desempenho da transferência do agente.
• Pagar e alocar armazenamento no Cloud Storage.
• Validar transferências de dados para o Cloud Storage.
• Remover os recursos do Cloud Storage depois de importar dados para a API Cloud Healthcare e corrigir 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 que você use o Serviço de transferência do Cloud Storage para o preenchimento de apenas um carregamento em lote um armazenamento 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 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 este 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 uma cota para otimizar os dados e aumentar a capacidade de processamento. Para práticas recomendadas gerais sobre 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 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 as solicitações para a API Cloud Healthcare que são consistentes em tamanho e enviados em padrões previsíveis:

Figura 1. A carga agregada da API por hora em todos os conjuntos de dados e repositórios 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 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.

Figura 2. Uma distribuição irregular do uso de recursos causados por um grande job em lote 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 ou fazer com que cargas de pico previsíveis encontrem 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 a alta capacidade de processamento de dados e evitar erros 429 Resource Exhausted, consulte as práticas recomendadas nesta página, em especial Gerenciar cota para otimizar a capacidade de processamento de dados. Estas práticas recomendadas garantem que seu aplicativo cliente seja robusto e possa ser escalonado com alterações 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 capacidade de ingestão de dados

Para mais informações sobre a capacidade de processamento da ingestão de dados, consulte Gerencie o tráfego e a carga das suas cargas de trabalho no Google Cloud.