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 de dados ao ingerir dados na API Cloud Healthcare. Essas recomendações são para profissionais técnicos com experiência no gerenciamento da capacidade de processamento de dados para sistemas de grande escala.

Capacidade de processamento de dados

Capacidade de dados é a quantidade de recursos, como recursos FHIR ou instâncias DICOM, ou bytes que a API Cloud Healthcare ingere a cada segundo.

Restrições da capacidade de processamento de dados

A lista a seguir descreve os motivos da restrição na capacidade de processamento de dados:

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

Tentar novamente solicitações com falha

Se um cliente repetir as solicitações de maneira rápida e repetida após falhas, ele poderá exceder as cotas da API Cloud Healthcare. As seções a seguir descrevem como executar novamente as solicitações com falha de modo eficiente.

Use a espera exponencial com instabilidade e filas de novas tentativas persistentes

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

Garanta que sua implementação de espera exponencial seja idempotente a cada nova tentativa, especialmente se você estiver usando 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 repetição semelhantes. Para novas tentativas de longo prazo ou de vários processos, implemente uma fila de nova tentativa persistente. Essa fila poderá redefinir o mecanismo de repetição se você exceder o tempo máximo de espera.

Use a espera exponencial ao tentar novamente estas solicitações:

Operações que modificam um recurso FHIR ou um pacote de recursos FHIR.
Solicitações síncronas de LRO. Tente novamente se houver um erro quando a LRO for iniciada ou se ela falhar.

As LROs têm erros exclusivos que podem exigir que você implemente as seguintes estratégias de nova tentativa:
- Use um pacote separado para armazenar os dados que falharam em uma operação de importação ou criaçã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:

Enviar uma solicitação para a API Cloud Healthcare.
Se a solicitação falhar, aguarde 1 + random-fraction segundos e repita a solicitação.
Se a solicitação falhar, aguarde 2 + random-fraction segundos e repita a solicitação.
Se a solicitação falhar, aguarde 4 + random-fraction segundos e repita a solicitação.
Continue esse padrão, aguardando 2ⁿ + random-fraction segundos após cada nova tentativa, até uma vez maximum-backoff.
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 é min((2ⁿ + random-fraction), maximum-backoff), com n começando em 0 e incrementado em 1 a 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 impede que os clientes sejam sincronizados e enviem várias tentativas ao mesmo tempo.
Substitua maximum-backoff pelo tempo máximo, em segundos, para aguardar entre novas tentativas. Os valores típicos são 32 ou 64 (2⁵ ou 2⁶) segundos. Escolha o valor que funciona melhor 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 da espera. Por exemplo, se o tempo de maximum-backoff for de 64 segundos, tente novamente a cada 64 segundos. Verifique se o cliente não tenta novamente indefinidamente.

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

A limitação de taxa protege sistemas de 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 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 entre 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 picos de carga por 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 usar apenas novas tentativas, porque evita pushback 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, na sigla em inglês), incluindo fhir.executeBundle.

Requisitos de 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 para evitar falhas no disco.
Workers coordenados para pull da fila de processamento.
Detecção de uso geral para ajustar o número de workers e a velocidade de processamento deles com base nos limites da cota.
Recuperação de desastres da fila de processamento com suporte de armazenamento. Se ocorrer um desastre, o sistema precisará limpar ou recuperar a fila.
LROs reduzidas durante os horários 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 estágio do pipeline:

Limitar o número de workers extraindo de uma etapa anterior do pipeline.
Limitar cada worker individualmente.
Uso de um coordenador de pool de workers para ajustar a taxa de processamento de unidades de trabalho individuais, como consultas por segundo (QPS) ou bytes ingeridos por segundo.

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

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

Limitação do lado do cliente no Apache Beam Para informações sobre como controlar a limitação usando as sinalizações numWorkers e maxNumWorkers, consulte Escalonamento automático horizontal.
A classe RateLimiter (em inglês) do Java do conjunto de principais bibliotecas Java do Google Guava.
O módulo ratelimiter do Python.

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

Escolher entre processamento assíncrono e síncrono

Uma camada de proxy do lado do cliente que une as solicitações à API Cloud Healthcare, mostrada em Solucionar erros em várias camadas, também pode controlar a limitação 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íncrona

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 um framework LRO se os clientes puderem receber resultados de leitura.

Síncrona

O processamento síncrono oferece um mecanismo de feedback simples quando uma unidade de 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 QPS ou bytes, e o cliente bloqueia e aguarda a resposta da camada de proxy.

A camada de proxy pode ajustar a limitação de taxa com base no número de instâncias ou pode se coordenar com um processo 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.

Às vezes, o processamento síncrono 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, tempos limite e redução da capacidade de processamento de dados, dificultando o escalonamento.
Se a camada de cliente e de proxy forem desconectadas, será necessário mais trabalho para garantir que 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ção usando o objeto RateLimits
Limites de 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 de linguagem.

Ao usar o Cloud Tasks, considere o seguinte:

