Bonnes pratiques concernant la latence des requêtes et la gestion des exceptions

Cette page décrit les bonnes pratiques pour optimiser la latence des requêtes et gérer les erreurs dans l'API Cloud Healthcare. Mettez en œuvre ces pratiques lorsque vous planifiez et concevez l'architecture de votre système.

Google fournit un contrat de niveau de service qui définit le temps d'activité attendu du service de l'API Cloud Healthcare et la manière dont les clients peuvent gérer les erreurs. Pour en savoir plus, consultez la page Contrat de niveau de service de Cloud Healthcare.

Implémenter une logique de nouvelle tentative et des délais avant expiration

Pour gérer les retards et les erreurs causés par les requêtes ayant échoué, mettez en œuvre une logique de nouvelle tentative et des délais d'inactivité appropriés. Lorsque vous définissez le délai avant expiration, prévoyez suffisamment de temps pour effectuer les opérations suivantes:

  • Laissez l'API Cloud Healthcare traiter la requête.
  • Déterminez si l'erreur provient du service ou du client.

Vous pouvez relancer certaines erreurs, mais d'autres ne peuvent pas faire l'objet d'une nouvelle tentative et persistent après plusieurs tentatives. Par exemple, si le format des données de la requête est incorrect, le serveur répond par un code d'état 400 Bad Request. La requête n'aboutira pas tant que vous n'aurez pas corrigé les données.

Pour gérer ces situations, vous devez planifier les états d'erreur finaux.

Pour en savoir plus sur la logique de nouvelle tentative et sur les délais d'inactivité, consultez la section Relancer les requêtes ayant échoué.

Gérer les erreurs sur plusieurs couches

Lorsque le middleware interagit avec l'API Cloud Healthcare, implémentez une logique de nouvelle tentative et des délais d'inactivité dans le client et le middleware. Si un client rencontre des erreurs au-delà de sa limite de nouvelles tentatives, vous devez être en mesure de déterminer si l'erreur s'est produite dans le client, le middleware ou le service sous-jacent de l'API Cloud Healthcare. Cela est particulièrement important lors de la planification des états d'erreur finaux.

Imaginez le scénario suivant :

  1. Le middleware reçoit une erreur 500 Internal Server Error de l'API Cloud Healthcare lors de l'envoi d'une requête.
  2. La couche de middleware relance la requête cinq fois, atteignant sa limite, puis cesse d'effectuer de nouvelles tentatives.
  3. Le client reçoit une dernière erreur 500 Internal Server Error.

Il est important de comprendre que l'erreur provient de l'API Cloud Healthcare et non du middleware. Pour simplifier le débogage, fournissez ces informations dans l'erreur renvoyée au client.

Le schéma suivant illustre un scénario dans lequel un proxy de middleware reçoit des erreurs 500 Internal Server Error lors du transfert d'une requête d'un client à l'API Cloud Healthcare. Le client et le proxy implémentent tous deux la gestion des exceptions et les nouvelles tentatives.

Schéma de l'endroit où gérer les erreurs dans la pile client, middleware ou serveur.
Figure 1. Les couches dans lesquelles vous devez mettre en œuvre une logique de nouvelle tentative et des délais d'inactivité sont les couches Client et Proxy.

La figure 1 illustre les étapes suivantes:

  1. Le client envoie une requête valide à l'API Cloud Healthcare via un proxy de middleware.
  2. Le proxy transmet la requête à l'API Cloud Healthcare.
  3. L'API Cloud Healthcare renvoie une erreur 500 Internal Server Error au proxy. Le proxy relance la requête cinq fois jusqu'à ce que sa limite de nouvelles tentatives soit atteinte.
  4. Le proxy renvoie l'état d'erreur final, 500 Internal Server Error, au client.

    À l'aide des recommandations présentées précédemment, vous pouvez déboguer l'état d'erreur final en demandant au proxy de renvoyer l'erreur suivante au client:

    Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

    Ajoutez d'autres informations sur l'erreur renvoyée par l'API Cloud Healthcare.

Parfois, le client ou le proxy reçoit des erreurs 500 Internal Server Error qui ont dépassé la limite de nouvelles tentatives et ne peuvent pas réessayer. Dans ce cas, un humain peut avoir besoin d'intervenir pour déterminer si l'erreur provient du proxy ou de l'API Cloud Healthcare.

Sélectionner les erreurs à réessayer

Selon l'architecture de votre système, vous pouvez relancer certaines erreurs et en ignorer d'autres. Voici une liste non exhaustive des codes d'erreur de l'API Cloud Healthcare récupérables:

  • 408 Request Timeout
  • 425 Too Early
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Ces erreurs ne se produisent généralement pas à la même fréquence, et certaines peuvent ne jamais se produire.

Effets de l'architecture système

L'architecture de votre système détermine quand et comment vous relancez les erreurs.

Par exemple, dans une architecture client à serveur directe, un client qui reçoit une erreur 401 UNAUTHENTICATED de l'API Cloud Healthcare peut s'authentifier à nouveau et relancer sa requête.

