Fiabilité dans Azure AI Search

Recherche Azure AI est une infrastructure de recherche évolutive qui indexe du contenu hétérogène et permet la récupération via des API, des applications et des agents IA. Il convient aux scénarios de recherche d’entreprise et aux expériences client basées sur l’IA qui nécessitent une génération de contenu dynamique par le biais de modèles d’achèvement de conversation. En tant que service Azure, AI Search fournit une gamme de fonctionnalités pour prendre en charge vos exigences de fiabilité.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure AI Search résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance des services. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service Recherche Azure AI (SLA).

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de :

• Utilisez un niveau tarifaire qui dispose d’au moins deux réplicas. Cette configuration rend votre service de recherche plus résilient aux erreurs temporaires et aux opérations de maintenance. Il répond également au contrat de niveau de service (SLA) pour la recherche IA. Le contrat SLA nécessite deux réplicas pour les charges de travail en lecture seule et au moins trois réplicas pour les charges de travail en lecture-écriture.
• N’utilisez pas le niveau Gratuit pour une utilisation en production. La recherche IA ne fournit pas de SLA pour le niveau Gratuit, qui est limité à un réplica.

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous utilisez la recherche IA, vous créez un service de recherche. Chaque service de recherche prend en charge de nombreux index de recherche qui stockent votre contenu utilisable dans une recherche.

La recherche IA n’est pas conçue comme magasin de données principal. Au lieu de cela, vous utilisez des indexeurs pour connecter votre service de recherche à des sources de données externes. Un indexeur analyse les données sources, appelle les compétences qui effectuent le traitement et l’enrichissement, et remplit votre index avec les sorties de la compétence.

Vous configurez également le nombre de réplicas pour votre service. Dans la recherche en IA, une réplique est une copie du moteur de recherche de votre service. Vous pouvez considérer un réplica en tant que représentation d’une seule machine virtuelle. Chaque service de recherche peut avoir entre 1 et 12 réplicas.

L’ajout de plusieurs réplicas permet à Recherche IA de :

• Augmenter la disponibilité de votre service de recherche.

• Effectuez une maintenance sur un réplica pendant que les requêtes continuent à s’exécuter sur d’autres réplicas.

• Gérer des charges de travail d’indexation et de requête plus élevées.

• Améliorez la résilience en essayant de provisionner des réplicas dans différentes zones de disponibilité, si votre région les prend en charge.

Recherche IA affecte automatiquement un réplica pour être le réplica principal. Toutes les opérations en écriture sont effectuées sur ce réplica. Les autres réplicas sont utilisés pour les opérations en lecture.

Le diagramme suivant illustre la façon dont un service de recherche avec trois réplicas est susceptible d’être réparti sur trois zones de disponibilité :

Vous pouvez également configurer le nombre de partitions, qui représentent le stockage utilisé par les index de recherche.

Il est important de comprendre l’impact de l’ajout de répliques et de partitions, car ils affectent respectivement les performances de lecture et d’écriture de différentes manières. Pour découvrir plus d’informations sur les réplicas et les partitions, consultez Estimer et gérer la capacité d’un service de recherche.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Les indexeurs de recherche IA ont une gestion des erreurs temporaires intégrée. Si une source de données n’est pas disponible brièvement, l’indexeur est conçu pour récupérer et réessayer. Il utilise le suivi des modifications pour reprendre l’indexation à partir du dernier document indexé avec succès.

Les services de recherche peuvent rencontrer des erreurs temporaires pendant les opérations de maintenance standard et non planifiées. Recherche Azure AI ne fournit pas de notification préalable ni autorise la planification de la maintenance à des moments spécifiques. Bien que tous les efforts soient déployés pour réduire les temps d’arrêt, même pour les services à réplica unique, de brèves interruptions peuvent toujours se produire. Pour améliorer la résilience contre ces erreurs temporaires, nous vous recommandons d’utiliser deux réplicas ou plus.

Si vous créez des applications qui interagissent avec la recherche IA, elles doivent gérer les erreurs temporaires. Utilisez une stratégie de nouvelle tentative avec des backoffs exponentiels pour les opérations en lecture et en écriture.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Recherche AI est redondant interzone, ce qui signifie que vos réplicas sont répartis sur plusieurs zones de disponibilité au sein de la région du service de recherche.

Lorsque vous ajoutez deux réplicas ou plus à votre service, AI Search tente de placer chaque réplica dans une zone de disponibilité différente. Pour les services ayant plus de réplicas que de zones disponibles, les réplicas sont répartis dans les zones aussi uniformément que possible.

