Prácticas recomendadas para la latencia de las solicitudes y la gestión de errores

En esta página se describen las prácticas recomendadas para optimizar la latencia de las solicitudes y gestionar los errores en la API Cloud Healthcare. Implementa estas prácticas al planificar y diseñar la arquitectura de tu sistema.

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

Implementar lógica de reintentos y tiempos de espera

Para gestionar los retrasos y los errores causados por solicitudes fallidas, implementa una lógica de reintentos y tiempos de espera adecuados. Al definir la duración del tiempo de espera, deja suficiente tiempo para hacer lo siguiente:

• Permite que la API Cloud Healthcare procese la solicitud.
• Determina si el error se ha originado en el servicio o en el cliente.

Puedes volver a intentar algunas operaciones, pero otras no se pueden volver a intentar y persisten en varios intentos. Por ejemplo, si los datos de la solicitud no tienen el formato correcto, el servidor responde con el código de estado 400 Bad Request. La solicitud no se completará hasta que corrijas los datos.

Para gestionar 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 Reintentar solicitudes fallidas.

Gestionar errores en varias capas

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

Veamos la siguiente situación:

1. El middleware recibe un error 500 Internal Server Error de la API Cloud Healthcare al enviar una solicitud.
2. La capa de middleware vuelve a intentar enviar la solicitud cinco veces más, hasta alcanzar el límite, y, a continuación, deja de intentarlo.
3. El cliente recibe un error final de 500 Internal Server Error.

Es importante tener en cuenta que el error se ha originado en la API Cloud Healthcare, no en el middleware. Para simplificar la depuración, proporcione esta información en el error devuelto al cliente.

En el siguiente diagrama se muestra un caso en el que un proxy de middleware recibe errores 500 Internal Server Error al reenviar una solicitud de un cliente a la API Cloud Healthcare. Tanto el cliente como el proxy implementan la gestión de errores y los reintentos.

Imagen 1. Las capas en las que debes implementar la lógica de reintentos y los tiempos de espera son Cliente y Proxy.

En la imagen 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 Cloud Healthcare.
3. La API Cloud Healthcare devuelve un error 500 Internal Server Error al proxy. El proxy vuelve a intentar enviar 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 han mostrado 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

   Añade más información sobre el error devuelto por la API Cloud Healthcare.

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

Elige qué errores quieres volver a intentar

En función de la arquitectura de tu sistema, puedes volver a intentar realizar ciertas acciones que hayan dado error e ignorar otras. A continuación, se muestra una lista no exhaustiva de 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

Estos errores no suelen producirse con la misma frecuencia y es posible que algunos no se produzcan nunca.

Efectos de 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 Cloud Healthcare puede volver a autenticarse y reintentar su solicitud.

Supongamos que un sistema tiene una capa intermedia entre el cliente y la API Cloud Healthcare. Si el cliente se ha autenticado correctamente y el problema se debe a que el token de autenticación ha caducado, el middleware debe actualizar el token y volver a intentar enviar 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.

Planificar los estados de error finales

Aunque se implementen la lógica de reintentos y los tiempos de espera, es posible que un cliente o un middleware reciban errores hasta que se agoten los reintentos. El último error devuelto antes de que se agoten los reintentos y los tiempos de espera es el estado de error final. Es posible que se produzca un error final debido a errores de coherencia de datos.

A veces, un estado de error final requiere la 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 pueda revisarlo.

Ten en cuenta lo siguiente al planificar cómo gestionar 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 FHIR.
• Si muchas instancias de máquina virtual (VM) empiezan a fallar permanentemente, un cliente debe informar de las solicitudes que han fallado. Una vez que se haya solucionado el problema, el cliente debe volver a intentar enviar las solicitudes.
• Los sistemas de monitorización y alertas, así como los objetivos de nivel de servicio (SLOs), son necesarios para garantizar la estabilidad de tu sistema. Consulte Pruebas y monitorización para obtener más información.

Planifica un aumento de la latencia

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

• Las pequeñas diferencias entre las solicitudes, aunque parezcan insignificantes, pueden provocar que se tarde más en procesarlas.
• Las solicitudes similares pueden tener latencias diferentes. Por ejemplo, dos solicitudes similares que añaden un registro al almacenamiento de datos pueden tener latencias diferentes si una de ellas supera un umbral que activa una tarea adicional, como asignar más almacenamiento.
• La API Cloud Healthcare gestiona muchas solicitudes simultáneamente. 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 Cloud Healthcare esté sometida a una carga mayor de lo habitual.
• Si un recurso físico de la API Cloud Healthcare, como un disco, gestiona muchas solicitudes, debe completar las tareas en cola antes de gestionar otras solicitudes.
• A veces, la API Cloud Healthcare vuelve a intentar realizar operaciones que han devuelto errores en el servidor, lo que puede aumentar la latencia de los clientes.
• Puede haber varias copias de los datos en diferentes centros de datos de 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 que la latencia aumente.

Planificar usando la latencia de percentil

Para planificar el aumento de la latencia, analice la latencia de percentil de sus 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, del 50% de las solicitudes más rápidas. Por ejemplo, si la latencia del percentil 50 es de 0,5 segundos, significa que la API Cloud Healthcare ha procesado 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, del 99% de las solicitudes más rápidas. Por ejemplo, si la latencia del percentil 99 es de dos segundos, significa que la API Cloud Healthcare ha procesado el 99% de las solicitudes en dos segundos.

Si analizas la latencia de percentil durante un intervalo en el que la API Cloud Healthcare solo ha procesado unas pocas solicitudes, es posible que la latencia de percentil no sea útil ni indicativa del rendimiento general, ya que las solicitudes atípicas pueden influir mucho.

Por ejemplo, supongamos que un proceso de la API 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 la latencia con una sola solicitud no es suficiente para saber si hay problemas de rendimiento.

Si recoges una muestra de solicitudes más grande durante un periodo más largo, como 24 horas, puedes obtener más información sobre el comportamiento general de tu sistema. Puedes usar estas muestras para determinar cómo responde tu sistema a un tráfico elevado.