Supposons qu'un système dispose d'une couche de middleware entre le client et l'API Cloud Healthcare. Si le client s'est correctement authentifié et qu'un jeton d'authentification expiré est à l'origine du problème, le middleware doit actualiser le jeton et relancer la requête.

Après avoir analysé les états d'erreur finaux, vous pouvez ajuster les erreurs que votre client relance en fonction de vos résultats.

Planifier les états d'erreur finaux

Même après avoir implémenté une logique de nouvelle tentative et des délais d'inactivité, un client ou un middleware peut recevoir des erreurs jusqu'à ce que le nombre de nouvelles tentatives soit épuisé. La dernière erreur renvoyée avant l'expiration des nouvelles tentatives et de l'expiration des délais d'attente correspond à l'état d'erreur final. Vous pouvez rencontrer un état d'erreur final pour les erreurs de cohérence des données.

Parfois, l'état d'erreur final nécessite une intervention humaine. Essayez de mettre en œuvre une solution pour résoudre l'état d'erreur final d'une requête. Sinon, consignez l'état d'erreur final pour qu'un humain puisse l'examiner.

Tenez compte des points suivants lorsque vous planifiez comment gérer les états d'erreur finaux:

  • Indique si le traitement des dépendances doit s'arrêter si une transaction ou un bundle FHIR ne peut pas se terminer correctement.
  • Si de nombreuses instances de machines virtuelles (VM) échouent définitivement, un client doit signaler les requêtes qui ont échoué. Une fois le problème résolu, le client doit relancer les requêtes.
  • La surveillance, les systèmes d'alerte et les objectifs de niveau de service (SLO) sont nécessaires pour garantir la stabilité de votre système. Pour en savoir plus, consultez la page Tester et surveiller.

Planifier l'augmentation de la latence

L'API Cloud Healthcare est un service évolutif et performant, mais la latence des requêtes peut toujours varier pour les raisons suivantes:

  • De petites différences entre les requêtes, même si elles semblent insignifiantes, peuvent entraîner un temps de traitement supplémentaire.
  • Les requêtes similaires peuvent avoir des latences différentes. Par exemple, deux requêtes similaires qui ajoutent un enregistrement au stockage de données peuvent avoir des latences différentes si l'une dépasse un seuil qui déclenche une tâche supplémentaire, comme attribuer de l'espace de stockage supplémentaire.
  • L'API Cloud Healthcare traite de nombreuses requêtes simultanément. Le moment auquel un client envoie une requête, mesuré en fractions de seconde, peut coïncider avec un moment où l'API Cloud Healthcare est soumise à une charge plus importante que d'habitude.
  • Si une ressource physique de l'API Cloud Healthcare, telle qu'un disque, traite de nombreuses requêtes, elle doit terminer ses tâches en file d'attente avant de traiter d'autres requêtes.
  • Parfois, l'API Cloud Healthcare relance les erreurs côté serveur, ce qui peut augmenter la latence pour les clients.
  • Il peut y avoir plusieurs copies des données dans différents centres de données dans un emplacement régional ou multirégional. Si vos requêtes sont acheminées vers plusieurs centres de données, lors de la requête d'origine ou lors d'une nouvelle tentative, la latence peut augmenter.

Planifier en utilisant la latence de centile

Vous pouvez planifier une augmentation de la latence en analysant la latence en centile de vos requêtes. Les exemples suivants décrivent la latence du 50e centile et la latence du 99e centile:

  • La latence du 50e centile correspond à la latence maximale, en secondes, pour les 50% de requêtes les plus rapides. Par exemple, si la latence du 50e centile est de 0,5 seconde, cela signifie que l'API Cloud Healthcare a traité 50% des requêtes en 0,5 seconde. La latence du 50e centile est également appelée "latence médiane".
  • La latence du 99e centile correspond à la latence maximale, en secondes, pour les 99% de requêtes les plus rapides. Par exemple, si la latence du 99e centile est de deux secondes, l'API Cloud Healthcare a traité 99% des requêtes en deux secondes.

Si vous analysez la latence du centile sur un intervalle lorsque l'API Cloud Healthcare n'a traité que quelques requêtes, cette latence peut ne pas être utile ou ne pas indiquer les performances globales, car les requêtes aberrantes peuvent avoir une grande influence.

Par exemple, supposons qu'un processus de l'API Cloud Healthcare traite 100 requêtes en 100 minutes. La latence du 99e centile pour les 100 minutes est basée sur la requête la plus lente. Une mesure de la latence à l'aide d'une seule requête ne suffit pas pour déterminer s'il existe des problèmes de performances.

En collectant un échantillon de requête plus important sur une période plus longue (24 heures, par exemple), vous pouvez obtenir des informations plus détaillées sur le comportement global de votre système. Vous pouvez utiliser ces exemples pour déterminer la manière dont votre système réagit à un trafic dense.