Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans Recherche Azure AI, la capacité est basée sur des réplicas et des partitions qui peuvent être mis à l’échelle vers votre charge de travail. Les répliques sont des copies du moteur de recherche. Les partitions sont des unités de stockage. Au début, chaque nouveau service de recherche en dispose d’une, mais vous pouvez ajouter ou supprimer des réplicas et des partitions indépendamment pour prendre en charge les charges de travail fluctuantes. L’ajout de capacité augmente le coût d’exécution d’un service de recherche.
Les caractéristiques physiques des réplicas et des partitions, telles que la vitesse de traitement et les E/S de disque, varient selon le niveau tarifaire. Sur un service de recherche standard, les réplicas et les partitions sont plus rapides et supérieurs à ceux d’un service de base.
Le changement de capacité n’est pas instantané. L’activation ou la désactivation des partitions peut prendre jusqu’à une heure, en particulier pour les services comportant de grandes quantités de données.
Durant la mise à l’échelle d’un service de recherche, vous avez le choix entre les approches et les outils suivants :
Remarque
Si votre service a été créé avant avril ou mai 2024, une mise à niveau ponctuelle vers des limites de stockage plus élevées peut être disponible sans frais supplémentaires. Pour plus d’informations, consultez Mettre à niveau votre service de recherche.
Concepts : unités de recherche, réplicas, partitions
La capacité est exprimée en unités de recherche qui peuvent être allouées en supplément des partitions et des réplicas.
| Concept | Définition |
|---|---|
| Unité de recherche | Incrément unique de la capacité disponible totale (36 unités). Le service a besoin au minimum d’une unité pour s’exécuter. La première paire réplica/partition est la première unité de recherche. Toutefois, chaque instance supplémentaire d’une réplique ou d’une partition consomme une unité de recherche supplémentaire. Par exemple, vous commencez par un réplica et une partition (une unité de recherche), ajoutez un deuxième réplica, vous consommez maintenant deux unités de recherche. Une unité de recherche est également l’unité de facturation pour un service Recherche Azure AI. |
| Réplique | Instances du service de recherche, principalement utilisées pour équilibrer la charge des opérations de requête. Chaque réplica héberge une copie d’un index. Si vous allouez trois réplicas, vous avez trois copies d’un index disponibles pour traiter les demandes de requête. |
| Partition | Stockage physique et E/S pour les opérations de lecture/écriture (par exemple, pendant la reconstruction ou l’actualisation d’un index). Chaque partition contient une section de l’index total. Si vous allouez trois partitions, l’index est divisé en trois. |
Passez en revue la table des partitions et des réplicas pour connaître les combinaisons possibles qui restent sous la limite de 36 unités.
Moment opportun pour ajouter de la capacité
Au départ, un service se voit allouer un niveau minimal de ressources consistant en une partition et une réplique. Le niveau que vous choisissez détermine la taille et la vitesse de partition, et chaque niveau est optimisé autour d’un ensemble de caractéristiques qui correspondent à différents scénarios. Si vous choisissez un niveau supérieur, vous devrez peut-être moins de partitions que si vous utilisez S1. L’une des questions que vous devez répondre par le biais de tests auto-dirigés est de savoir si une partition plus grande et plus coûteuse génère de meilleures performances que deux partitions moins coûteuses sur un service approvisionné à un niveau inférieur.
Un seul service doit avoir suffisamment de ressources pour gérer toutes les charges de travail (indexation et requêtes). Aucune charge de travail ne s’exécute en arrière-plan. Vous pouvez planifier l’indexation à des moments où les requêtes de requête sont naturellement moins fréquentes, mais le service ne hiérarchise pas une tâche par rapport à une autre. De plus, un certain degré de redondance lisse les performances des requêtes lorsque les services ou les nœuds sont mis à jour en interne.
Les instructions pour déterminer s’il faut ajouter de la capacité sont les suivantes :
- Respect des critères de haute disponibilité pour le contrat de niveau de service.
- La fréquence des erreurs HTTP 503 (Service indisponible) augmente.
- La fréquence des erreurs HTTP 429 (Trop de requêtes) augmente, ce qui indique un stockage faible.
- Un grand volume de requêtes est attendu.
- Une mise à niveau ponctuelle vers une infrastructure plus récente et des partitions plus volumineuses n’est pas suffisante.
- Le nombre actuel de partitions n’est pas suffisant pour l’indexation des charges de travail.
En règle générale, les applications de recherche tendent à avoir besoin de plus de réplicas que de partitions, en particulier lorsque les opérations de service favorisent les charges de travail de requête. Chaque réplica est une copie de votre index, ce qui permet au service d’équilibrer la charge des requêtes sur plusieurs copies. Azure AI Search gère l’équilibrage de charge et la réplication d’un index, et vous pouvez modifier le nombre de réplicas alloués pour votre service à tout moment. Vous pouvez allouer jusqu'à 12 réplicas dans un service de recherche Standard, et 3 dans un service de recherche de base. L’allocation de réplique peut être effectuée à partir du portail Azure ou de l’une des options programmatiques.
Les partitions supplémentaires sont utiles pour les charges de travail d’indexation intensives. Des partitions supplémentaires répartissent les opérations de lecture/écriture sur un plus grand nombre de ressources de calcul.
Enfin, plus les index sont grands, plus ils sont longs à interroger. Par conséquent, peut-être constaterez-vous que chaque augmentation des partitions nécessite une augmentation plus faible mais proportionnelle des répliques. La complexité de vos requêtes et le volume de celles-ci influencent la rapidité d'exécution des requêtes.
Remarque
L’ajout de réplicas ou de partitions augmente le coût d’exécution du service et peut introduire de légères variations dans l'ordre des résultats. Veillez à vérifier la calculatrice de prix pour comprendre les implications de facturation de l’ajout de nœuds supplémentaires. Le graphique ci-dessous peut vous aider à référencer le nombre d’unités de recherche requises pour une configuration spécifique. Pour plus d’informations sur la façon dont les réplicas supplémentaires affectent le traitement des requêtes, consultez le tri des résultats.
Comment mettre à niveau la capacité
Certaines fonctionnalités azure AI Search sont uniquement disponibles pour les nouveaux services. Une de ces fonctionnalités est une capacité de stockage plus élevée, qui s’applique aux services créés après avril 2024. Toutefois, si vous avez créé votre service avant avril 2024, vous pouvez obtenir une capacité plus élevée sans recréer votre service en effectuant une mise à niveau ponctuelle. Pour plus d’informations, consultez Mettre à niveau votre service de recherche.
Comment modifier la capacité
Pour augmenter ou diminuer la capacité de votre service, vous avez deux options :
Ajouter ou supprimer des partitions et des répliques
Connectez-vous au portail Azure et sélectionnez votre service de recherche.
Dans le volet gauche, sélectionnez Échelle des paramètres>.
La capture d’écran suivante montre un service Standard provisionné avec une réplique et une partition. La formule en bas indique combien d’unités de recherche sont utilisées (1). Si le prix unitaire était de 100 (prix fictif), le coût mensuel de l’exécution de ce service serait de 100 en moyenne.
Utilisez le curseur pour augmenter ou diminuer le nombre de partitions. Sélectionnez Enregistrer.
Cet exemple ajoute une deuxième réplique et une deuxième partition. Notez le nombre d’unités de recherche. Il est désormais de quatre, car la formule de facturation multiplie le nombre de réplicas par le nombre de partitions (2 x 2). Le doublement de la capacité fait plus que doubler le coût de l’exécution du service. Si le coût d’une unité de recherche était de 100, la nouvelle facture mensuelle serait désormais de 400.
Pour connaître les coûts actuels par niveau, consultez la page de tarification.
Vérifiez vos notifications pour confirmer que l’opération a démarré.
Cette opération peut prendre plusieurs heures. Vous ne pouvez pas annuler le processus après son démarrage, et il n’existe aucune surveillance en temps réel des ajustements de réplica et de partition. Toutefois, le message suivant s’affiche pendant que les modifications sont en cours.
Modifier votre niveau tarifaire
Remarque
La préversion 2025-02-01 prend en charge les modifications entre les niveaux De base et Standard (S1, S2 et S3). Actuellement, vous ne pouvez passer d’un niveau inférieur qu’à un niveau supérieur, par exemple passer de Basic à S1. Votre région ne peut pas non plus avoir de contraintes de capacité sur le niveau supérieur.
Votre niveau tarifaire détermine le stockage maximal de votre service de recherche. Si vous avez besoin d’une capacité supplémentaire , vous pouvez basculer vers un autre niveau tarifaire qui répond à vos besoins de stockage.
Outre la capacité, la modification de votre niveau tarifaire affecte la charge de travail et les limites maximales de votre service. Avant de continuer, comparez les limites de service de votre niveau actuel et de votre niveau souhaité. Il s’agit notamment des limites suivantes :
- Stockage de partitions
- Index
- Vecteurs
- Indexeurs
- Ressources de liaison privée partagée
- Synonymes
- Alias d’index
- Limitation du classement sémantique
En règle générale, le passage à un niveau supérieur augmente votre limite de stockage et votre limite de vecteur, augmente le débit des requêtes et diminue la latence.
Pour modifier votre niveau tarifaire :
Connectez-vous au portail Azure et sélectionnez votre service de recherche.
Dans le volet gauche, sélectionnez Échelle des paramètres>.
Sous votre niveau actuel, sélectionnez Modifier le niveau tarifaire.
Dans la page Sélectionner le niveau tarifaire , choisissez un niveau supérieur dans la liste. Actuellement, vous pouvez uniquement monter entre Basic, S1, S2 et S3. D’autres niveaux tarifaires ne sont pas disponibles et apparaissent grisés.
Pour basculer vers le niveau supérieur, sélectionnez Sélectionner.
Cette opération peut prendre plusieurs heures. Vous ne pouvez pas annuler le processus après son démarrage, et il n’existe aucune surveillance en temps réel des modifications de niveau. Toutefois, dans la page Vue d’ensemble, un état d’approvisionnement indique que l’opération est en cours pour votre service.
Gestion des requêtes de mise à l’échelle
Quand une requête de mise à l’échelle est reçue, le service de recherche :
- Vérifie si la requête est valide.
- Démarre la sauvegarde des données et des informations système.
- Vérifie si le service est déjà dans un état de provisionnement (ajout ou suppression de réplicas ou de partitions).
- Démarre le provisionnement.
La mise à l’échelle d’un service peut prendre dans les 15 minutes ou bien plus d’une heure, selon la taille du service et l’étendue de la requête. La sauvegarde peut prendre plusieurs minutes, en fonction de la quantité de données et du nombre de partitions et de réplicas.
Les étapes ci-dessus ne sont pas entièrement consécutives. Par exemple, le système démarre le provisionnement quand il peut le faire de manière sécurisée, ce qui peut avoir lieu au moment où la sauvegarde s’achève.
Erreurs durant la mise à l’échelle
Le message d’erreur « Les opérations de mise à jour du service ne sont pas autorisées pour le moment, car nous traitons déjà une requête » est provoqué par la répétition d’une requête de scale-down ou de scale-up alors que le service traite déjà une requête.
Résolvez cette erreur en consultant l’état du service pour vérifier l’état du provisionnement :
- Utilisez l’API REST de gestion, Azure PowerShell ou Azure CLI pour obtenir l’état du service.
- Appelez Get Service (REST) ou équivalent pour PowerShell ou l’interface CLI.
- Vérifiez la réponse pour « provisioningState » : « provisioning »
Si le statut est « Provisioning », attendez que la demande soit terminée. L’état doit être "Succeeded" ou "Failed" avant qu’une autre requête ne soit tentée. Il n’existe aucun état pour la sauvegarde. La sauvegarde est une opération interne. Il est peu probable qu’elle soit un facteur disruptif dans un exercice de mise à l’échelle.
Si votre service de recherche semble bloqué dans un état d’approvisionnement, recherchez les index orphelins inutilisables, avec zéro volume de requête et aucune mise à jour d’index. Un index inutilisable peut bloquer les modifications apportées à la capacité de service. En particulier, recherchez les index chiffrés par CMK, dont les clés ne sont plus valides. Vous devez supprimer l’index ou restaurer les clés pour rétablir l’index en ligne et débloquer votre opération de mise à l’échelle.
combinaisons de partitions et de répliques
Le graphique suivant s’applique au niveau Standard et supérieur. Il affiche toutes les combinaisons possibles de partitions et de réplicas, dans la limite de 36 unités de recherche par service.
| 1 partition | 2 partitions | 3 partitions | 4 partitions | 6 partitions | 12 partitions | |
|---|---|---|---|---|---|---|
| 1 réplica | 1 unité de recherche | 2 unités de recherche | 3 unités de recherche | 4 unités de recherche | 6 unités de recherche | 12 unités de recherche |
| 2 répliques | 2 unités de recherche | 4 unités de recherche | 6 unités de recherche | 8 unités de recherche | 12 unités de recherche | 24 unités de recherche |
| 3 répliques | 3 unités de recherche | 6 unités de recherche | 9 unités de recherche | 12 unités de recherche | 18 unités de recherche | 36 unités de recherche |
| 4 réplicas | 4 unités de recherche | 8 unités de recherche | 12 unités de recherche | 16 unités de recherche | 24 unités de recherche | N/A |
| 5 répliques | 5 US | 10 SU | 15 unités de recherche | 20 unités de recherche | 30 unités de recherche | N/A |
| 6 répliques | 6 unités de recherche | 12 unités de recherche | 18 unités de recherche | 24 unités de recherche | 36 unités de recherche | N/A |
| 12 réplicas | 12 unités de recherche | 24 unités de recherche | 36 unités de recherche | N/A | N/A | N/A |
Les services de recherche Essentiel ont des nombres d’unités de recherche inférieurs.
Sur les services de recherche créés avant le 3 avril 2024, les services de base peuvent avoir exactement une partition et jusqu'à trois répliques pour une limite maximale de trois SUs. Les répliques sont les seules ressources ajustables. Toutefois, vous pouvez augmenter votre nombre de partitions en mettant à niveau votre service.
Sur les services de recherche créés après le 3 avril 2024 dans les régions prises en charge, les services de base peuvent avoir jusqu'à trois partitions et trois réplicas. La limite maximale d’unités de stockage (SU) est de neuf pour prendre en charge un ensemble complet de partitions et de réplicas.
Pour les services de recherche de tout niveau facturable, quelle que soit la date de création, vous avez besoin d’au moins deux réplicas pour assurer la haute disponibilité des requêtes.
Pour connaître les tarifs de facturation par niveau et devise, consultez la page de tarification Recherche d’IA Azure.
Estimer la capacité à l’aide d’un niveau facturable
La taille des index que vous prévoyez de générer détermine les besoins de stockage. Il n’existe pas d’euristique solide ou de généralités qui facilitent les estimations. La seule façon de déterminer la taille d’un index est de créer une. Sa taille est basée sur la tokenisation et les incorporations, et si vous activez les suggesteurs, le filtrage et le tri, ou peut tirer parti de la compression vectorielle.
Nous vous recommandons de procéder à l’estimation d’un niveau facturable, Essentiel ou supérieur. Le niveau Gratuit s’exécute sur des ressources physiques partagées par plusieurs clients et il est soumis à des facteurs qui vous échappent. Seules des ressources dédiées de service de recherche facturable peuvent prendre en charge un échantillonnage et des temps de traitement plus conséquents pour produire des estimations plus réalistes de quantité d’index, de taille et de volume de requête durant le développement.
Passez en revue les limites de service à chaque niveau pour déterminer si les niveaux inférieurs peuvent prendre en charge le nombre d’index dont vous avez besoin. Déterminez votre besoin en copies d’un index pour des environnements actifs de développement, de test et de production.
Un service de recherche est soumis à des limites de nombre d’objets (nombre maximal d’index, d’indexeurs, d’ensembles de compétences, etc.) et des limites de stockage. Quelle que soit la limite atteinte en premier, c’est la limite effective.
Créez un service à un niveau facturable. Niveaux optimisés pour certaines charges de travail. Par exemple, le niveau optimisé pour le stockage a une limite de 10 index, car il est conçu pour prendre en charge un faible nombre d’index volumineux.
Si vous n’êtes pas sûr de la charge projetée, commencez modestement, au niveau De base ou S1.
Commencez à un niveau élevé, à S2 ou même S3, si les tests comprennent des charges d’interrogation et d’indexation à grande échelle.
Enfin, si vous indexez une grande quantité de données et que la charge de requêtes est relativement faible, comme dans le cas d’une application métier interne, commencez par le niveau À stockage optimisé L1 ou L2.
Générez un index initial pour déterminer comment les données sources se traduisent en index. C’est l’unique façon d’estimer la taille de l’index. Les attributs des définitions de champ affectent les exigences de la mémoire physique :
Pour la recherche par mot clé, le marquage des champs comme filtrables et triables augmente la taille de l’index.
Pour la recherche vectorielle, vous pouvez définir des paramètres pour réduire la taille du vecteur.
Surveillez le stockage, les limites de service, le volume de requêtes et la latence dans le portail Azure. le Portail Azure affiche les requêtes par seconde, les requêtes limitées et la latence de recherche. Toutes ces valeurs peuvent vous aider à décider si vous avez sélectionné le niveau adéquat.
Ajoutez des réplicas pour une haute disponibilité ou pour atténuer les contre-performances des requêtes lentes.
Il n’existe aucune instruction sur le nombre de réplicas nécessaires pour prendre en charge les charges d’interrogation. Les performances des requêtes dépendent de la complexité des requêtes et des charges de travail concurrentes. Bien que l’ajout de réplicas entraîne clairement de meilleures performances, le résultat n’est pas strictement linéaire : l’ajout de trois réplicas ne garantit pas un débit multiplié par trois. Pour obtenir des conseils sur l’estimation de QPS pour votre solution, consultez Analyser les performanceset surveiller les requêtes.
Pour un index inversé, la taille et la complexité sont déterminés par le contenu, pas nécessairement par la quantité de données que vous entrez dans celui-ci. Une source de données volumineuse avec un haut niveau de redondance peut générer un index plus restreint qu’un jeu de données plus modeste présentant un contenu extrêmement variable. Il est donc généralement impossible de déduire la taille de l’index d’après celle du jeu de données d’origine.
Les exigences en matière de stockage peuvent être gonflées si vous incluez des données qui ne seront jamais recherchées. Dans l’idéal, les documents contiennent uniquement les données dont vous avez besoin pour l’expérience de recherche.
Considérations liées au contrat de niveau de service
Les fonctionnalités gratuites et préliminaires ne sont pas couvertes par les contrats de niveau de service (SLA). Pour tous les niveaux facturables, les SLA entrent en vigueur lorsque vous approvisionnez une redondance suffisante pour votre service.
Au moins deux réplicas répondent aux contrats SLA de requête (lecture).
Un SLA de requête et d’indexation (lecture-écriture) nécessite au moins trois réplicas.
Le nombre de partitions n’affecte pas les SLA.