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 controlar los retrasos y los errores causados por 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 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 tener éxito 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 Vuelve a intentar las solicitudes que fallaron.

Controla 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 por encima de su límite de reintentos, 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 planifican 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 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 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 reenvía una solicitud de un cliente a la API de Cloud Healthcare. El cliente y el proxy implementan el control 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 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 su y 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 recibe errores 500 Internal Server Error después de los 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 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 la API de Cloud Healthcare que se pueden reintentar Códigos de error:

  • 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 reintentar 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 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 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 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 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 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, 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 uno 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 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 generar errores del servidor, lo que puede aumentar de red 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 una mayor latencia, puedes analizar el percentil de latencia de tus solicitudes. El Los siguientes ejemplos describen la latencia del percentil 50 y las Latencia del percentil 99:

  • La latencia del percentil 50 es la latencia máxima, en segundos, para el el 50% de las solicitudes más rápidas. 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 99% más rápido 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 para los 100 minutos se basaría 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.