Agent Bucket : Un bucket de stockage natif pour agents à l'échelle du trillion

À l'heure où les agents IA prolifèrent, les développeurs créent à une vitesse sans précédent des applications intelligentes débordantes d'imagination. Des assistants de programmation capables de vous aider à écrire du code aux outils de création qui génèrent un film à partir d'une seule phrase, en passant par les assistants personnels intelligents toujours disponibles, les agents redéfinissent notre façon d'interagir avec le monde numérique. Derrière cette vague, un consensus se dégage : grâce à une architecture Serverless (comme Lambda), aux grands modèles de langage (LLM) et au stockage cloud (comme S3, TOS), combinés au Vibe Coding, n'importe qui peut rapidement créer son propre agent IA en 30 minutes.

Pour passer de "fonctionnel" à "performant", les développeurs d'agents doivent encore surmonter des difficultés pour transformer leurs "jouets" en "applications de production". À mesure que l'activité s'étend à un nombre massif d'utilisateurs, les développeurs sont confrontés à un défi extrêmement complexe : comment construire une solution de stockage complète pour un nombre massif d'utilisateurs finaux sur un stockage d'objets ? Pour la plupart des développeurs, il ne s'agit pas seulement d'un obstacle technique, mais aussi d'un fossé qui entrave la distribution à grande échelle des agents. Agent Bucket vise à simplifier radicalement le processus de construction de systèmes multi-locataires grâce à une conception de stockage native pour l'IA, offrant ainsi des capacités d'agent plus conviviales.

Quand des milliards d'utilisateurs affluent, le stockage d'objets traditionnel "ne suffit plus"

Imaginez que vous avez développé une application AIGC à succès. Chaque utilisateur génère et stocke de grandes quantités d'images, de vidéos et de fichiers temporaires. En tant que développeur, vous choisirez naturellement des services de stockage d'objets matures et évolutifs comme S3 et TOS. Mais le problème se pose : comment gérer les données d'un nombre massif d'utilisateurs ?

Dans son article de blog de 2022, S3, intitulé "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3", décrit deux approches : "utiliser un bucket S3 distinct pour chaque locataire" et "utiliser un bucket S3 partagé basé sur un préfixe d'isolement" :

• Créer un "bucket" distinct pour chaque utilisateur : cela est possible lorsque le nombre d'utilisateurs est faible, mais lorsque le nombre d'utilisateurs atteint des dizaines de milliers, voire des millions, le nombre de buckets explose rapidement, ce qui rend les coûts de gestion et les limitations de ressources insupportables. S3 offre un quota total de 10 000 buckets par région, mais pour les capacités d'IA populaires, 10 000 ne suffisent pas.

• Distinguer les utilisateurs par un "préfixe" dans le même bucket : c'est devenu la solution dominante. Par exemple, les fichiers de l'utilisateur A commencent tous par user-a/, et ceux de l'utilisateur B commencent par user-b/, comme la gestion des fichiers dans un dossier sur un ordinateur. Cependant, le stockage d'objets n'a pas de dossiers natifs, cette solution consiste à distinguer les multi-locataires via un "préfixe commun" (Prefix) dans un système de stockage "K-V".

Cette solution basée sur des "buckets" ou des "préfixes" est largement utilisée depuis dix ans. Mais elle présente les problèmes suivants :

• Isolement multi-locataire : les données de tous les utilisateurs sont mélangées dans le même bucket, et un accès anormalement fréquent d'un utilisateur peut affecter tous les autres utilisateurs, créant un "effet de voisinage". L'isolement des performances et l'isolement des pannes sont impossibles.

• Contrôle des autorisations : les stratégies d'autorisation complexes (IAM Policy) sont difficiles à maintenir et des erreurs de configuration peuvent facilement se produire, entraînant un accès accidentel aux données des utilisateurs, en particulier lorsqu'il est nécessaire d'interagir avec d'autres services cloud, le risque est plus grand.

