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 reintentos y los tiempos de espera adecuados. Cuando configures la duración del tiempo de espera, considera 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 volver a intentar algunas acciones en caso de error, pero otras no se pueden volver a intentar y persisten en varios reintentos. Por ejemplo, si los datos de la solicitud no tienen el formato correcto, el servidor responde con un código de estado 400 Bad Request. La solicitud no se completará 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 reintento y los tiempos de espera, consulta Reintenta solicitudes con errores.

Controla errores en varias capas

Cuando el software intermedio interactúa con la API de Cloud Healthcare, implementa la lógica de reintentos y los tiempos de espera en el cliente y el software intermedio. Si un cliente encuentra errores después de superar 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 se planifican los estados de error finales.

Considera la siguiente situación:

1. El software intermedio recibe un error 500 Internal Server Error de la API de Cloud Healthcare cuando envía una solicitud.
2. La capa de middleware reintenta la solicitud cinco veces más, alcanza su límite y, luego, deja de reintentarla.
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 devuelve 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. Tanto el cliente como el proxy implementan el manejo de errores y los reintentos.

Figura 1: Las capas en las que debes implementar la lógica de reintentos y los tiempos de espera son Client y 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 devuelve 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 devuelve el estado de error final, 500 Internal Server Error, al cliente.

   Con las recomendaciones que se mostraron anteriormente, puedes depurar el estado de error final 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 devolvió la API de Cloud Healthcare.

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

Elige qué errores reintentar

Según la arquitectura del sistema, puedes volver a intentar ciertas acciones que generaron errores y omitir otras. A continuación, se incluye una lista no exhaustiva de los 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 es posible que algunos nunca ocurran.

Efectos de la arquitectura del sistema

La arquitectura de tu sistema influye en cómo y cuándo reintentas 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 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 el problema se debió a un token de autenticación vencido, 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 reintenta según tus hallazgos.

Planifica los estados de error finales

Incluso después de implementar la lógica de reintentos y los tiempos de espera, un cliente o middleware podría 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 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 un humano lo revise.

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

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

Planifica el aumento de la 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 generar 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 cruza 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 que un cliente envía una solicitud, medido en fracciones de segundo, puede coincidir con un momento en que la API de Cloud Healthcare está bajo 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 realizar las solicitudes que generaron errores en el servidor, lo que puede aumentar la latencia para los clientes.
• Es posible que haya varias copias de los 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, es posible que aumente la latencia.

Planifica el uso de la latencia de percentil

Puedes planificar el aumento de la latencia analizando la latencia de 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 un plazo de dos segundos.

Si analizas la latencia de percentil durante un intervalo en el que la API de Cloud Healthcare solo procesó algunas solicitudes, es posible que la latencia de percentil no sea útil ni indicativa del rendimiento general, ya que las solicitudes atípicas 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 única 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 prolongado, 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 tu sistema al tráfico intenso.