Latencia de las solicitudes y prácticas recomendadas para el manejo de errores

En esta página, se describen las prácticas recomendadas para optimizar la latencia de las solicitudes y manejar 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 manejar los errores. Para obtener más información, consulta el Acuerdo de Nivel de Servicio (ANS) de Cloud Healthcare.

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

Para manejar las demoras y los errores causados por solicitudes fallidas, implementa una lógica de reintento y tiempos de espera adecuados. Cuando configures la duración del tiempo de espera, permite el 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 después de 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 tendrá éxito hasta que corrijas los datos.

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

Para obtener más información sobre la lógica de reintento y los tiempos de espera, consulta Reintenta las solicitudes fallidas.

Soluciona 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 que superan su límite de reintentos, debes poder identificar si el error ocurrió en el cliente, el middleware o el servicio subyacente de la API de Cloud Healthcare. Esto es muy importante cuando se planifica para 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, hasta alcanzar su límite, y luego deja de reintentarlo.
  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 y 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 manejar los errores en la pila del cliente, middleware o 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. La API de Cloud Healthcare le muestra un error 500 Internal Server Error al proxy. El proxy vuelve a intentar la solicitud cinco veces más hasta que se alcanza su 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 final del error 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 cualquier información sobre el error que muestra la API de Cloud Healthcare.

A veces, el cliente o proxy recibe errores 500 Internal Server Error que superan sus límites de reintentos y no puede volver a intentarlo. En este caso, es posible que una persona necesite intervenir para diagnosticar si el error provino del proxy o de la API de Cloud Healthcare.

Elige los errores que quieres volver a intentar

Según la arquitectura del sistema, puedes reintentar ciertos errores y, luego, ignorar otros. La siguiente es una lista no exhaustiva de códigos de error de la API de Cloud Healthcare que se pueden reintentar:

  • 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 algunos pueden no ocurrir nunca.

Efectos de la arquitectura del sistema

La arquitectura de tu sistema influye en cómo y cuándo reintentar 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 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 reintentar la solicitud.

Después de analizar los estados de error finales, puedes ajustar los errores que el cliente vuelve a intentar según tus hallazgos.

Planifica los estados de error finales

Incluso después de implementar la lógica de reintento y los tiempos de espera, un cliente o middleware pueden recibir errores hasta que se agoten sus 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 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 manejar los estados de error finales:

  • Indica si hay dependencias de procesamiento que deben detenerse si una transacción o un paquete de FHIR 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.
  • 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 Cómo realizar pruebas y supervisar para obtener más información.

Cómo planificar para aumentar la latencia

La API de Cloud Healthcare es un servicio escalable y eficaz, pero la latencia de las solicitudes aún puede variar por los siguientes motivos:

  • Las pequeñas diferencias entre las solicitudes, incluso si parecen insignificantes, pueden causar 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 el umbral que activa una tarea adicional, como asignar más almacenamiento.
  • La API de Cloud Healthcare controla muchas solicitudes al mismo tiempo. El tiempo en el que un cliente envía una solicitud, medida 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, maneja muchas solicitudes, debe completar las tareas en cola antes de controlar otras solicitudes.
  • A veces, la API de Cloud Healthcare reintenta los 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 un reintento, puede haber una mayor latencia.

Planifica con latencia de percentil

Puedes planificar el aumento de la latencia; para ello, analiza la latencia del percentil de tus solicitudes. En los siguientes ejemplos, se describen 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 “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ó unas pocas solicitudes, es posible que la latencia del percentil no sea útil o no sea indicativa del rendimiento general, ya que las solicitudes con 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 de 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 solicitud más grande durante un período más largo, como 24 horas, puede proporcionar más información sobre el comportamiento general de tu sistema. Puedes usar estas muestras para determinar cómo responde el sistema al tráfico pesado.