Prácticas recomendadas para la latencia de solicitudes y el manejo de errores

En esta página, se describen las prácticas recomendadas para optimizar la latencia de las solicitudes cómo manejar errores en la API de Cloud Healthcare. Implementación estas prácticas cuando planificas y diseñas la arquitectura de tu sistema.

Google proporciona un Acuerdo de Nivel de Servicio (ANS) que define el tiempo de actividad esperado del servicio de la API de Cloud Healthcare y cómo los clientes pueden controlar los errores. Para obtener más información, consulta Acuerdo de Nivel de Servicio (ANS) de Cloud Healthcare.

Implementa la lógica de reintentos y los tiempos de espera

Para manejar las demoras y los errores causados por las solicitudes fallidas, implementa la lógica de reintento y los tiempos de espera adecuados. Cuando establezcas la duración del tiempo de espera, permite tiempo suficiente para hacer lo siguiente:

  • Permite que la API de Cloud Healthcare procese la solicitud.
  • Determina si el error se originó en el servicio o en el cliente.

Puedes reintentar algunos errores, pero otros no se pueden reintentar y persisten en varios reintentos. Por ejemplo, si los datos de la solicitud tienen un formato incorrecto el servidor responde con un código de estado 400 Bad Request. La solicitud no tener éxito hasta que corrijas los datos.

Para manejar estas situaciones, debes planificar para los estados de error finales.

Para obtener más información sobre la lógica de reintento y los tiempos de espera, consulta Vuelve a intentar las solicitudes que fallaron.

Soluciona errores en varias capas

Cuando el middleware interactúa con la API de Cloud Healthcare, implementa la lógica de reintento y tiempos de espera en el cliente y el middleware. Si un cliente encuentra errores después de su límite de reintentos, debes poder identificar si el error se produjo en el cliente, el middleware o el servicio subyacente de la API de Cloud Healthcare. Esto es especialmente importante cuando y planificar los estados de error finales.

Considera la siguiente situación:

  1. El middleware recibe un error 500 Internal Server Error del API de Cloud Healthcare cuando se envía una solicitud.
  2. La capa de middleware vuelve a intentar la solicitud cinco veces más y alcanza su y, luego, deja de reintentarlo.
  3. El cliente recibe un error 500 Internal Server Error final.

Es importante entender que el error se originó en la API de Cloud Healthcare, no en el middleware. Para simplificar la depuración, proporciona esta información en el error que se muestra en cliente.

En el siguiente diagrama, se muestra una situación en la que un proxy de middleware recibe Errores 500 Internal Server Error cuando se reenvía una solicitud de un cliente a la API de Cloud Healthcare. Tanto el cliente como el proxy implementan el manejo de errores y los reintentos.

Diagrama de dónde manejar los errores en la pila del cliente, el middleware o el servidor
Figura 1: Las capas en las que necesitas implementar la lógica de reintento y los tiempos de espera son el Cliente y el Proxy.

En la Figura 1, se muestran los siguientes pasos:

  1. El cliente envía una solicitud válida a la API de Cloud Healthcare a través de un proxy de middleware.
  2. El proxy reenvía la solicitud a la API de Cloud Healthcare.
  3. El La API de Cloud Healthcare muestra un error 500 Internal Server Error al proxy. El proxy vuelve a intentar la solicitud cinco veces más hasta su se alcanza el límite de reintentos.

  4. El proxy muestra el estado de error final, 500 Internal Server Error, al cliente.

    Con las recomendaciones que mencionamos antes, puedes depurar el estado final de error haciendo que el proxy devuelva el siguiente error al cliente: 

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

    Agrega más información sobre el error que muestra la API de Cloud Healthcare.

A veces, el cliente o el proxy recibe errores 500 Internal Server Error superó el límite de reintentos y no puede volver a intentarlo. En este caso, una persona para diagnosticar si el error provino del proxy o del API de Cloud Healthcare.

Elige los errores que quieras reintentar

Según la arquitectura de tu sistema, puedes reintentar ciertos errores e ignorar los demás. La siguiente es una lista no exhaustiva de los códigos de error de la API de Cloud Healthcare que se pueden volver a intentar:

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

Por lo general, estos errores no ocurren con la misma frecuencia y es posible que algunos nunca ocurran.

Efectos de la arquitectura del sistema

La arquitectura de tu sistema influye en cómo y cuándo vuelves a intentar los errores.

Por ejemplo, en una arquitectura directo de cliente a servidor, un cliente que recibe un error 401 UNAUTHENTICATED del La API de Cloud Healthcare puede volver a autenticarse y reintentar su solicitud.

