Antimodèle : réponses aux erreurs de cache

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

La mise en cache est un processus de stockage temporaire des données dans une zone de stockage appelée cache pour référence ultérieure. La mise en cache de données offre des avantages considérables en termes de performance, car elle :

  • permet une récupération plus rapide des données ;
  • réduit le temps de traitement en évitant de générer constamment des données ;
  • empêche les requêtes d'API d'atteindre les serveurs backend, et réduit ainsi la surcharge sur ces serveurs ;
  • améliore l'utilisation des ressources système/application ;
  • améliore le temps de réponse des API.

Chaque fois que nous devons accéder fréquemment à des données qui ne changent pas trop souvent, nous nous recommandons d'utiliser un cache pour stocker ces données.

Apigee Edge permet de stocker les données dans un cache au moment de l'exécution pour des raisons de persistance et d'accélération la récupération. La fonctionnalité de mise en cache est disponible dans des règles suivantes : Règle populationCache, Règle LookupCache, Règle InvalidateCache et Règle ResponseCache.

Dans cette section, nous allons étudier la stratégie du cache de réponse. Règle de cache de réponse dans Apigee Edge vous permet de mettre en cache les réponses des serveurs backend. Si les applications clientes envoient régulièrement des requêtes à la même ressource backend et que la ressource est mise à jour régulièrement, nous pouvons mettre ces réponses en cache à l'aide de cette règle. La stratégie de cache des réponses permet de renvoyer les réponses mises en cache et, par conséquent, d'éviter de transférer inutilement les requêtes aux serveurs backend.

La règle de cache des réponses :

  • réduit le nombre de requêtes atteignant le backend ;
  • réduit la bande passante réseau ;
  • Améliore les performances et des temps de réponse de l'API.

Antimodèle

La règle ResponseCache vous permet de mettre en cache par défaut les réponses HTTP avec n'importe quel code d'état possible. Cela signifie que les réponses de réussite et d'erreur peuvent être mises en cache.

Voici un exemple de stratégie de cache de réponse avec la configuration par défaut:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

La règle de mise en cache des réponses met en cache les réponses d'erreur dans sa configuration par défaut. Toutefois, il n'est pas recommandé de mettre en cache les réponses d'erreur sans un examen approfondi des implications défavorables, pour les raisons suivantes :

  • Scénario 1 : les défaillances se produisent pendant une période temporaire inconnue. Nous pouvons continuer à envoyer des réponses d'erreur en raison de la mise en cache, même après la résolution du problème.

    OR

  • Scénario 2 : les défaillances seront observées pendant une période fixe, puis il conviendra de modifier le code pour éviter de mettre en cache les réponses une fois le problème résolu

Examinons ces deux scénarios plus en détail.

Scénario 1 : Défaillance temporaire d'un backend/ressource

Notez que l'échec sur le serveur backend est dû à l'une des raisons suivantes :

  • Un problème technique au niveau du réseau.
  • Le serveur backend est extrêmement occupé et ne peut pas répondre aux requêtes pendant une période temporaire.
  • La ressource backend demandée peut être supprimée/indisponible pendant une période temporaire.
  • Le serveur backend répond lentement en raison d'un temps de traitement élevé pour une période temporaire, etc.

Dans tous ces cas, les échecs peuvent survenir pendant une période inconnue, puis nous pouvons commencer à obtenir des réponses correctes. Si nous mettons en cache les réponses d'erreur, nous pouvons continuer à les envoyer aux utilisateurs, même si le problème avec le serveur backend a été résolu.

Scénario 2 : Défaillance prolongée ou corrigée d'un backend/ressource

Notez que nous savons que l'échec dans le backend se produit pendant une période déterminée. Par exemple, vous savez que :

  • Une ressource backend spécifique sera indisponible pendant une heure.

    OR

  • Le serveur backend est supprimé/indisponible pendant 24 heures en raison d'une défaillance soudaine du site, d'un problème de scaling, d'une maintenance, d'une mise à niveau, etc.

Grâce à ces informations, nous pouvons définir le délai d'expiration du cache de manière appropriée dans le cache de réponse afin de ne pas mettre en cache les réponses d'erreur pendant plus longtemps. Toutefois, une fois que le serveur backend ou la ressource seront de nouveau disponibles, nous devrons modifier la règle pour éviter de mettre en cache les réponses d'erreur. En effet, s'il s'agit d'une défaillance temporaire/unique du serveur backend, nous mettrons en cache les réponses et nous aurons à résoudre le problème décrit dans le scénario 1 ci-dessus.

Impact

  • La mise en cache des réponses d'erreur peut entraîner l'envoi de réponses d'erreur, même lorsque le problème est résolu dans le serveur backend.
  • Les utilisateurs peuvent consacrer beaucoup d'efforts à la résolution d'un problème sans savoir qu'il est causé par la mise en cache des réponses d'erreur dans le serveur backend.

Bonne pratique

  • Ne stockez pas les réponses d'erreur dans le cache de réponses. Assurez-vous que l'élément <ExcludeErrorResponse> est défini sur true dans la règle ResponseCache pour empêcher la mise en cache des réponses d'erreur, comme indiqué dans l'extrait de code ci-dessous. Avec cette configuration, seules les réponses des codes de réussite par défaut 200 à 205 (sauf si les codes de réussite sont modifiés) seront mises en cache. 
    <!-- /antipatterns/examples/1-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServerResponseCache</DisplayName>
  <CacheKey>
    <KeyFragment ref="request.uri" />
  </CacheKey>
  <Scope>Exclusive</Scope>
  <ExpirySettings>
    <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
  </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
  <ExcludeErrorResponse>true</ExcludeErrorResponse>
</ResponseCache>
  • Si vous avez besoin de mettre en cache les réponses d'erreur pour une raison spécifique, vous pouvez déterminer la durée maximale/exacte pendant laquelle l'échec sera observé (si possible) :
    • Définissez le délai d'expiration de manière appropriée pour vous assurer de ne pas mettre en cache les réponses d'erreur. plus longue que la durée pendant laquelle l'échec est visible.
    • Utilisez la règle ResponseCache pour mettre en cache les réponses d'erreur sans l'élément <ExcludeErrorResponse>.

    N'effectuez cette opération que si vous êtes absolument certain que la défaillance du serveur backend n'est pas temporaire ou de courte durée.

  • Apigee ne recommande pas de mettre en cache les réponses 5xx des serveurs backend.