• Clarté des coûts : il est difficile de savoir avec précision combien d'espace de stockage chaque utilisateur a consommé et combien de frais de trafic ont été générés. Lorsque vous souhaitez facturer les utilisateurs payants en fonction de leur utilisation, la facturation et la mesure deviennent confuses.Pourquoi ces besoins apparemment fondamentaux semblent-ils "lourds" à implémenter pour les développeurs d'Agents sur le stockage d'objets ? Une étude approfondie révèle que dans l'architecture cloud native actuelle, il existe un énorme vide entre le "stockage d'objets" (S3/TOS) et le "système de fichiers" traditionnel. L'essence du stockage d'objets (S3/TOS) est la "planéité". Sa conception initiale visait à stocker simplement des quantités massives de données, comme un immense entrepôt. Bien que sa capacité soit presque illimitée, sa structure logique est extrêmement simple. Il manque une gestion avancée native des répertoires, un contrôle précis des métadonnées et une véritable conscience des locataires. Lorsque les développeurs tentent de simuler un système de fichiers multi-locataires "tridimensionnel" sur un S3 "plat" en codant en dur des préfixes, nous utilisons en réalité un "stockage KV statique" pour prendre en charge une méthode d'accès aux fichiers d'application Agent avec une "sémantique de répertoire et une forte isolation". En d'autres termes, l'Agent doit consommer des tokens supplémentaires pour gérer les fichiers et contrôler la résolution des autorisations et de l'isolation multi-locataires. Ces tokens supplémentaires consommés indiquent tous que le service de stockage simple défini par S3 n'est pas assez simple pour l'Agent.

Le blog S3 de 2025, « Design patterns for multi-tenant access control on Amazon S3 », explique plus en détail S3 Access Point. Cela signifie que vous pouvez créer plusieurs points d'accès réseau virtuels et configurer une stratégie de point d'accès personnalisée pour chaque point d'accès, ce qui offre des solutions au niveau de la planification réseau pour les scénarios multi-locataires.

Agent Wonderland

Un développeur d'Agent idéal, lors du développement d'un AI Agent, peut construire un Agent entièrement serverless basé sur "Agent SDK + stockage + service MaaS" :

• L'Agent peut fonctionner de manière entièrement serverless

• Il est possible de construire un Agent en combinant les capacités de produits existantes via Vibe Coding

• Il suffit de maintenir le script python "ADK"

• Le stockage utilise le stockage d'objets

• La capacité d'IA utilise 豆包 (Doubao, un service d'IA)

• Théoriquement, il n'y a pas d'ECS ou d'autres produits de type instance

Dans le même temps, le stockage doit fournir les capacités suivantes :

• L'Agent peut avoir un stockage avec une sémantique d'objet (enregistrer des fichiers), fournir une capacité d'accès multi-locataire, en commençant par des millions et extensible à des centaines de millions

• L'Agent peut fournir un espace indépendant pour chaque utilisateur (entre plusieurs entreprises, les entreprises ou les uid peuvent avoir le même nom)

• L'Agent peut configurer directement la bande passante de chaque utilisateur et configurer la limite supérieure de la taille totale de l'objet utilisateur

• L'Agent peut facturer, surveiller et observer en fonction de l'utilisateur

• L'Agent peut configurer des stratégies d'accès pour les fichiers de chaque utilisateur

Agent Bucket : Injecter des gènes "natifs multi-locataires" dans AI Agent

Pour résoudre fondamentalement ce problème, nous avons proposé un nouveau paradigme de stockage d'objets : Agent Bucket. Son innovation principale est d'introduire une nouvelle couche de ressources natives entre les "buckets" et les "objets" traditionnels : les ensembles d'objets.

L'idée centrale de cette conception est extrêmement simple : associer un ObjectSet exclusif à chacun de vos utilisateurs finaux. Vous pouvez imaginer ObjectSet comme un "coffre-fort de données" ou un "espace personnel cloud" conçu pour chaque utilisateur. Il appartient logiquement à votre Bucket (développeur), mais physiquement et en termes de gestion, il a sa propre "personnalité" et son propre "cycle de vie" indépendants.Agent Bucket prend en charge jusqu'à 100 millions d'ObjectSet par bucket, ce qui signifie que vous pouvez servir sereinement des centaines de millions d'utilisateurs finaux, comme si chacun d'eux "vivait" dans son propre espace de stockage isolé, sans avoir à vous soucier de la gestion du stockage multi-tenant.

