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

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 qui définit la disponibilité prévue du service de l'API Cloud Healthcare et la façon 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 relancer certaines erreurs, mais d'autres ne peuvent pas faire l'objet d'une nouvelle tentative et sont conservées plusieurs tentatives. Par exemple, si les données de la requête ne sont pas correctement formatées, le serveur répond avec un code d'état 400 Bad Request. La demande ne sera pas jusqu'à ce que les données soient corrigé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 sur plusieurs couches

Lorsque le middleware interagit avec l'API Cloud Healthcare, implémentez une logique de nouvelle tentative. et les 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 déterminer 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 du API Cloud Healthcare lors de l'envoi d'une requête.
2. La couche middleware relance la requête cinq fois de plus, atteignant son puis arrête les 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 de l'intergiciel. À 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 Erreurs 500 Internal Server Error lors du transfert d'une requête d'un client vers l'API Cloud Healthcare. Le client et le proxy implémentent tous deux le gestion des exceptions et les nouvelles tentatives.

Figure 1 Couches où vous devez implémenter une logique de nouvelle tentative et des 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 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 réessaie la requête cinq fois de plus 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 le code suivant : 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 vous devrez peut-être intervenir pour déterminer si l'erreur provient du proxy API Cloud Healthcare.

Choisir les erreurs à réessayer

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

• 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 façon dont vous relancez les erreurs et le moment où elles le sont.

Par exemple, dans une architecture directe de client à serveur, un client qui reçoit une erreur 401 UNAUTHENTICATED dans L'API Cloud Healthcare peut s'authentifier à nouveau et relancer 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é une logique de nouvelle tentative et des délais avant expiration, un client ou un middleware peut recevoir des erreurs jusqu'à ce que les nouvelles tentatives soient épuisées. La dernière erreur renvoyée avant les tentatives les délais avant expiration sont é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, consignez l'état d'erreur final afin qu'un humain puisse l'examiner.

Tenez compte des points suivants lorsque vous planifiez comment gérer les é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îne un délai 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 ont des latences différentes si l'une d'elles dépasse un seuil une tâche supplémentaire, comme allouer plus d'espace de stockage.
• L'API Cloud Healthcare traite de nombreuses requêtes simultanément. Le moment où lorsqu'un client envoie une requête, mesurée en fractions de seconde, peut coïncider à un moment où l'API Cloud Healthcare est sous 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 y avoir plusieurs copies de données dans différents centres de données dans une zone régionale ou multirégionale. Si vos requêtes sont acheminées dans plusieurs centres de données, soit sur la requête initiale, soit lors d'une nouvelle tentative, la latence peut augmenter.

Planifier en utilisant la latence au centile

Vous pouvez prévoir une augmentation de la latence en analysant la latence centile des vos demandes. Les exemples suivants décrivent la latence au 50e centile et la latence au 99e centile :

• La latence du 50e centile est la latence maximale, en secondes, pour le 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 a traité 50% des requêtes en moins de 0,5 seconde. La latence du 50e centile est également appelée la "latence médiane".
• La latence du 99e centile est la latence maximale, en secondes, pour le 99% des requêtes sont 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 (24 heures, par exemple) vous permet de mieux cerner le comportement de votre système. Vous pouvez utiliser ces exemples pour déterminer comment votre système réagit à un trafic important.