Práticas recomendadas de latência de pedidos e processamento de erros

Esta página descreve as práticas recomendadas para otimizar a latência dos pedidos e processar erros na Cloud Healthcare API. Implemente estas práticas à medida que planeia e cria a arquitetura do seu sistema.

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

Implemente a lógica de repetição e os limites de tempo

Para processar atrasos e erros causados por pedidos falhados, implemente uma lógica de repetição e limites de tempo adequados. Ao definir a duração do limite de tempo, permita tempo suficiente para fazer o seguinte:

• Permitir que a Cloud Healthcare API processe o pedido.
• Determine se o erro teve origem no serviço ou no cliente.

Pode tentar novamente alguns erros, mas outros não são repetíveis e persistem em várias tentativas. Por exemplo, se os dados do pedido estiverem formatados incorretamente, o servidor responde com um código de estado 400 Bad Request. O pedido não vai ser bem-sucedido até corrigir os dados.

Para lidar com estas situações, tem de planear estados de erro finais.

Para mais informações sobre a lógica de repetição e os limites de tempo, consulte o artigo Repita pedidos falhados.

Trate erros em várias camadas

Quando o middleware interage com a Cloud Healthcare API, implemente a lógica de repetição e os limites de tempo no cliente e no middleware. Se um cliente encontrar erros após o limite de novas tentativas, tem de conseguir identificar se o erro ocorreu no cliente, no middleware ou no serviço da API Cloud Healthcare subjacente. Isto é especialmente importante quando planear estados de erro finais.

Considere o seguinte cenário:

1. O middleware recebe um erro 500 Internal Server Error da Cloud Healthcare API ao enviar um pedido.
2. A camada de middleware tenta novamente o pedido mais cinco vezes, atingindo o respetivo limite e, em seguida, para de tentar.
3. O cliente recebe um erro 500 Internal Server Error final.

É importante compreender que o erro teve origem na Cloud Healthcare API e não no middleware. Para simplificar a depuração, forneça estas informações no erro devolvido ao cliente.

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

Figura 1. As camadas onde tem de implementar a lógica de repetição e os limites de tempo são o cliente e o proxy.

A Figura 1 mostra os seguintes passos:

1. O cliente envia um pedido válido para a Cloud Healthcare API através de um proxy de middleware.
2. O proxy encaminha o pedido para a Cloud Healthcare API.
3. A API Cloud Healthcare devolve um erro 500 Internal Server Error ao proxy. O proxy tenta novamente o pedido mais cinco vezes até atingir o limite de novas tentativas.

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

   Usando as recomendações apresentadas anteriormente, pode depurar o estado de erro final fazendo com que o proxy devolva o seguinte erro ao cliente:

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

   Adicione mais informações sobre o erro devolvido pela Cloud Healthcare API.

Por vezes, o cliente ou o proxy recebe erros 500 Internal Server Error que excedem os respetivos limites de novas tentativas e não consegue tentar novamente. Neste caso, pode ser necessária a intervenção de um humano para diagnosticar se o erro foi originado no proxy ou na API Cloud Healthcare.

Escolha os erros que quer tentar corrigir novamente

Consoante a arquitetura do sistema, pode tentar novamente determinados erros e ignorar outros. Segue-se uma lista não exaustiva de códigos de erro da Cloud Healthcare API que podem ser repetidos:

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

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

Efeitos da arquitetura do sistema

A arquitetura do seu sistema influencia a forma e o momento em que tenta novamente os erros.

Por exemplo, numa arquitetura direta cliente-servidor, um cliente que recebe um erro 401 UNAUTHENTICATED da Cloud Healthcare API pode voltar a autenticar-se e tentar novamente o pedido.

Suponhamos que um sistema tem uma camada de middleware entre o cliente e a Cloud Healthcare API. Se o cliente tiver sido autenticado corretamente e um token de autenticação expirado tiver causado o problema, o middleware tem de atualizar o token e repetir o pedido.

Depois de analisar os estados de erro finais, pode ajustar as repetições do cliente com base nas suas conclusões.