Le diagramme suivant montre un exemple de service de recherche avec quatre réplicas susceptibles d’être déployés sur trois zones de disponibilité :

Important

La recherche IA ne garantit pas le positionnement exact des réplicas. Le placement est soumis à des contraintes de capacité, à des opérations de mise à l’échelle et à d’autres facteurs.

Spécifications

La redondance de zone est automatiquement activée lorsque votre service de recherche répond à l’ensemble des critères suivants :

• Prise en charge de la région : La prise en charge des zones de disponibilité dépend de l’infrastructure et du stockage. Pour obtenir la liste des régions prises en charge, consultez Choisir une région pour la recherche IA.

• Niveau: Votre service doit se trouver au niveau De base ou supérieur

• Nombre de réplicas : Votre service doit avoir au moins deux réplicas

  Note

  Recherche IA essaye de distribuer des réplicas sur plusieurs zones lorsque vous avez deux réplicas ou plus. Toutefois, pour les charges de travail en lecture-écriture, nous vous recommandons d’utiliser au moins trois réplicas afin d’obtenir le contrat SLA de disponibilité le plus élevé possible.

Distribution d’instances entre zones

Recherche IA tente de placer des réplicas dans différentes zones de disponibilité. Cependant, il existe parfois des situations où tous les réplicas d’un service de recherche peuvent être placés dans la même zone de disponibilité. Cette situation peut se produire lorsque des réplicas sont supprimés de votre service, par exemple lorsque vous effectuez un scale-in en configurant votre service pour utiliser moins de réplicas. La suppression de réplicas ne déclenche pas le rééquilibrage des réplicas restants entre les zones de disponibilité.

Si vous souhaitez réduire la probabilité que tous vos réplicas soient placés dans une seule zone de disponibilité, vous pouvez déclencher manuellement une opération de scale-out immédiatement après une opération de scale-in. Par exemple, supposons que votre service de recherche dispose de 10 réplicas et que vous souhaitiez effectuer un scale-in vers 7 réplicas. Au lieu d’effectuer une opération de mise à l’échelle unique, vous pouvez effectuer une mise à l’échelle temporaire vers 6 instances, puis mettre immédiatement à l’échelle 7 instances pour déclencher le rééquilibrage de zone.

Coûts

Chaque service de recherche commence par un réplica. La redondance de zone nécessite deux réplicas ou plus, ce qui augmente le coût d’exécution du service. Pour comprendre les implications des répliques sur la facturation, utilisez le calculateur de prix.

Configurez la prise en charge des zones de disponibilité

Si votre service de recherche répond aux exigences de redondance de zone, aucune configuration supplémentaire n’est nécessaire. Dans la mesure du possible, la recherche IA tente de placer vos réplicas dans différentes zones de disponibilité.

Planification de capacité et gestion

Pour préparer une défaillance de zone de disponibilité, envisagez de surprovisionner le nombre de répliques. Le surprovisionnement permet au service de recherche de tolérer une perte de capacité et de continuer à fonctionner sans dégradation des performances. L’ajout de réplicas pendant une panne est difficile. Par conséquent, le surapprovisionnement permet de s’assurer que votre service de recherche peut gérer des volumes de requêtes normaux, même avec une capacité réduite. Pour plus d’informations, consultez Gérer la capacité en surprovisionnant.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce à quoi s’attendre lorsque les services de recherche sont configurés pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones : Recherche IA effectue l’équilibrage de charge automatique de toutes les requêtes et opérations en écriture dans tous les réplicas disponibles. La recherche par intelligence artificielle peut envoyer des opérations de lecture à n’importe quelle réplique dans n’importe quelle zone de disponibilité. Il envoie des opérations en écriture à un seul réplica principal sélectionné par le service Recherche IA.

• Réplication des données entre les zones : Les modifications apportées aux données sont automatiquement répliquées entre les réplicas entre les zones de disponibilité. La réplication se produit de manière asynchrone, ce qui signifie que les écritures sont validées sur un réplica principal avant d’être répliquées vers d’autres réplicas.

Comportement lors d’une défaillance de zone

Cette section décrit ce à quoi s’attendre lorsque les services de recherche sont configurés pour la redondance de zone et qu’une panne de zone de disponibilité se produit.

• Détection et réponse : La recherche par IA est chargée de détecter un échec dans une zone de disponibilité. Vous n’avez rien à faire pour initier un failover de zone.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Requêtes actives : les requêtes que les réplicas traitent dans la zone en échec sont arrêtées. Les clients doivent réessayer les demandes en suivant les instructions pour gérer les erreurs temporaires.

