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 y controlar los errores en la API de Cloud Healthcare. Implementa estas prácticas a medida que 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 el Acuerdo de Nivel de Servicio (ANS) de Cloud Healthcare.

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

Para controlar las demoras y los errores causados por solicitudes fallidas, implementa la lógica de reintento y los tiempos de espera adecuados. Cuando configures la duración del tiempo de espera, permite suficiente tiempo 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 volver a intentar 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 se realizará correctamente hasta que corrijas los datos.

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

Para obtener más información sobre la lógica de reintentos y los tiempos de espera, consulta Cómo reintentar solicitudes fallidas.

Controla errores en varias capas

Cuando el middleware interactúa con la API de Cloud Healthcare, implementa la lógica de reintento y los 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 muy importante cuando se planifican los estados de error finales.

Considera la siguiente situación:

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

Es importante comprender 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 al cliente.

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

Diagrama de dónde controlar los errores en la pila de cliente, middleware y servidor.
Figura 1: Las capas en las que debes 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. 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 que 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 se mostraron antes, puedes depurar el estado de error final haciendo que el proxy muestre 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 reciben errores 500 Internal Server Error después de los límites de reintentos y no pueden volver a intentarlo. En este caso, es posible que una persona necesite intervenir para diagnosticar si el error proviene del proxy o de la API de Cloud Healthcare.

Elige qué errores reintentar

Según la arquitectura del sistema, puedes volver a intentar ciertos errores y ignorar otros. 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 directa de cliente a servidor, un cliente que recibe un error 401 UNAUTHENTICATED de la API de Cloud Healthcare puede volver a autenticar y volver a intentar 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 vuelve a intentar en función de tus conclusiones.

Planifica los estados de error finales

Incluso después de implementar la lógica de reintento y los tiempos de espera, un cliente o un middleware pueden recibir errores hasta que se agoten los reintentos. El último error que se muestra antes de que se agoten los reintentos y los tiempos de espera es el estado de error final. Es posible que encuentres un estado de error final para los errores de coherencia de los datos.

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

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

  • Si hay dependencias de procesamiento que se deben detener si una transacción o un paquete de FHIR no se pueden 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 solucione el problema, el cliente debe volver a intentar las solicitudes.
  • La supervisión, los sistemas de alertas y los objetivos de nivel de servicio (SLO) son necesarios para garantizar la estabilidad de tu sistema. Consulta Prueba y supervisa para obtener más información.

Planifica para 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, incluso si parecen insignificantes, pueden causar un tiempo de procesamiento adicional.
  • Las solicitudes similares pueden tener latencias diferentes. Por ejemplo, dos solicitudes similares que agregan un registro al almacenamiento de datos pueden tener latencias diferentes si una supera un umbral que activa una tarea adicional, como asignar más almacenamiento.
  • La API de Cloud Healthcare controla muchas solicitudes de forma simultánea. El momento en el que un cliente envía una solicitud, medido en fracciones de segundo, puede coincidir con un momento en el que la API de Cloud Healthcare tiene una carga más pesada de lo habitual.
  • Si un recurso físico de la API de Cloud Healthcare, como un disco, controla muchas solicitudes, debe completar sus tareas en cola antes de controlar otras solicitudes.
  • A veces, la API de Cloud Healthcare vuelve a intentar errores del servidor, lo que puede aumentar la latencia para los clientes.
  • Puede haber varias copias de datos en diferentes centros de datos en una ubicación regional o multirregional. Si tus solicitudes se enrutan a través de varios centros de datos, ya sea en la solicitud original o en una nueva, es posible que aumente la latencia.

Planifica con la latencia del percentil

Para planificar un aumento de la latencia, analiza la latencia del percentil 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, 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 99% más rápido de las solicitudes. Por ejemplo, si la latencia del percentil 99 es de dos segundos, la API de Cloud Healthcare procesó el 99% de las solicitudes en dos segundos.

Si analizas la latencia del percentil durante un intervalo en el que la API de Cloud Healthcare solo procesó algunas solicitudes, es posible que la latencia del percentil no sea útil ni indicativa del rendimiento general, ya que las solicitudes de valores atípicos pueden tener una gran influencia.

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

Recopilar una muestra de solicitudes más grande durante un período más largo, como 24 horas, puede proporcionar más estadísticas sobre el comportamiento general de tu sistema. Puedes usar estas muestras para determinar cómo responde tu sistema a un tráfico intenso.