Partager via

Vue d’ensemble de la mise en cache

S’APPLIQUE À : Tous les niveaux de Gestion des API

Configurez la mise en cache dans Gestion des API Azure pour stocker et récupérer des réponses aux demandes d’API et aux informations associées. En stockant les réponses des services back-end, Gestion des API peut traiter les requêtes identiques suivantes directement à partir du cache, ce qui réduit la nécessité d’appeler le service principal à plusieurs reprises. La mise en cache peut améliorer les performances des API, réduire la charge back-end et améliorer l’expérience globale des clients appelant des API via Gestion des API.

Cet article explique les options de mise en cache dans Gestion des API et met en évidence les principaux scénarios et considérations de configuration.

Important

La mise en cache nécessite à la fois un service de mise en cache ( soit un cache interne déployé automatiquement dans le cadre du service Gestion des API, soit un cache externe déployé par vous) et la configuration des stratégies de mise en cache pour spécifier la façon dont la mise en cache doit être appliquée aux demandes d’API.

Options de service de mise en cache

Gestion des API Azure fournit les options de service de mise en cache suivantes pour répondre à différentes exigences en matière de performances et d’architecture.

  • Interne (intégré) : le cache interne (intégré) est automatiquement provisionné dans tous les niveaux de service Gestion des API (à l’exception du niveau Consommation ). L’implémentation du cache interne diffère entre les niveaux classiques (Développeur, De base, Standard et Premium) et les niveaux v2 (De base v2, Standard v2 et Premium v2). Le cache intégré dans les niveaux v2 offre une fiabilité améliorée. En savoir plus sur la mise en cache avec le cache intégré.

  • Cache externe : pour améliorer les performances et la persistance, configurez éventuellement un cache compatible Redis externe, tel qu’Azure Managed Redis, à utiliser avec n’importe quel niveau de service ou passerelle Gestion des API. En savoir plus sur la configuration d’un cache externe avec Azure Managed Redis.

Le tableau suivant compare les fonctionnalités du cache interne et externe.

Capacité Interne External
Approvisionnement et gestion automatiques ✔️ ❌
Coût ajouté ❌ ✔️
Configuration personnalisée ❌ ✔️
Disponibilité dans tous les niveaux et passerelles Non disponible dans le niveau Consommation ou la passerelle auto-hébergée ✔️
Stockage régional Cache fourni dans la même région que l’instance Gestion des API et partagé entre les unités d’échelle.

Dans un déploiement multirégion , chaque région a son propre cache.		 Dépend de la préférence du client
Stockage persistant Persistant dans les niveaux v2.

Dans les niveaux classiques (Développeur, De base, Standard et Premium), le contenu du cache n’est pas conservé lorsque les mises à jour du service ont lieu.		 ✔️
Limites par niveau La taille du cache varie selon le niveau de service Non limité
Accès partagé par plusieurs instances gestion des API ❌ ✔️
Prise en charge de la mise en cache sémantique ❌ ✔️
Prise en charge du préchargement et de la purge des données ❌ ✔️

Scénarios de mise en cache

Utilisez la mise en cache dans Gestion des API Azure pour les scénarios comme ceux du tableau suivant.

Scénario Descriptif Type de cache Comportement avec perte de disponibilité ou de connectivité du cache
Optimiser l’expérience client Accélérer le traitement des demandes répétitives pour les clients. Interne ou externe Le serveur principal traite les requêtes et doit gérer la charge complète si le cache n’est pas disponible.
Contrôler les coûts et la mise à l’échelle du back-end Réduisez la charge et les coûts du back-end lorsque celui-ci n'est pas dimensionné pour gérer l'intégralité du trafic. External Dépend de la configuration du cache et du service. Recommandation : sélectionnez un niveau de service de cache avec la fiabilité la plus élevée et surveillez les performances.
Magasin de métadonnées Utilisez cache-store-value pour stocker des données arbitraires dans le cache. Interne ou externe Dépend de la configuration du cache et du service.

Considerations:

  • Dans n’importe quel scénario de mise en cache, envisagez la perte de disponibilité ou de connectivité du cache. Gestion des API utilise une approche « meilleur effort » pour la disponibilité du cache. Si un cache configuré n’est pas disponible, les absences de cache se produisent et, par défaut, les demandes continuent vers le service back-end.

  • Dans les niveaux classiques gestion des API, le cache interne est volatile et ne persiste pas dans les mises à jour du service. Pendant une mise à jour de service, le cache interne est effacé dans un processus progressif qui implique jusqu’à 50% du cache à la fois.

    Note

    Vous pouvez configurer les paramètres de mise à jour du service, y compris une fenêtre de maintenance pour les mises à jour, afin de réduire les impacts potentiels du client, tels que la perte du cache interne.

  • Si vous configurez un cache externe, il peut être persistant, mais vous êtes responsable de la disponibilité et de la connectivité.

  • Pour protéger le service principal contre les pics de trafic qui peuvent la surcharger lorsqu’un cache n’est pas disponible, configurez une stratégie de limitation de débit (limite de débit ou limite de débit par clé) immédiatement après toute stratégie de recherche de cache.