Conception d'ObjectSet - Des capacités conviviales pour les Agents

Dans Agent Bucket, ObjectSet n'est pas seulement un niveau supplémentaire, mais transforme également les besoins les plus épineux des scénarios multi-tenant en capacités natives prêtes à l'emploi. Une fois que la propriété des données est clairement définie au niveau d'ObjectSet, une série de capacités auparavant difficiles à réaliser deviennent naturelles.

• Isolation native : Au niveau d'ObjectSet, vous pouvez définir des limites de QPS, de bande passante et de quota de capacité indépendantes pour chaque utilisateur. L'expérience des utilisateurs payants peut être garantie, et le comportement anormal des utilisateurs gratuits n'affectera pas les autres. Il s'agit d'une véritable isolation du domaine de défaillance, empêchant les "voisins" de s'interférer mutuellement.

• Autorisations natives : Chaque ObjectSet peut avoir un nom de domaine indépendant. Cela signifie que vous pouvez donner à l'utilisateur A une adresse d'accès exclusive user-a.yourapp.com, au lieu d'exposer le nom de domaine de l'ensemble du bucket. Plus ingénieux encore, la conception à "deux verrous" : le premier verrou est un jeton d'accès temporaire (STS) émis par le fournisseur de services cloud, qui contrôle les autorisations d'accès au niveau de l'application ; le deuxième verrou est le nom de domaine indépendant d'ObjectSet, qui verrouille les demandes d'accès dans l'espace de données de l'utilisateur lui-même au niveau du réseau. Cela améliore considérablement la sécurité des données.

• Surveillance native : Sur le tableau de bord de surveillance, vous ne pouvez plus voir uniquement les données globales de l'ensemble du bucket. Vous pouvez décomposer les graphiques de surveillance par ObjectSet, en observant clairement quel utilisateur final effectue un grand nombre d'accès, afin de prendre des décisions d'exploitation et d'optimisation précises.

• Des capacités natives décentralisées : Les stratégies qui ne pouvaient être définies qu'au niveau du bucket dans le passé peuvent désormais être décentralisées pour chaque utilisateur. Vous pouvez définir différents cycles de vie des données pour différents niveaux d'utilisateurs, ou utiliser différentes clés de chiffrement pour chaque ObjectSet, afin de réaliser une gestion des données plus granulaire et plus sécurisée.

• Mesure native : Vous voulez savoir combien d'espace de stockage chaque utilisateur utilise ? Vous voulez répartir précisément les coûts de stockage sur chaque utilisateur ? C'est désormais un jeu d'enfant. Agent Bucket calcule automatiquement la capacité et l'utilisation de chaque ObjectSet, ce qui rend votre facturation et votre répartition claires et transparentes.

• Facturation native : Les développeurs peuvent facilement mettre en œuvre la répartition des coûts, en répercutant précisément les coûts générés par le stockage sur chaque utilisateur final. Par exemple, facturer différemment en fonction du ratio de coûts réels générés par les différents utilisateurs A, B et C, afin de fournir un support de données pour la commercialisation d'Agent.

• Limite de capacité native : Afin de contrôler les coûts d'exploitation d'Agent, vous pouvez définir un Quota (limite de capacité) pour chaque ObjectSet. Une fois la valeur prédéfinie atteinte, le système empêchera cet utilisateur de générer de nouveaux fichiers, évitant ainsi l'utilisation abusive des ressources dans les scénarios multi-tenant à la source.

• Intelligence native : Agent Bucket permet à Agent de sortir des limites du simple "stockage et accès" de fichiers traditionnels, en donnant à Object une intelligence native, soutenant plus efficacement le développement unique d'Agent. ObjectSet peut activer l'indexation intelligente en un clic, fournissant à Agent des capacités de questions-réponses multimodales natives et conviviales, remplaçant les opérations mécaniques traditionnelles d'Object CRUD ; il prend même en charge l'activation du mode Agentself en un clic, reliant les vecteurs, les connaissances, les modèles et les prompts, révélant directement les fonctions d'Agent secondaires scénarisées, permettant aux développeurs d'Agent de niveau supérieur de se concentrer sur la création de flux de travail métier principaux, libérant pleinement l'efficacité de la monétisation intelligente.