Planeie os estados de erro finais

Mesmo após a implementação da lógica de repetição e dos limites de tempo, um cliente ou um middleware pode receber erros até que as respetivas repetições se esgotem. O último erro devolvido antes de as novas tentativas e os limites de tempo serem esgotados é o estado de erro final. Pode encontrar um estado de erro final para erros de consistência de dados.

Por vezes, um estado de erro final requer intervenção humana. Tente implementar uma solução para resolver o estado de erro final de um pedido. Caso contrário, registe o estado de erro final para que um humano o possa rever.

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

• Se existem dependências de processamento que têm de parar se não for possível concluir com êxito uma transação ou um pacote FHIR.
• Se muitas instâncias de máquinas virtuais (VM) começarem a falhar permanentemente, um cliente tem de comunicar os pedidos que falharam. Depois de o problema ser corrigido, o cliente tem de repetir os pedidos.
• Os sistemas de monitorização, alerta e objetivos ao nível do serviço (SLOs) são necessários para garantir a estabilidade do seu sistema. Consulte Teste e monitorize para mais informações.

Planeie um aumento da latência

A Cloud Healthcare API é um serviço escalável e de elevado desempenho, mas a latência dos pedidos pode variar pelos seguintes motivos:

• As pequenas diferenças entre os pedidos, mesmo que pareçam insignificantes, podem causar um tempo de processamento adicional.
• Pedidos semelhantes podem ter latências diferentes. Por exemplo, dois pedidos semelhantes que adicionam um registo ao armazenamento de dados podem ter latências diferentes se um ultrapassar um limite que aciona uma tarefa adicional, como a atribuição de mais armazenamento.
• A Cloud Healthcare API processa muitos pedidos em simultâneo. A hora em que um cliente envia um pedido, medida em frações de segundo, pode coincidir com uma hora em que a Cloud Healthcare API está sob uma carga mais pesada do que o habitual.
• Se um recurso físico da API Cloud Healthcare, como um disco, estiver a processar muitos pedidos, tem de concluir as tarefas em fila antes de processar outros pedidos.
• Por vezes, a Cloud Healthcare API tenta novamente erros do lado do servidor, o que pode aumentar a latência para os clientes.
• Pode haver várias cópias de dados em diferentes centros de dados numa localização regional ou multirregional. Se os seus pedidos forem encaminhados por vários centros de dados, seja no pedido original ou numa nova tentativa, pode haver um aumento da latência.

Planeie com a latência de percentil

Pode planear um aumento da latência analisando a latência percentil dos seus pedidos. Os exemplos seguintes descrevem a latência do percentil 50 e a latência do percentil 99:

• A latência do 50.º percentil é a latência máxima, em segundos, para os 50% mais rápidos dos pedidos. Por exemplo, se a latência do percentil 50 for de 0,5 segundos, a Cloud Healthcare API processou 50% dos pedidos em 0,5 segundos. A latência do 50.º percentil também é denominada "latência mediana".
• A latência do percentil 99 é a latência máxima, em segundos, para os 99% mais rápidos dos pedidos. Por exemplo, se a latência do percentil 99 for de dois segundos, a Cloud Healthcare API processou 99% dos pedidos em dois segundos.

Se analisar a latência percentil ao longo de um intervalo em que a Cloud Healthcare API apenas processou alguns pedidos, a latência percentil pode não ser útil nem indicativa do desempenho geral, porque os pedidos atípicos podem ter uma grande influência.

Por exemplo, suponhamos que um processo na Cloud Healthcare API processa 100 pedidos em 100 minutos. A latência do percentil 99 para os 100 minutos basear-se-ia no pedido único mais lento. Uma medição da latência com um único pedido não é suficiente para compreender se existem problemas de desempenho.

A recolha de uma amostra de pedidos maior durante um período mais longo, como 24 horas, pode fornecer mais estatísticas sobre o comportamento geral do seu sistema. Pode usar estes exemplos para determinar como o seu sistema responde ao tráfego elevado.