Antimodèle : réponses aux erreurs de cache

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation 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.

Lorsque nous devons accéder fréquemment à des données qui ne changent pas trop souvent, nous vous recommandons vivement 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 les rendre persistantes et les récupérer plus rapidement. 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 examiner la stratégie de cache de réponse. La stratégie de cache de réponses de la plate-forme 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 et inconnue, et nous pouvons continuer à envoyer des réponses d'erreur en raison de la mise en cache, même après que le problème a été résolu

    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

Voyons cela 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 de backend spécifique sera indisponible pendant 1 heure

    OR

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

Grâce à ces informations, nous pouvons définir le délai d'expiration du cache de manière appropriée dans la stratégie de cache de réponse afin de ne pas mettre en cache les réponses d'erreur 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 devez 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 afin de vous assurer que les réponses d'erreur ne seront pas mises en cache au-delà de la période 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.