Les défis techniques posés par l'explosion de la taille des applications

En introduisant le concept natif d'ObjectSet, Agent Bucket offre aux développeurs d'applications un moyen élégant et efficace de gérer les données de centaines de millions d'utilisateurs finaux. Les actifs numériques de chaque utilisateur sont stockés en toute sécurité dans leur ObjectSet exclusif, réalisant naturellement l'isolation, la facturation et la gestion des quotas.

Avec l'expansion rapide de la taille des applications, la complexité de la gestion d'un grand nombre de Set, la difficulté d'isolation et les goulots d'étranglement physiques deviennent tous apparents :

• Problème de gestion hiérarchique d'un grand nombre d'utilisateurs : Lors de la gestion différenciée des ressources et des fonctionnalités d'un grand nombre d'utilisateurs de différents niveaux, l'application doit concevoir et mettre en œuvre ses propres métadonnées de classification des utilisateurs, et associer les commutateurs de fonctionnalités de stockage d'objets. Aider les développeurs à gérer élégamment la classification des utilisateurs sur le concept natif de Set est important pour accélérer le déploiement des applications.- Goulot d'étranglement de la capacité d'un seul cluster : Bien que l'Agent Bucket puisse être étendu logiquement à l'infini, ses métadonnées sont stockées par défaut dans un seul cluster physique. Lorsque le nombre total d'objets dans le bucket atteint des centaines de milliards, voire des milliers de milliards, la capacité physique d'un seul cluster devient une limite insurmontable.

• Problèmes de partage des points d'accès : La diversité des activités de l'Agent et le grand nombre d'utilisateurs entraînent des risques de sécurité et un rayon d'explosion plus importants pour le point d'accès lui-même. Comment effectuer une planification dynamique en fonction des différences entre un grand nombre d'activités et d'utilisateurs, et réaliser une sécurité, une isolation et une accélération différenciées devient un défi.

Set Tagging : Gestion hiérarchisée des utilisateurs par étiquetage

ObjectSet fournit une méthode de gestion par étiquetage native, permettant aux développeurs d'Agent d'utiliser simplement la capacité de set tagging pour réaliser la gouvernance hiérarchisée des utilisateurs ; les développeurs peuvent attribuer un tag à chaque niveau d'utilisateur défini, et activer différents quotas et caractéristiques pour chaque tag. Tous les ObjectSet portant ce tag appliqueront les quotas et caractéristiques correspondants. Prenons l'exemple de trois niveaux, V1, V2 et V3 :

• V1 : Niveau par défaut, utilisateurs gratuits, tag par défaut pour tous les ObjectSet, peut être configuré pour stocker jusqu'à 1GiB de données, la distribution publique ne peut pas dépasser une bande passante de 100mbps, la vitesse de téléchargement à flux unique est contrôlée à 1mbps ;

• V2 : Membres payants de niveau débutant, configurés pour stocker jusqu'à 10GiB de données, la distribution publique ne peut pas dépasser une bande passante de 10gbps, la vitesse de téléchargement à flux unique est contrôlée à 10mbps ;

• V3 : Membres payants de niveau supérieur, en plus de fournir des quotas de stockage et de distribution publique plus importants, prennent également en charge la configuration pour activer l'accélération supplémentaire du réseau public faible et la capacité d'accélération des supports haute performance ;

Les développeurs d'Agent peuvent utiliser de manière flexible le tagging V1/V2/V3 pour gérer les ressources et les fonctionnalités à valeur ajoutée que ces utilisateurs peuvent utiliser, en fonction des différents cycles de développement des différents utilisateurs.

Set Slice : Isolation native des données de masse des utilisateurs

Lorsqu'un Agent Bucket contient des centaines de millions de Set et que le nombre d'objets atteint des centaines de milliards, voire des milliers de milliards, le fait que "toutes les métadonnées d'un seul Bucket soient concentrées dans un seul cluster KV" présente un double risque de capacité et de performance.

Set Slice propose une idée de "non-démantèlement logique, démantèlement physique" :

• D'un point de vue logique, vous ne gérez toujours qu'un seul Agent Bucket.