Stratégies de mise en cache

Configurez des stratégies de mise en cache pour contrôler la façon dont les réponses des API sont mises en cache et récupérées dans Gestion des API Azure.

  • Par défaut, dans les stratégies de mise en cache, Gestion des API utilise un cache externe s’il est configuré et revient au cache intégré dans le cas contraire.

  • Gestion des API fournit des stratégies de mise en cache en paires, comme indiqué dans le tableau suivant. Dans une définition de stratégie, configurez une stratégie de recherche de cache dans la inbound section pour rechercher les réponses mises en cache et une stratégie de magasin de cache dans la outbound section pour stocker les réponses réussies dans le cache.

Policies Descriptif Usage
consultation du cache / stockage du cache - Récupérer une réponse à partir du cache
- Stocker une réponse dans la demande de cache		 - Permet de récupérer une réponse d’API complète à partir du cache pour une requête identique GET
cache-lookup-value / cache-store-value - Récupérer une valeur spécifique à partir du cache
- Stocker une valeur spécifique dans le cache		 - Utiliser pour les scénarios de mise en cache personnalisés avec des clés de cache spécifiques
azure-openai-semantic-cache-lookup / azure-openai-semantic-cache-store - Vérifiez si une réponse sémantiquement similaire existe dans le cache pour une requête d’API Azure OpenAI
- Stocker une réponse pour une demande d’API Azure OpenAI		 - Utiliser pour récupérer des réponses similaires aux demandes d’API d’achèvement de conversation Azure OpenAI
llm-semantic-cache-lookup / llm-semantic-cache-store - Vérifiez si une réponse sémantiquement similaire existe dans le cache pour une requête d’API LLM
- Stocker une réponse pour une requête d’API LLM		 - Utiliser pour récupérer des réponses similaires aux requêtes API LLM Chat Completion

Conseil / Astuce

  • Les stratégies de stockage des entrées dans le cache incluent un duration attribut pour spécifier la durée pendant laquelle une entrée mise en cache persiste.
  • Utilisez cache-remove-value pour supprimer une valeur spécifique identifiée par la clé du cache.

Exemples de stratégie de mise en cache

Voici des exemples de base de stratégies de mise en cache dans Gestion des API. Pour plus d’exemples, consultez les articles de référence sur la stratégie de mise en cache.

Mise en cache des réponses

Mettre en cache la réponse complète de l’API dans le cache interne pour traiter des requêtes identiques sans appels back-end. Dans cet exemple, le cache stocke les réponses pendant sept jours.

<policies>
    <inbound>
        <base />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" >
            <vary-by-query-parameter>version</vary-by-query-parameter>
        </cache-lookup>
    </inbound>
    <outbound>
        <cache-store duration="604800" />
        <base />
    </outbound>
</policies>

Mise en cache des valeurs

Mettre en cache des valeurs de données spécifiques pour la réutilisation sur plusieurs requêtes.

<policies>
    <inbound>
        <cache-lookup-value key="user-preferences" default-value="none" variable-name="preferences" />
        <choose>
            <when condition="@(context.Variables["preferences"].ToString() == "none")">
                <!-- Load preferences from backend -->
                <send-request mode="new" response-variable-name="prefsResponse">
                    <set-url>https://backend.api/user/preferences</set-url>
                </send-request>
                <cache-store-value key="user-preferences" value="@(((IResponse)context.Variables["prefsResponse"]).Body.As<string>())" duration="1800" />
            </when>
        </choose>
    </inbound>
</policies>

Protection de limitation de débit

En guise de meilleure pratique, combinez la recherche de cache avec une limitation de débit pour protéger les services principaux.

<policies>
    <inbound>
        <cache-lookup-value key="@("data-" + context.Request.IpAddress)" variable-name="cachedData" />
        <choose>
            <when condition="@(!context.Variables.ContainsKey("cachedData"))">
                <rate-limit calls="10" renewal-period="60" />
                <!-- Proceed to backend -->
            </when>
            <otherwise>
                <!-- Return cached data without rate limiting -->
                <return-response>
                    <set-body>@((string)context.Variables["cachedData"])</set-body>
                </return-response>
            </otherwise>
        </choose>
    </inbound>
</policies>

Considérations relatives à la sécurité

  • Données sensibles : éviter la mise en cache des réponses contenant des informations sensibles ou personnelles
  • Clés de cache : vérifiez que les clés de cache n’exposent pas d’informations sensibles dans les journaux ou les diagnostics
  • Contrôle d’accès : le cache externe nécessite une sécurité réseau et des contrôles d’accès appropriés
  • Chiffrement : Utiliser TLS/SSL pour les connexions à des instances de cache externes

Contenu connexe

  • Last updated on