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

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

Google fournit un contrat de niveau de service (SLA) qui définit le temps de disponibilité prévu du service de l'API Cloud Healthcare et la manière dont les clients peuvent gérer les erreurs. Pour en savoir plus, consultez le contrat de niveau de service 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é, implémentez une logique de nouvelle tentative et des délais d'expiration appropriés. Lorsque vous définissez la durée du 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 réessayer certaines erreurs, mais d'autres ne peuvent pas être réessayées et persistent après plusieurs tentatives. Par exemple, si les données de la requête ne sont pas correctement formatées, le serveur renvoie un code d'état 400 Bad Request. La requête ne sera pas traitée 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 les délais d'expiration, consultez la section Réessayer des requêtes ayant échoué.

Gérer les erreurs à plusieurs niveaux

Lorsque le middleware interagit avec l'API Cloud Healthcare, implémentez une logique de nouvelle tentative et des délais avant expiration dans le client et le middleware. Si un client rencontre des erreurs au-delà de sa limite de nouvelle tentative, vous devez pouvoir identifier si l'erreur s'est produite dans le client, le middleware ou le service API Cloud Healthcare sous-jacent. 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 middleware relance la requête cinq fois de plus, atteignant sa limite, puis cesse de la relancer.
3. Le client reçoit une erreur 500 Internal Server Error finale.

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 diagramme suivant montre un scénario dans lequel un proxy de middleware reçoit des erreurs 500 Internal Server Error lors de la transmission 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.

Figure 1 Les couches où vous devez implémenter la logique de nouvelle tentative et les délais avant expiration sont le client et le proxy.

La figure 1 illustre les étapes suivantes:

1. Le client envoie une requête valide à l'API Cloud Healthcare via un proxy 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 réessaie la requête cinq fois de plus jusqu'à ce que sa limite de nouvelle tentative soit atteinte.

4. Le proxy renvoie l'état d'erreur final, 500 Internal Server Error, au client.

   En suivant les recommandations indiqué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 toute autre information sur l'erreur renvoyée par l'API Cloud Healthcare.

Parfois, le client ou le proxy reçoit des erreurs 500 Internal Server Error au-delà de ses limites de nouvelle tentative et ne peut pas réessayer. Dans ce cas, un humain peut devoir intervenir pour diagnostiquer si l'erreur provient du proxy ou de l'API Cloud Healthcare.

Choisir les erreurs à réessayer

En fonction de l'architecture de votre système, vous pouvez réessayer certaines erreurs et en ignorer d'autres. Voici une liste non exhaustive des codes d'erreur de l'API Cloud Healthcare pouvant être réessayés:

• 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 ne se produisent peut-être jamais.

Effets de l'architecture système

L'architecture de votre système influence la manière et le moment où vous réessayez 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 se réauthentifier et réessayer sa requête.

Supposons qu'un système comporte une couche middleware entre le client et l'API Cloud Healthcare. Si le client s'est authentifié correctement et qu'un jeton d'authentification expiré a causé le problème, le middleware doit actualiser le jeton et réessayer la requête.

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

Planifier les états d'erreur finaux

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

Parfois, un état d'erreur final nécessite une intervention humaine. Essayez d'implémenter une solution pour résoudre l'état d'erreur final d'une requête. Sinon, enregistrez l'état d'erreur final afin qu'un humain puisse l'examiner.

Tenez compte des points suivants lorsque vous planifiez la gestion des états d'erreur finaux:

• Indique si des dépendances de traitement doivent s'arrêter si une transaction ou un lot FHIR ne peut pas être traité correctement.
• Si de nombreuses instances de machine virtuelle (VM) commencent à échouer de manière permanente, un client doit signaler les requêtes qui ont échoué. Une fois le problème résolu, le client doit réessayer les requêtes.
• La surveillance, les systèmes d'alerte et les objectifs de niveau de service (SLO) sont nécessaires pour assurer la stabilité de votre système. Pour en savoir plus, consultez la section Tester et surveiller.

Planifier une 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'elles franchit un seuil qui déclenche une tâche supplémentaire, comme l'allocation de plus d'espace de stockage.
• L'API Cloud Healthcare gère de nombreuses requêtes simultanément. Le moment où 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 mises en file d'attente avant de traiter d'autres requêtes.
• Parfois, l'API Cloud Healthcare réessaie les erreurs côté serveur, ce qui peut augmenter la latence pour les clients.
• Il peut exister plusieurs copies de 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, que ce soit pour la requête d'origine ou pour une nouvelle tentative, la latence peut augmenter.

Planifier en utilisant la latence en centiles

Vous pouvez vous préparer à une augmentation de la latence en analysant la latence percentile de vos requêtes. Les exemples suivants décrivent la latence au 50e centile et la latence au 99e centile:

• La latence du 50e centile correspond à la latence maximale, exprimée en secondes, pour les 50% de requêtes les plus rapides. Par exemple, si la latence du 50e centile est de 0,5 seconde, l'API Cloud Healthcare traite 50% des requêtes en 0,5 seconde. La latence au 50e centile est également appelée "latence médiane".
• La latence du 99e centile correspond à la latence maximale, exprimée 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 traite 99% des requêtes en deux secondes.

Si vous analysez la latence percentile sur un intervalle où l'API Cloud Healthcare n'a traité que quelques requêtes, la latence percentile peut ne pas être utile ni indicative des 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 serait basée sur la requête la plus lente. Une mesure de latence à l'aide d'une seule requête n'est pas suffisante pour déterminer si des problèmes de performances existent.

Collecter un échantillon de requêtes plus important sur une période plus longue, par exemple 24 heures, peut fournir plus d'informations sur le comportement global de votre système. Vous pouvez utiliser ces exemples pour déterminer comment votre système réagit à un trafic important.