• Physiquement, les métadonnées sont divisées en plusieurs Slice (tranches) en fonction de la plage de Set et des noms d'objets dans le Set. Chaque Slice peut être stocké sur différents clusters, l'isolation naturelle multi-Set et l'extension horizontale d'un seul Set.

Set Slice est une extension et une garantie supplémentaires de la capacité ObjectSet. Il résout fondamentalement le problème de l'extension infinie de la capacité physique, tout en assurant la stabilité et la cohérence du modèle de gestion ObjectSet de la couche supérieure.

• Stabilité des limites de gestion : Même si les données d'un Agent Bucket couvrent plusieurs clusters physiques, ObjectSet reste la seule unité de base pour les autorisations, les quotas, la facturation et la surveillance. Les stratégies configurées par les développeurs pour ObjectSet (telles que le contrôle d'accès, la limite de capacité) prendront automatiquement effet sur tous les Slices associés, sans se soucier de la distribution des données sous-jacentes.

• Un seul Set peut être étendu linéairement : Lorsque le volume de données d'un certain ObjectSet augmente rapidement, ses données seront naturellement distribuées sur plusieurs Slices. Avec l'expansion de l'ensemble du cluster, la capacité de cet ObjectSet augmente également de manière transparente et linéaire, et les développeurs n'ont pas besoin d'effectuer d'opérations destructrices telles que le démantèlement ou la migration de cet ObjectSet lui-même.

• Isolation des ressources inter-Set : En distribuant des objets de différentes plages sur différents clusters physiques, SetSlice réalise une isolation des ressources de dimension supérieure. Combiné à la gestion des quotas d'ObjectSet, il peut efficacement empêcher la croissance des données d'un certain ObjectSet "super grand utilisateur" d'empiéter sur toutes les ressources d'un seul cluster, affectant ainsi la stabilité des autres ObjectSet, rendant le risque de capacité global contrôlable.- Unité logique et compatibilité : Pour les entreprises et les développeurs, quel que soit le nombre de Slices sous-jacents, ils sont toujours confrontés à un Agent Bucket logiquement unifié. Toutes les méthodes d'opération pour les buckets, ObjectSets et objets restent inchangées, réalisant une transparence totale de l'expansion physique pour les applications de niveau supérieur.

Set AccessPoint : Isoler le point d'accès de chaque utilisateur

Agent Bucket prend en charge l'ouverture de points d'accès indépendants (noms de domaine indépendants) pour chaque ObjectSet, et l'extension de capacités de sécurité, d'isolation et d'accélération différenciées sur les points d'accès. Le système doit donc prendre en charge la planification de points d'accès indépendants à l'échelle du milliard et les capacités de configuration différenciées.

Nom de domaine d'accès indépendant {$apid}.tos-objectset-ap.volces.com : Double protection de sécurité

• Premier niveau Obscurity (Occultation) : Sous-domaine indépendant By User/ObjectSet, hachage à haute entropie apid, probabilité de collision extrêmement faible, il est impossible de deviner et d'énumérer l'entrée d'un utilisateur spécifique à partir du nom de domaine d'accès ;

• Deuxième niveau Containment (Confinement) : Les développeurs d'Agent utilisent sts pour distribuer les autorisations d'accès au niveau ObjectSet, même si sts est divulgué, il est possible de contrôler que sa portée d'accès soit limitée à une période de validité limitée d'un certain ObjectSet ;

Système de planification heuristique : Calcul de la stratégie de planification de noms de domaine à l'échelle du milliard

• Stratégie d'accès différenciée By user/ObjectSet:tag

• Multi user/ObjectSet automatiquement dispersés sur différents points d'entrée publics, le nombre d'utilisateurs affectés par une défaillance d'un seul point d'entrée est contrôlé

• Planification élastique à l'échelle de la région, la défaillance/surcharge d'un seul point d'entrée est automatiquement complétée par le déplacement de la boîte de trafic

• User de type distribution d'accélération publique, marquer la balise d'accélération de transmission publique, planifier automatiquement l'entrée d'accélération

• User de type risque public, marquer la balise de risque, planifier automatiquement l'entrée d'isolation publique et réduire le quota de bande passante publique

• User de type inter-domaine intranet, marquer la balise inter-domaine, planifier automatiquement le chemin d'accélération de ligne dédiée intranet