O Cloud Tasks não garante uma entrega única. No envio exato, todas as solicitações que contêm dados duplicados são reconhecidas como cópias 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 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 nova tentativa de pacotes FHIR com espera exponencial e limitadores de taxa ajuda a manter a alta capacidade de dados e 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 limitador de taxa estiver cheio ou acima da cota porque atingiu o tamanho máximo da fila e ficou sem espaço em disco, o cliente pode implementar a espera exponencial para enfileirar os pacotes.

Para evitar que a fila do limitador de taxa fique cheia, monitore 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, o sistema precisará alertar um usuário e impedir o cliente de enviar 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 de TCP, que pode causar sobrecarga e prejudicar o desempenho. Para melhorar o desempenho, use o sinal de atividade HTTP para manter a conexão TCP aberta para várias solicitações.

Para usar o sinal de atividade HTTP em 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 (em inglês) do Python usa o sinal de atividade HTTP por padrão. Se você estiver usando Node.js, defina keepAlive como true ao criar um objeto http.Agent e, em seguida, transmita o objeto em sua solicitação.

Usar um framework de testes

Um framework de testes garante o funcionamento do código e ajuda você a fazer o seguinte:

Prepare-se para picos repentinos de tráfego em um aplicativo ou pipeline.
Teste se a espera exponencial e a limitação de taxa do lado do cliente melhoram o desempenho. Os testes podem mostrar se essas implementações criam um backlog de tarefas que precisam ser processadas separadamente.
Separar e controlar o tráfego de alta prioridade. Por exemplo, se um usuário estiver aguardando uma resposta, a carga de trabalho nas tarefas de processamento em segundo plano poderá ser reduzida para garantir que a experiência do usuário não seja prejudicada.
Teste estratégias de enfileiramento síncrono e assíncrono para regular o fluxo de tráfego ou teste se a camada de proxy lida com pushback.
Planejar a recuperação de desastres. Isso normalmente requer a redefinição do tráfego de entrada ou o uso de filas para retomar o tráfego após o término do desastre.

Usar o Cloud Monitoring.

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

Integre 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 API Cloud Monitoring para rastrear as principais métricas, como novas tentativas, tamanhos e tempo de 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 a SLIs para recomendações.
Criar políticas de alertas usando a observabilidade do Google Cloud. As políticas de alertas notificam você sobre problemas, como quando o sistema está sob estresse ou precisa 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 manuais operacionais em um ambiente de preparação para responder aos seguintes cenários:
- Backlogs causados pela limitação de taxa
- Dificuldade causada por exceder os limites de cota
- 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, latência e impedir que as transações sejam concluídas. As transações que não podem ser concluídas podem criar um backlog 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" refere-se ao uso de recursos e à capacidade de processamento 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 contenção excessiva de bloqueio nos registros do banco de dados. Isso pode acontecer devido a muitas operações em um pacote FHIR ou a uma combinação de operações CRUD.

Pense no seguinte cenário:

Um pacote de transação FHIR que atualiza um recurso "Paciente" e outros recursos FHIR bloqueiam o recurso "Paciente" até que a transação seja concluída.
Vários pacotes FHIR tentam atualizar o recurso "Paciente" em paralelo, e ocorre 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 "Paciente" novamente com espera exponencial, mas períodos longos de contenção de bloqueio podem levar a tempos limite, capacidade reduzida e aumento do uso de recursos.
Em algum momento, o servidor FHIR da API Cloud Healthcare detecta um backlog de transações e redução de carga ao retornar 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 ao seu projeto.

Resolver problemas de `429 Too Many Requests` erros

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

Se ocorrer uma limitação, os pacotes de transações poderão falhar devido aos altos níveis 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 solucionar o erro, acesse o link Pacote transacional FHIR cancelado devido à carga pesada cumulativa no campo diagnostics.

Evitar pacotes grandes

O erro 429 Too Many Requests é mais provável com pacotes de transação grandes. Pacotes de qualquer tamanho podem criar gargalos de capacidade. Teste pacotes diferentes para encontrar o tamanho ideal.

Pacotes grandes com novas tentativas podem ter retornos de desempenho decrescentes 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 poderão encontrar erros 429 Too Many Requests e 413 Request Entity Too Large e gargalos de capacidade se forem grandes ou tiverem QPS alta.

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 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. O processamento em lotes pode melhorar o desempenho, mas lotes grandes podem causar erros e prejudicar a capacidade de processamento dos dados. Pacotes em 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ção pequenos evitam a contenção porque mantêm apenas alguns bloqueios por vez e são concluídos rapidamente. Isso ajuda a evitar um backlog de transações empilhadas.

Capacidade de processamento da LRO

Consulte Capacidade de dados da LRO.

Opções de armazenamento de dados FHIR

Se o volume de dados 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 se vai usar a importação FHIR:

