Práticas recomendadas para latência de solicitação e tratamento de erros

Esta página descreve as práticas recomendadas para otimizar a latência das solicitações e como lidar com erros na API Cloud Healthcare. Implemente essas práticas ao planejar e projetar a arquitetura do sistema.

O Google oferece 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 tempo suficiente para fazer o seguinte:

• 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 vai responder com um código de status 400 Bad Request. A solicitação não ter sucesso até corrigir os dados.

Para lidar com essas situações, você precisa planejar os estados de erro finais.

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

Solucionar erros em várias camadas

Quando o middleware interage com a API Cloud Healthcare, implemente a lógica de nova tentativa e os tempos limite no cliente e no middleware. Se um cliente encontra erros além do limite de tentativas, será preciso identificar se o erro ocorreu no cliente, no middleware ou no serviço subjacente da API Cloud Healthcare. Isso é especialmente importante quando o planejamento dos estados de erro finais.

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 tenta executar a solicitação mais cinco vezes, alcançando e para de tentar de novo.
3. O cliente recebe um erro 500 Internal Server Error final.

É importante entender que o erro originou-se na API Cloud Healthcare, não no middleware. Para simplificar a depuração, forneça essa informação no erro retornado ao para o cliente.

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

Figura 1. As camadas em que você precisa implementar a lógica de nova tentativa e os tempos limite são o cliente e o 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. O A API Cloud Healthcare retorna um erro 500 Internal Server Error ao proxy. O proxy tenta executar a solicitação mais cinco vezes até que o limite de novas tentativas foi atingido.

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

   Usando as recomendações mostradas anteriormente, é possível depure o estado de erro final fazendo o proxy retornar o seguinte 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 após os limites de nova tentativa e não pode tentar novamente. Nesse caso, um humano pode precisar intervir para diagnosticar se o erro veio do proxy ou do API Cloud Healthcare.

Escolher quais erros tentar novamente

Dependendo da arquitetura do sistema, é possível tentar novamente determinados erros e ignorar outros. Confira a seguir uma lista com alguns exemplos da API Cloud Healthcare que aceitam novas tentativas códigos de erro:

• 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 na mesma frequência e alguns podem nunca ocorrer.

Efeitos da arquitetura do sistema

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

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

Suponha que um sistema tenha uma camada de middleware entre o cliente e a API Cloud Healthcare. Se o cliente tiver feito a autenticação corretamente e um token de autenticação expirado tiver causado o problema, o middleware precisará atualizar o token e tentar a solicitação novamente.

Depois de analisar os estados finais de erro, você pode ajustar os erros que o cliente tenta novamente com base nas suas descobertas.

Planejar os estados de erro finais

Mesmo após implementar a lógica de repetição e tempos limite, um cliente ou middleware pode receber erros até que as tentativas se esgotem. O último erro retornado antes que as novas tentativas e os timeouts sejam esgotados é o estado de erro final. Você pode encontrar um estado de erro final para erros de consistência de dados.

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

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

• Se há dependências de processamento que precisam ser interrompidas se uma transação ou um pacote do FHIR não puder ser concluído.
• Se muitas instâncias de máquina virtual (VM) começarem a falhar permanentemente, um cliente precisará informar as solicitações que falharam. Depois que o problema for corrigido, o cliente precisará tentar as solicitações novamente.
• Monitoramento, sistemas de alerta e objetivos de nível de serviço (SLOs) para garantir a estabilidade do seu 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 ainda pode variar pelos seguintes motivos:

• Pequenas diferenças entre as solicitações, mesmo que pareçam insignificantes, podem aumentar o tempo de processamento.
• Solicitações semelhantes podem ter latências diferentes. Por exemplo, duas solicitações semelhantes que adicionam um registro ao armazenamento de dados podem têm latências diferentes se um deles ultrapassar um limite que desencadeie uma tarefa extra, como alocar mais armazenamento.
• A API Cloud Healthcare lida com muitas solicitações simultaneamente. A hora em que um cliente envia uma solicitação, medida em frações de segundo, pode coincidir com um momento em que a API Cloud Healthcare está sob carga mais pesada 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 em fila antes de processar outras solicitações.
• Às vezes, a API Cloud Healthcare tenta novamente erros no lado do servidor, o que pode aumentar latência de rede 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 encaminhadas vários data centers, seja na solicitação original ou em uma nova tentativa, pode haver aumento da latência.

Planejar usando a latência de percentil

Para se preparar para a latência aumentada, analise a latência de percentil das suas solicitações. Os exemplos a seguir descrevem a latência do 50º percentil e a latência do 99º percentil:

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

Se você analisar o percentil de latência em um intervalo quando a API Cloud Healthcare só processar algumas solicitações, a latência do percentil pode não ser útil ou indicativo do desempenho geral, porque as solicitações atípicas 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 durante os 100 minutos ser baseada na solicitação mais lenta. Uma medição de latência usando um único solicitação não é suficiente para compreender se há resultados problemas.

Coletar uma amostra maior de solicitação para um período mais longo, como 24 horas, pode fornecer mais informações comportamento do seu sistema. Você pode usar esses exemplos para determinar como seu sistema responde a tráfego intenso.