Solicitar latência e práticas recomendadas de tratamento de erros

Nesta página, descrevemos as práticas recomendadas para otimizar a latência da solicitação e processar erros na API Cloud Healthcare. Implemente essas práticas ao planejar e projetar a arquitetura do sistema.

O Google fornece um contrato de nível de serviço (SLA) que define o tempo de atividade esperado do serviço da API Cloud Healthcare e como os clientes podem lidar com erros. Para mais informações, consulte o Contrato de nível de serviço (SLA) do Cloud Healthcare.

Implementar a lógica de repetição e tempos limite

Para lidar com atrasos e erros causados por solicitações com falha, implemente a lógica de repetição e os tempos limite adequados. Ao definir a duração do tempo limite, permita um tempo suficiente para as seguintes ações:

• Deixe a API Cloud Healthcare processar a solicitação.
• Determine se o erro foi originado do serviço ou do cliente.

É possível repetir alguns erros, mas outros não podem ser repetidos e persistem em várias tentativas. Por exemplo, se os dados da solicitação estiverem formatados incorretamente, o servidor responderá com um código de status 400 Bad Request. A solicitação não será bem-sucedida até que você corrija os dados.

Para lidar com essas situações, é necessário planejar os estados finais de erro.

Para mais informações sobre a lógica de repetição e tempos limite, consulte Repetir solicitações com falha.

Solucionar erros em várias camadas

Quando o middleware interagir com a API Cloud Healthcare, implemente a lógica de repetição e os tempos limite no cliente e no middleware. Se um cliente encontrar erros após o limite de tentativas, será necessário identificar se o erro ocorreu no cliente, no middleware ou no serviço da API Cloud Healthcare subjacente. Isso é especialmente importante ao planejar os estados finais do erro.

Pense no seguinte cenário:

1. O middleware recebe um erro 500 Internal Server Error da API Cloud Healthcare ao enviar uma solicitação.
2. A camada de middleware repete a solicitação mais cinco vezes, atingindo o limite, e, em seguida, para de tentar.
3. O cliente recebe um erro 500 Internal Server Error final.

É importante entender que o erro foi originado na API Cloud Healthcare, não no middleware. Para simplificar a depuração, forneça essas informações no erro retornado ao cliente.

O diagrama a seguir mostra um cenário em que um proxy de middleware recebe erros 500 Internal Server Error ao encaminhar uma solicitação de um cliente para a API Cloud Healthcare. O cliente e o proxy implementam o tratamento de erros e novas tentativas.

Figura 1. As camadas em que você precisa implementar a lógica de repetição e tempos limite são Client e Proxy.

A Figura 1 mostra as seguintes etapas:

1. O cliente envia uma solicitação válida para a API Cloud Healthcare por um proxy de middleware.
2. O proxy encaminha a solicitação para a API Cloud Healthcare.
3. A API Cloud Healthcare retorna um erro 500 Internal Server Error ao proxy. O proxy repete a solicitação mais cinco vezes até que o limite de tentativas seja atingido.

4. O proxy retorna o estado de erro final, 500 Internal Server Error, ao cliente.

   Usando as recomendações mostradas anteriormente, é possível depurar o estado do erro final fazendo com que o proxy retorne o seguinte erro para o cliente:

   Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

   Adicione mais informações sobre o erro retornado da API Cloud Healthcare.

Às vezes, o cliente ou proxy recebe erros 500 Internal Server Error que ultrapassam os limites de repetição e não pode tentar novamente. Nesse caso, uma pessoa pode precisar intervir para diagnosticar se o erro veio do proxy ou da API Cloud Healthcare.

Escolha os erros para tentar novamente

Dependendo da arquitetura do sistema, é possível repetir determinados erros e ignorar outros. Veja a seguir uma lista com alguns exemplos de códigos de erro da API Cloud Healthcare que podem ser repetidas:

• 408 Request Timeout
• 425 Too Early
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

Esses erros geralmente não ocorrem com a mesma frequência, e alguns podem nunca ocorrer.

Efeitos da arquitetura do sistema

A arquitetura do sistema influencia como e quando você tenta repetir erros.

Por exemplo, em uma arquitetura direta de cliente para servidor, um cliente que recebe um erro 401 UNAUTHENTICATED da API Cloud Healthcare pode reautenticar e repetir a solicitação.

