Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Renforcer l'isolement des locataires
L'isolation des locataires est un concept qui s'applique à tous les environnements multi-locataires. Cela signifie que vos politiques et stratégies garantissent qu'un locataire ne peut pas accéder aux autres ressources du locataire. Pour les agents à locataires multiples, vous devrez peut-être introduire des structures et des mécanismes qui aident à faire respecter les exigences d'isolation des locataires de l'agent.
L'application de l'isolation des locataires s'apparente à d'autres stratégies utilisant des systèmes multilocataires traditionnels. En général, lorsque vous créez une architecture AaaS, identifiez toute zone de votre système dans laquelle une demande ou une action peut accéder aux ressources afin de déterminer si la demande dépasse les limites des locataires. Par exemple, les microservices peuvent dépendre de tables Amazon DynamoDB dédiées par locataire. Cela vous oblige à mettre en place des politiques garantissant que la table d'un locataire ne soit pas accessible à un autre locataire.
Dans ce cas, considérez l'isolement du locataire du point de vue de l'agent et ses interactions avec l'une de ses ressources par locataire. Le schéma suivant montre un exemple conceptuel de la manière dont les agents appliquent des politiques d'isolation des locataires pour contrôler l'accès aux ressources des locataires.
Sur le côté droit de ce schéma, l'agent dispose de connaissances par locataire qui sont stockées dans des bases de données vectorielles distinctes. Lorsque l'agent traite une demande, il examine le contexte dans lequel le locataire fait la demande. Sur cette base, l'agent applique une politique d'isolation appropriée pour garantir que les locataires ne peuvent pas accéder aux données ou aux ressources en dehors de leurs limites désignées.
Si votre agent utilise un protocole MCP (Model Context Protocol), il peut également implémenter votre modèle d'isolation des locataires. Le schéma suivant montre un exemple de la manière d'introduire le MCP et d'appliquer des politiques d'isolation.
Le MCP est un protocole standardisé qu'un agent utilise pour s'intégrer à tous les outils, données et ressources. Dans cet exemple, un client MCP et un serveur MCP interagissent avec les connaissances et les outils spécifiques au locataire présentés sur le côté droit du schéma. Le contexte du locataire passe du client au serveur, et le serveur utilise ce contexte pour obtenir des informations d'identification définies par le locataire auprès du service Gestion des identités et des accès AWS (IAM). Les informations d'identification contrôlent l'accès aux ressources de chaque locataire, garantissant ainsi qu'un locataire peut accéder aux ressources d'un autre locataire.
À mesure que les agents intègrent le multi-tenant, ils doivent introduire des mécanismes qui appliquent les politiques d'isolation des locataires lorsqu'ils traitent les demandes. Dans certains cas, l'IAM peut contribuer à limiter l'accès aux ressources des locataires. Dans d'autres cas, vous devrez peut-être introduire d'autres outils ou cadres pour appliquer les politiques d'isolation des locataires.
Voisin et agents bruyants
Dans un environnement AaaS à locataires multiples où plusieurs locataires partagent un agent, réfléchissez à l'endroit et à la manière d'introduire des politiques qui empêchent les voisins bruyants. Les politiques peuvent introduire une limitation à usage général qui s'applique à toutes les consommations, ou vous pouvez avoir des politiques basées sur les locataires ou les niveaux qui appliquent une limitation en fonction d'un personnage donné. Vous pourriez imposer des restrictions de consommation plus importantes aux locataires de base qu'aux locataires de niveau supérieur.
Cette notion de régulation peut être appliquée à plusieurs points de l'architecture. Le schéma suivant montre un exemple de certains domaines dans lesquels il est possible d'introduire des politiques de voisinage bruyant.
Lors de notre examen précédent de la mise en œuvre de plusieurs agents, nous avons examiné les différentes ressources que votre agent peut utiliser, en mettant en évidence le potentiel de ressources par locataire au sein d'un agent. Chaque point de contact est un domaine susceptible d'entraîner l'introduction de politiques de limitation, qui permettent de garantir que les locataires ne dépassent pas les limites de consommation de votre système ou les politiques de hiérarchisation d'un locataire.
Les meilleurs endroits pour introduire des protections contre le bruit des voisins sont les points de l'architecture où les locataires partagent les ressources. Ces composants partagés ou regroupés, tels que le calcul, la mémoire et les grands modèles de langage APIs, sont les plus susceptibles de subir une dégradation des performances si un seul locataire consomme de manière disproportionnée.
L'un des endroits naturels pour appliquer la régulation est le point d'entrée de l'agent, parfois appelé « bord extérieur ». Ici, vous pouvez introduire des limites globales ou tenant-tier-based de débit avant que l'agent ne commence à traiter la demande. Le throttling peut également être appliqué plus profondément dans le chemin d'exécution, par exemple lorsque l'agent appelle un LLM, accède à la mémoire ou invoque des outils partagés.
Ces politiques vous aident à appliquer une utilisation équitable, à maintenir la résilience des agents sous charge et à garantir une expérience cohérente pour tous les locataires. En fonction de vos objectifs, vous pouvez vous concentrer sur la protection générale du système (résilience) ou sur la gestion détaillée de l'expérience des locataires (par exemple, avec des droits basés sur des niveaux).