• User d'accélérateur local, marquer la balise d'accélérateur, monter automatiquement l'accélérateur local

De l'assistant de programmation au disque cloud AI, les possibilités infinies d'Agent Bucket

Agent Bucket fournit une solution complète pour Agent, et les scénarios d'application de la conception ObjectSet vont bien au-delà. Il peut être facilement étendu à toutes les applications qui doivent fournir des services à un grand nombre d'utilisateurs finaux :

• Dépôt de code : Dans le passé, lorsque les entreprises ou les particuliers hébergeaient du code dans le cloud, ils devaient souvent construire une couche de "système de locataire" au-dessus du stockage d'objets pour réaliser l'isolation des comptes et le contrôle des autorisations. Maintenant, un ObjectSet exclusif peut être attribué à chaque développeur pour collecter de manière unifiée les dépôts de code, les produits de construction et les dépendances. Agent Skills s'adapte également naturellement à ObjectSet. Le téléchargement, le téléchargement et la distribution de Skills fournissent une forte isolation via ObjectSet, évitant ainsi les interférences de voisinage lors de l'exécution d'Agent.

• Album photo/disque réseau d'entreprise : Les services traditionnels d'album photo ou de disque réseau mélangent souvent les photos de tous les utilisateurs dans le même bucket et distinguent les utilisateurs par préfixe, ce qui est non seulement complexe à gérer, mais également susceptible de provoquer un "effet de voisinage". Basé sur ObjectSet, les photos et vidéos de chaque utilisateur sont placées dans leurs propres Sets, les pics d'accès n'interfèrent pas les uns avec les autres, et il est également possible de définir des limites de capacité, des stratégies de sauvegarde et des méthodes de cryptage par utilisateur, réalisant ainsi véritablement "chacun a un album photo cloud sécurisé et contrôlable".

• Entrepôt de données Hadoop : Dans l'entrepôt de données d'entreprise, différentes lignes de métier et différentes bases de données partagent souvent des ressources sur le même stockage sous-jacent. En mappant chaque base de données à un ObjectSet, les entreprises peuvent réaliser l'isolation et le contrôle des quotas par base de données sur un stockage unifié. En particulier, ObjectSet fournit une couche d'autorisations supplémentaire sur TOS, et fournit l'isolation et le contrôle des autorisations pour les bases de données et les tables stockées sur TOS sans modifier le Proton existant sur TOS. // Traduction des commentaires et explications - Plateforme d'hébergement de modèles : Dans les scénarios d'hébergement de grands modèles, chaque modèle n'est pas seulement volumineux, mais peut également correspondre à différentes versions, poids et configurations d'inférence. La création d'un ObjectSet pour chaque modèle permet d'empaqueter et d'héberger les poids du modèle, le Tokenizer, les fichiers de configuration et les données d'évaluation associées dans le même espace. L'équipe d'exploitation peut définir des stratégies de chiffrement, des stratégies de sauvegarde et un contrôle de la bande passante différenciés pour différents modèles. En même temps, la capacité de mesure native permet de comptabiliser le coût d'utilisation réel de chaque modèle, fournissant ainsi une base pour la facturation et la planification des ressources par dimension de modèle.

• Service SaaS de données : Les plateformes de distribution de données destinées à un grand nombre d'utilisateurs finaux doivent souvent se connecter simultanément à de nombreux fournisseurs de données, en veillant à ce que les limites de données de chaque partie soient claires et en évitant le risque de performance "un grand seau qui ralentit tout le monde". Grâce à Agent Bucket, chaque fournisseur de données peut avoir son propre ObjectSet, gérant de manière unifiée les données brutes et les résultats de traitement. Grâce à un nom de domaine et une bande passante indépendants, ainsi qu'à un quota de QPS, différents fournisseurs peuvent bénéficier d'une garantie de service et d'une limitation de débit différenciées, réalisant ainsi une infrastructure de distribution de données "une plateforme, plusieurs fournisseurs, isolation mutuelle et collaboration contrôlable".

Reference:

• https://aws.amazon.com/cn/blogs/apn/partitioning-and-isolating-multi-tenant-saas-data-with-amazon-s3/

• https://aws.amazon.com/cn/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/