A importação FHIR não limita o tamanho total dos dados importados. Se um pacote FHIR exceder 50 MB, faça o upload dos recursos FHIR para o Cloud Storage e importe-os. Evite importações grandes ou de alta latência simultâneas. Caso contrário, a capacidade de processamento de dados pode ser limitada.
A importação FHIR é menos complexa do que usar pacotes FHIR. Por exemplo, não é necessário fazer o seguinte:
- Particionar pacotes grandes em menores
- Gerenciar programações
- Repetir erros temporários no nível do recurso ou do pacote
A importação de FHIR não aplica a integridade referencial. Para mais informações, consulte Integridade referencial de FHIR.
Não use a importação de FHIR quando a atualização de dados for de alta prioridade. As importações podem ser rápidas, mas podem demorar horas ou dias.
As importações FHIR têm um desempenho melhor quando há poucas LROs no seu projeto do Google Cloud.
A importação FHIR poderá alcançar uma alta capacidade de dados se seu aplicativo puder lidar com 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 criar um pipeline para armazenar dados no Cloud Storage e importá-los em custos de faturamento ou largura de banda de rede.
A integridade referencial precisa ser aplicada.
A validação do perfil FHIR precisa ser aplicada.
É preciso enviar notificações do Pub/Sub quando os recursos FHIR são armazenados. A importação FHIR não é compatível com 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-arquitetado, a capacidade de processamento de dados pode ser limitada pelo seguinte:
- Atrasos upstream no processamento de pipelines. Os pipelines podem precisar de mais tempo para preparar dados antes que possam ser ingeridos.
- Esperas, 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 maneira independente. Por exemplo, se um pacote tiver 10 operações POST, 5 operações GET e uma operação DELETE, a cota e o faturamento aplicados a ele serão iguais, como se essas operações fossem executadas de forma independente.
Pacotes de transação grandes têm mais chances de apresentar conflitos de transação que levem à contenção de bloqueio. Para mais informações, consulte Evitar erros 429 Resource Exhausted operation_too_costly.
Pacotes em lote podem melhorar a capacidade de dados, mas não têm recursos de consistência transacional, como integridade referencial.
Pacotes em lote grandes podem ter capacidade reduzida. Para mais informações, consulte Evitar pacotes grandes.

Opções de armazenamento de dados DICOM

Use os métodos a seguir para ter uma alta capacidade de processamento de dados ao enviar dados de um sistema de arquivamento de imagens e comunicação (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 capacidade de dados quando você sincroniza um PACS com a API Cloud Healthcare. Antes de sincronizar, execute testes de desempenho e verifique se o adaptador consegue manter a capacidade de processamento de dados máxima.

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 Cloud Storage ou outra opção de transferência. Por exemplo, talvez não seja possível atender a estes requisitos do Serviço de transferência do Cloud Storage:

ativar um sistema de arquivos em cada máquina que hospeda agentes no pool de agentes, para recuperar dados de origem;
Se você transferir dados em um intervalo regular em vez de um carregamento único em lote, vai precisar medir as 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 do Cloud Storage.
Validação de transferências de dados para o Cloud Storage.
Remover 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 em 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 um único carregamento em lote a fim de preencher um armazenamento DICOM. O uso regular do Serviço de transferência do Cloud Storage requer trabalho extra, como um pipeline de importação síncrona. 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 da loja da DICOMweb

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

Gerencie a cota para otimizar a capacidade de processamento de dados

Nas seções a seguir, descrevemos como gerenciar e planejar a cota para otimizar a capacidade de dados. Para ver as práticas recomendadas gerais de gerenciamento de cotas, consulte Práticas recomendadas de gerenciamento de cotas.

Planejar a cota para tráfego previsível

Planeje os requisitos de cota analisando primeiro o tráfego diário típico do aplicativo cliente. Mesmo que o tráfego seja previsível, planeje uma cota maior do que a média necessária. Isso ajuda a evitar erros e fornece 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 de cota entre as horas de pico e as típicas. — **Figura 1**. A carga agregada de API por hora 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 grandes jobs em lote durante os horários de pico. Para mais informações, consulte Favorecer transações de baixo volume de maneira consistente.

O diagrama a seguir mostra um padrão de tráfego previsível. No entanto, uma solicitação em lote com um 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 projeto.

Comparação do uso de cota entre horários de pico e horário típico com
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 extra, pequenos picos de tráfego não causarão erros ou causarão cargas de pico previsíveis para encontrar erros. Os pequenos picos precisam ser distribuídos entre muitos armazenamentos de dados, aplicativos e outros clientes que produzem 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 capacidade de processamento de dados e evitar erros 429 Resource Exhausted, consulte as práticas recomendadas nesta página, especialmente Gerenciar cotas para otimizar a capacidade de processamento de dados. Essas práticas recomendadas garantem que seu aplicativo cliente seja robusto e possa ser escalonado com as mudanças no volume de solicitações. Solicitar uma cota adicional sem implementar as práticas recomendadas provavelmente 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 capacidade de ingestão de dados

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