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

Cette page décrit les bonnes pratiques 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 l'architecture de votre système.

Google fournit un contrat de niveau de service (SLA) qui définit le temps d'activité attendu du service 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 nouvelles tentatives et des délais d'attente

Pour gérer les retards et les erreurs causés par les demandes ayant échoué, implémentez une logique de nouvelle tentative et des délais d'attente 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 pour certaines erreurs, mais d'autres ne peuvent pas être corrigées et persistent malgré plusieurs tentatives. Par exemple, si les données de la requête sont mal formatées, le serveur répond avec un code d'état 400 Bad Request. La requête ne fonctionnera 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 les délais d'expiration, consultez Réessayer d'exécuter 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 réessai et des délais d'attente dans le client et le middleware. Si un client rencontre des erreurs au-delà de sa limite de tentatives, vous devez être en mesure d'identifier si l'erreur s'est produite dans le client, le middleware ou le service d'API Cloud Healthcare sous-jacent. C'est particulièrement important lorsque vous planifiez les é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 intermédiaire relance la requête cinq fois de plus, jusqu'à atteindre 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 schéma suivant illustre un scénario dans lequel un proxy de middleware reçoit des erreurs 500 Internal Server Error lorsqu'il transfère 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 dans lesquelles vous devez implémenter la logique de nouvelle tentative et les délais d'attente sont 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 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 tentatives soit atteinte.

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

   En utilisant les recommandations présentées plus haut, 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 des informations sur l'erreur renvoyée par l'API Cloud Healthcare.

Il arrive que le client ou le proxy reçoivent des erreurs 500 Internal Server Error au-delà de leurs limites de nouvelles tentatives et ne puissent pas réessayer. Dans ce cas, une intervention humaine peut être nécessaire pour déterminer 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. Vous trouverez ci-dessous 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 peuvent ne jamais se produire.

Effets de l'architecture du système

L'architecture de votre système influe sur la manière et le moment où vous réessayez en cas d'erreur.

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 relancer sa requête.

Supposons qu'un système comporte une couche intermédiaire entre le client et l'API Cloud Healthcare. Si le client s'est authentifié correctement et qu'un jeton d'authentification expiré est à l'origine du 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 conclusions.

Planifier les états d'erreur finaux

Même après avoir implémenté une logique de nouvelle tentative et des délais d'attente, 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 l'épuisement des nouvelles tentatives et des délais avant expiration correspond à 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 pour qu'un humain puisse l'examiner.

Lorsque vous planifiez la façon de gérer les états d'erreur finaux, tenez compte des points suivants :

• Indique s'il existe des dépendances de traitement qui doivent s'arrêter si une transaction ou un bundle FHIR ne peuvent pas se terminer correctement.
• Si de nombreuses instances de machines virtuelles (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 d'envoyer les requêtes.
• Les systèmes de surveillance et d'alerte, ainsi que les objectifs de niveau de service (SLO), sont nécessaires pour assurer la stabilité de votre système. Pour en savoir plus, consultez Tester et surveiller.

Planifier une latence accrue

L'API Cloud Healthcare est un service évolutif et performant, mais la latence des requêtes peut 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.
• Des 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 dépasse un seuil qui déclenche une tâche supplémentaire, comme l'allocation de plus d'espace de stockage.
• L'API Cloud Healthcare traite 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 plus sollicitée 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 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 d'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 anticiper une latence accrue en analysant la latence en centiles 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, 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 moins de 0,5 seconde. La latence au 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, cela signifie que l'API Cloud Healthcare a traité 99 % des requêtes en moins de deux secondes.

Si vous analysez la latence en centiles sur un intervalle au cours duquel l'API Cloud Healthcare n'a traité que quelques requêtes, la latence en centiles 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 la latence basée sur une seule requête ne suffit pas pour déterminer s'il existe des problèmes de performances.

La collecte d'un échantillon de requêtes plus important sur une période plus longue, comme 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.