Supongamos que un sistema tiene una capa de middleware entre el cliente y la API de Cloud Healthcare. Si el cliente se autenticó correctamente y un token de autenticación vencido causó el problema, el middleware debe actualizar el token y volver a intentar la solicitud.

Después de analizar los estados de error finales, puedes ajustar los errores que tu cliente reintentos en función de tus hallazgos.

Planificar los estados de error finales

Incluso después de implementar la lógica de reintento y los tiempos de espera un cliente o middleware podrían recibir errores hasta que se agoten los reintentos. El último error devuelto antes de los reintentos se agotan los tiempos de espera es el estado de error final. Es posible que encuentres un último error en busca de errores de coherencia de datos.

A veces, un estado de error final requiere intervención humana. Intenta implementar un solución para resolver el estado de error final de una solicitud. De lo contrario, registra el estado final del error para que una persona pueda revisarlo.

Ten en cuenta lo siguiente cuando planifiques cómo manejar los estados de error finales:

  • Si hay dependencias de procesamiento que deben detenerse si una transacción de FHIR o el paquete no se puede completar correctamente.
  • Si muchas instancias de máquina virtual (VM) comienzan a fallar de forma permanente, un cliente debe informar las solicitudes que fallaron. Una vez que se soluciona el problema, el cliente debe reintentar las solicitudes.
  • Supervisión, sistemas de alertas y objetivos de nivel de servicio (SLO) son necesarias para garantizar la estabilidad de tu sistema. Consulta Probar y supervisar para obtener más información.

Planifica para lograr una mayor latencia

La API de Cloud Healthcare es un servicio escalable y de alto rendimiento, pero la latencia de las solicitudes puede variar por los siguientes motivos:

  • Las pequeñas diferencias entre las solicitudes, aunque parezcan insignificantes, pueden causar más tiempo de procesamiento.
  • Las solicitudes similares pueden tener latencias diferentes. Por ejemplo, dos solicitudes similares que agregan un registro al almacenamiento de datos podrían tienen latencias diferentes si se sobrepasa un umbral que activa tarea adicional, como asignar más almacenamiento.
  • La API de Cloud Healthcare controla muchas solicitudes de forma simultánea. El momento en que un cliente envía una solicitud, medida en fracciones de segundo, puede coincidir en un momento en que la API de Cloud Healthcare lleva más tiempo de lo normal.
  • Si un recurso físico de la API de Cloud Healthcare, como un disco, controla muchos solicitudes, debe completar sus tareas en cola antes de controlar otras solicitudes.
  • A veces, la API de Cloud Healthcare vuelve a intentar generar errores del servidor, lo que puede aumentar de red para los clientes.
  • Puede haber varias copias de datos en diferentes centros de datos dentro de regional o multirregional. Si tus solicitudes se enrutan a través de varios centros de datos, ya sea en la solicitud original o en un reintento, puede haber una mayor latencia.

Planifica con latencia percentil

Para planificar una mayor latencia, puedes analizar el percentil de latencia de tus solicitudes. En los siguientes ejemplos, se describe la latencia del percentil 50 y la latencia del percentil 99:

  • La latencia del percentil 50 es la latencia máxima, en segundos, para el 50% más rápido de las solicitudes. Por ejemplo, si la latencia del percentil 50 es de 0.5 segundos, entonces la API de Cloud Healthcare procesó el 50% de las solicitudes en 0.5 segundos. La latencia del percentil 50 también se denomina la “latencia mediana”.
  • La latencia del percentil 99 es la latencia máxima, en segundos, para el el 99% de las solicitudes. Por ejemplo, si la latencia del percentil 99 en 2 segundos, la API de Cloud Healthcare procesó el 99% de las solicitudes en dos segundos.

Si analizas la latencia del percentil durante un intervalo cuando solo la API de Cloud Healthcare varias solicitudes procesadas, es posible que la latencia percentil no sea útil o indicativa porque las solicitudes de valores atípicos pueden influir considerablemente.

Por ejemplo, supongamos que un proceso en la API de Cloud Healthcare procesa 100 solicitudes en 100 minutos. La latencia del percentil 99 durante los 100 minutos se basará en la solicitud más lenta. Una medición de latencia con un solo no es suficiente para comprender si hay errores problemas.

Recopilar una muestra de solicitudes más grande durante un período más largo, como 24 horas, puede proporcionar más información de tu sistema. Puedes usar estas muestras para determinar cómo tu sistema responde al tráfico intenso.