• Perte de données attendue : Si la zone de disponibilité affectée contient uniquement des réplicas en lecture, aucune perte de données n’est attendue.

  Si le réplica principal est perdu car il se trouvait dans la zone affectée, il est possible que toutes les opérations en écriture qui n’ont pas encore été répliquées soient perdues.

• Temps d’arrêt attendu : dans la plupart des cas, une défaillance de zone n’est pas censée provoquer un temps d’arrêt de votre service de recherche pour les opérations en lecture, car les réplicas en lecture dans d’autres zones de disponibilité continuent le traitement des requêtes.

  Si le réplica principal est perdu parce qu'il se trouvait dans la zone affectée, AI Search promeut automatiquement un autre réplica pour devenir le nouveau réplica principal afin que les opérations d’écriture puissent reprendre. La promotion du réplica prend généralement quelques secondes. Pendant ce temps, les opérations d’écriture peuvent ne pas réussir. Assurez-vous que vos applications sont préparées en suivant l’Guide de gestion des erreurs temporaires.

  Toutefois, il existe des situations peu probables où tous les réplicas de votre service de recherche peuvent se trouver dans une seule zone de disponibilité. Dans ce scénario, vous pouvez rencontrer des temps d’arrêt jusqu’à ce que la zone récupère. Pour découvrir plus d’informations et comprendre une solution de contournement, consultez Distribution d’instance.

• Réacheminement du trafic : En cas d’échec d’une zone, AI Search détecte l’échec et achemine les demandes vers des réplicas actifs dans les zones survivantes. Si la réplique principale est perdue, une autre réplique est promue et devient la nouvelle réplique principale.

Récupération de la zone

Lorsque la zone de disponibilité récupère, Recherche AI restaure automatiquement les opérations normales et commence à acheminer le trafic vers les réplicas disponibles dans toutes les zones, notamment la zone récupérée.

Tester les pannes de zone

AI Search gère le routage du trafic pour les services redondants interzone. Vous n’avez pas besoin d’initier ou de valider des processus d’échec de zone.

Résilience aux défaillances à l’échelle de la région

La recherche IA est un service à région unique. Si la région devient indisponible, votre service de recherche devient également indisponible.

Solutions multirégions personnalisées pour la résilience

Vous pouvez éventuellement déployer plusieurs services AI Search dans différentes régions. Il vous incombe du déploiement et de la configuration de services distincts dans chaque région. Si vous créez un déploiement identique dans une région Azure secondaire qui utilise une architecture multirégion, votre application devient moins vulnérable à une catastrophe à une seule région.

Lorsque vous suivez cette approche, vous devez synchroniser les index entre les régions pour récupérer le dernier état de l’application. Vous devez également configurer les stratégies d’équilibrage de charge et de basculement.

Si vous souhaitez optimiser les performances de votre solution globale, recherchez des opportunités d’indexation sur des réplicas en lecture seule de vos sources de données. Par exemple, certains indexeurs prennent en charge la lecture à partir des réplicas en lecture d’une source de données géo-distribuée.

Pour plus d’informations, consultez Déploiements multirégions dans Recherche IA Azure.

Sauvegarde et restauration

Étant donné que la recherche IA n’est pas une solution de stockage de données principale, elle ne fournit pas d’options de sauvegarde et de restauration en libre-service. Toutefois, vous pouvez utiliser l’exemple index-backup-restore pour .NET ou Python pour sauvegarder votre définition d’index et ses documents dans une série de fichiers JSON, qui sont ensuite utilisés pour restaurer l’index.

Toutefois, si vous supprimez accidentellement l’index et que vous n’avez pas de sauvegarde, vous pouvez reconstruire l’index. La reconstruction implique de recréer l’index sur votre service de recherche, puis de le recharger en récupérant des données à partir de votre magasin de données principal.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Dans la Recherche IA, le SLA de disponibilité s’applique aux services de recherche qui :

• Sont configurés pour utiliser un niveau facturable.
• Avoir deux réplicas au moins pour les charges de travail en lecture seule (requêtes).
• Avoir au moins trois réplicas pour les charges de travail en lecture-écriture (requêtes et indexation).

Contenu connexe

• Fiabilité dans Azure
• Limites de service dans la recherche IA
• Choisir une région pour la recherche IA
• Choisir un niveau tarifaire pour la recherche IA
• Planifier ou ajouter de la capacité dans la recherche IA