Suponha que um sistema tenha uma camada de middleware entre o cliente e a API Cloud Healthcare. Se o cliente foi autenticado corretamente e um token de autenticação expirado causou o problema, o middleware precisará atualizar o token e repetir a solicitação.

Depois de analisar os estados finais de erro, é possível ajustar os erros que seu cliente repete com base em suas descobertas.

Planejar os estados finais de erro

Mesmo depois de implementar a lógica de repetição e os tempos limite, um cliente ou middleware pode receber erros até que as tentativas sejam esgotadas. O último erro retornado antes que novas tentativas e tempos limite se esgotem é o estado do erro final. É possível encontrar um estado final de erro para erros de consistência de dados.

Às vezes, um estado de erro final requer intervenção humana. Tente implementar uma solução para resolver o estado de erro final de uma solicitação. Caso contrário, registre o estado final do erro para que uma pessoa possa analisá-lo.

Considere o seguinte ao planejar como lidar com os estados finais de erro:

• Se há dependências de processamento que precisam ser interrompidas se uma transação FHIR ou um pacote não for concluído com êxito.
• Se muitas instâncias de máquina virtual (VM) começarem a falhar permanentemente, um cliente precisará relatar as solicitações que falharam. Depois que o problema for corrigido, o cliente precisará repetir as solicitações.
• O monitoramento, os sistemas de alertas e os objetivos de nível de serviço (SLOs) são necessários para garantir a estabilidade do sistema. Consulte Testar e monitorar para mais informações.

Planejar o aumento da latência

A API Cloud Healthcare é um serviço escalonável e de alto desempenho, mas a latência da solicitação ainda pode variar pelos seguintes motivos:

• Pequenas diferenças entre solicitações, mesmo que pareçam insignificantes, podem causar tempo de processamento extra.
• Solicitações semelhantes podem ter latências diferentes. Por exemplo, duas solicitações semelhantes que adicionam um registro ao armazenamento de dados poderão ter latências diferentes se uma delas ultrapassar um limite que aciona uma tarefa extra, como alocação de mais armazenamento.
• A API Cloud Healthcare lida com muitas solicitações simultaneamente. O tempo em que um cliente envia uma solicitação, medido em frações de segundo, pode coincidir com o momento em que a API Cloud Healthcare está sob carga mais pesada do que o normal.
• Se um recurso físico da API Cloud Healthcare, como um disco, estiver processando muitas solicitações, ele precisará concluir as tarefas na fila antes de processar outras solicitações.
• Às vezes, a API Cloud Healthcare tenta repetir erros no lado do servidor, o que pode aumentar a latência para os clientes.
• Pode haver várias cópias de dados em diferentes data centers em um local regional ou multirregional. Se as solicitações forem roteadas em vários data centers, seja na solicitação original ou em uma nova tentativa, talvez haja aumento na latência.

Planejar usando a latência do percentil

É possível planejar o aumento de latência analisando a latência no percentil das solicitações. Os exemplos a seguir descrevem a latência do 50o percentil e a latência do 99o percentil:

• A latência do 50o percentil é a latência máxima, em segundos, para os 50% mais rápidos das solicitações. Por exemplo, se a latência do 50o percentil for de 0,5 segundo, a API Cloud Healthcare processou 50% das solicitações em 0,5 segundo. A latência do 50o percentil também é chamada de "latência mediana".
• A latência do 99o percentil é a latência máxima, em segundos, das solicitações mais rápidas. Por exemplo, se a latência do 99o percentil for de dois segundos, a API Cloud Healthcare processou 99% das solicitações em dois segundos.

Se você analisar a latência do percentil em um intervalo em que a API Cloud Healthcare processou apenas algumas solicitações, a latência do percentil poderá não ser útil ou indicar o desempenho geral, porque as solicitações discrepantes podem ter uma grande influência.

Por exemplo, suponha que um processo na API Cloud Healthcare processe 100 solicitações em 100 minutos. A latência do 99o percentil dos 100 minutos seria baseada na única solicitação mais lenta. Uma medição de latência usando uma única solicitação não é suficiente para entender se há problemas de desempenho.

A coleta de uma amostra maior de solicitação durante um período mais longo, como 24 horas, pode fornecer mais informações sobre o comportamento geral do sistema. Use essas amostras para determinar como o sistema responde ao tráfego intenso.