Agent Bucket : un bucket de stockage natif pour agents à l’échelle de milliers de milliards

Aujourd’hui, alors que les agents IA émergent comme des champignons après la pluie, les développeurs créent à une vitesse sans précédent des applications intelligentes débordantes d’imagination. Des assistants de programmation qui vous aident à é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 prêts à vous aider, les agents redéfinissent notre façon d’interagir avec le monde numérique. Derrière cette vague, un consensus se dégage de plus en plus clairement : grâce à une architecture sans serveur (comme Lambda), aux grands modèles linguistiques (LLM) et au stockage en nuage (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 » à « convivial », les développeurs d’agents doivent encore surmonter des difficultés pour passer du statut de « jouet » à celui d’« application de niveau production ». À mesure que l’activité s’étend à un nombre massif d’utilisateurs, les développeurs doivent faire face à un défi extrêmement complexe : comment créer une solution de stockage complète pour un nombre massif d’utilisateurs finaux sur le stockage d’objets ? Pour la plupart des développeurs, il ne s’agit pas seulement d’un seuil technologique, mais aussi d’un fossé qui entrave la distribution à grande échelle des agents. Agent Bucket vise à simplifier complètement le processus de création de systèmes multi-locataires grâce à une conception de stockage native de l’IA, offrant ainsi une capacité d’agent plus conviviale.

Lorsque des centaines de millions d’utilisateurs affluent, le stockage d’objets traditionnel « ne suffit plus »

Imaginez que vous ayez développé une application AIGC à succès. Chaque utilisateur générera et stockera un grand nombre 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 voici le problème : comment gérer les données d’un nombre massif d’utilisateurs ?

Le blogue de S3 de 2022, « Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3 », décrit deux méthodes : « Utiliser des buckets S3 distincts pour chaque locataire » et « Partager des buckets S3 isolés par préfixe » :

• 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, et les coûts de gestion et les limites de ressources deviennent insupportables. S3 offre un quota total de 10 000 buckets pour l’ensemble de la région, mais pour les capacités d’IA populaires, 10 000 buckets sont loin d’être suffisants.

• Distinguer les utilisateurs par « préfixe » dans le même bucket : c’est devenu la solution dominante. Par exemple, les fichiers de l’utilisateur A commencent par user-a/, et ceux de l’utilisateur B commencent par user-b/, comme la gestion des fichiers avec des dossiers sur un ordinateur. Toutefois, le stockage d’objets n’a pas de dossiers natifs, cette solution consiste à distinguer les multi-locataires par « préfixe commun » dans le 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 une visite anormale à haute fréquence d’un utilisateur peut affecter tous les autres utilisateurs, produisant un « effet de voisinage ». L’isolement des performances et l’isolement des pannes sont hors de question.

• Contrôle des autorisations : les stratégies d’autorisations complexes (stratégie IAM) sont difficiles à maintenir, et il est facile de faire des erreurs de configuration, ce qui entraîne un accès accidentel aux données des utilisateurs, en particulier lorsqu’il est nécessaire d’interagir avec d’autres services en nuage, le risque est plus grand.

• Clarté des coûts : il est difficile de savoir exactement combien d’espace de stockage chaque utilisateur consomme et combien de frais de trafic sont générés. Lorsque vous souhaitez facturer les utilisateurs payants en fonction de leur utilisation, la facturation et la mesure deviennent un compte confus. Pourquoi ces besoins apparemment fondamentaux semblent-ils si "lourds" à implémenter pour les développeurs d'Agents sur le stockage d'objets ? Une exploration approfondie révèle qu'il existe un vaste vide entre le "stockage d'objets" S3 et les "systèmes de fichiers" traditionnels dans l'architecture cloud native actuelle. 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 des répertoires native, un contrôle granulaire 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 sémantique de répertoire et 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 consommations de tokens supplémentaires indiquent toutes 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 les S3 Access Points. Cela signifie qu'il est possible de créer plusieurs points d'accès réseau virtuels et de 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 l'ordonnancement réseau pour les scénarios multi-locataires.

Agent Wonderland

Un développeur d'Agent idéal, lors du développement d'un Agent IA, 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 existants via Vibe Coding

• Il suffit de maintenir le script python "ADK"

• Le stockage utilise le stockage d'objets

• Les capacités d'IA utilisent Doubao

• 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 (sauvegarde des fichiers), fournir une capacité d'accès multi-locataires, en commençant par des millions et extensible à des milliards

• 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, configurer la limite supérieure de la taille totale des objets 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 "multi-locataires natifs" dans l'Agent IA

Pour résoudre fondamentalement ce problème, nous proposons un nouveau paradigme de stockage d'objets : Agent Bucket. Son innovation principale est l'introduction d'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" spécialement conçu pour chaque utilisateur. Il appartient logiquement à votre Bucket (développeur), mais physiquement et en termes de gestion, il possède sa propre "personnalité" et son propre "cycle de vie" indépendants.Agent Bucket prend en charge 100 millions d'ObjectSet par bucket, ce qui signifie que vous pouvez facilement servir des centaines de millions d'utilisateurs finaux, comme si chaque utilisateur final "vivait" dans son propre espace de stockage indépendant, sans avoir à vous soucier de la gestion du stockage multi-tenant.

Conception d'ObjectSet - 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 qui étaient difficiles à réaliser dans le passé deviennent naturelles.

• Isolement natif : 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'un véritable isolement 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 de stockage. Plus ingénieux encore, la conception à "deux verrous" : le premier verrou est un jeton d'accès temporaire (STS) délivré 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 depuis le 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 comprenant 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 politiques qui ne pouvaient être définies qu'au niveau du bucket dans le passé peuvent maintenant ê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 occupe ? Vous voulez répartir avec précision les coûts de stockage sur chaque utilisateur ? C'est maintenant facile. Agent Bucket calculera automatiquement la capacité et l'utilisation de chaque ObjectSet, ce qui rendra votre facturation et votre répartition claires et transparentes.

• Facturation native : Les développeurs peuvent facilement réaliser la répartition des coûts et répercuter avec précision les coûts de 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 limitera l'utilisateur à continuer à générer de nouveaux fichiers, évitant ainsi l'utilisation abusive des ressources dans les scénarios multi-tenant.

• Intelligence native : Agent Bucket permet à Agent de sortir des limites du simple "stockage et récupération" de fichiers traditionnels, en donnant à Object une intelligence native, et en supportant plus efficacement le développement unique d'Agent. ObjectSet peut activer l'indexation intelligente en un clic, fournissant à Agent une capacité de questions-réponses multimodales conviviales et natives, remplaçant les opérations mécaniques traditionnelles d'Object CRUD ; il prend même en charge l'activation en un clic du mode Agentself, reliant les vecteurs, les connaissances, les modèles et les prompts, exposant 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 d'activité principaux, libérant pleinement l'efficacité de la monétisation intelligente.

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

En introduisant le concept natif d'ObjectSet, Agent Bucket fournit 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'isolement, la facturation et la gestion des quotas.

Avec l'expansion rapide de l'échelle des applications, la complexité de la gestion des ensembles massifs, la difficulté de l'isolement et les goulots d'étranglement physiques deviennent tous apparents :

• Problème de gestion hiérarchique des utilisateurs massifs : Lorsque l'application gère de manière différenciée les ressources et les caractéristiques d'un grand nombre d'utilisateurs de différents niveaux, elle doit concevoir et mettre en œuvre ses propres métadonnées de classification des utilisateurs, et associer les commutateurs de caractéristiques 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 la mise en œuvre de l'application.Les défis de la gestion des données à l'échelle d'un agent sont les suivants :

• 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 présentent des risques de sécurité et un rayon d'explosion plus importants pour le point d'accès lui-même. Il devient difficile de réaliser une planification dynamique basée sur les différences entre un grand nombre d'activités et d'utilisateurs, et de réaliser des capacités de sécurité, d'isolation et d'accélération différenciées.

Set Tagging : Gestion par étiquettes et classification des utilisateurs

ObjectSet fournit une méthode de gestion native par étiquettes, permettant aux développeurs d'Agent d'utiliser facilement la capacité de set tagging pour réaliser la gouvernance et la classification des utilisateurs. Les développeurs peuvent attribuer une étiquette à chaque niveau d'utilisateur défini et activer différents quotas et fonctionnalités pour chaque étiquette. Tous les ObjectSet portant cette étiquette appliqueront les quotas et fonctionnalités correspondants. Prenons l'exemple de trois niveaux : V1, V2 et V3 :

• V1 : Niveau par défaut, utilisateurs gratuits, étiquette par défaut pour tous les ObjectSet, peut être configuré pour stocker jusqu'à 1 Gio de données, la distribution sur le réseau public ne peut pas dépasser 100 mbps de bande passante, et la vitesse de téléchargement à flux unique est contrôlée à 1 mbps ;

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

• V3 : Membres payants de niveau supérieur, en plus de fournir des quotas de stockage et de distribution sur le réseau public plus importants, prennent également en charge la configuration pour activer l'accélération supplémentaire du réseau public faible et les capacités 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 d'ensembles (Sets) 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 offre une approche de "non-découpage logique, découpage 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 Slices (tranches) en fonction de la plage de l'ensemble (Set) et des noms d'objets dans l'ensemble. Chaque Slice peut être stocké sur différents clusters, avec une isolation naturelle entre plusieurs ensembles et une extension horizontale d'un seul ensemble.

Set Slice est une extension et une garantie supplémentaires des capacités d'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 et les limites de capacité) prennent automatiquement effet sur tous les Slices concernés, sans qu'il soit nécessaire de 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 sont 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, sans que les développeurs aient besoin d'effectuer des opérations destructrices telles que le découpage ou la migration de cet ObjectSet lui-même.

• Isolation des ressources entre les Sets : En distribuant différents ensembles d'objets 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 ObjectSet "super grand utilisateur" d'empiéter sur toutes les ressources d'un seul cluster, affectant ainsi la stabilité des autres ObjectSet, rendant ainsi le risque de capacité global contrôlable. - Unité et compatibilité logiques : 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, les ObjectSets et les objets restent inchangées, réalisant une transparence totale de l'extension 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'activation de points d'accès indépendants (noms de domaine indépendants) pour chaque ObjectSet, et étend les 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 prendre en charge la planification de points d'accès indépendants au niveau 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 : protection de sécurité à deux niveaux

• Premier niveau Obscurity (obscurité) : sous-domaine indépendant par utilisateur/ObjectSet, hachage à haute entropie apid, probabilité de collision extrêmement faible, il est impossible de deviner et d'énumérer le point d'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 peut contrôler sa portée d'accès limitée à une certaine période de validité d'ObjectSet ;

Système de planification heuristique : calcul de la stratégie de planification de noms de domaine au niveau du milliard

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

• Plusieurs utilisateurs/ObjectSets sont automatiquement dispersés dans différents points d'entrée publics, le nombre d'utilisateurs affectés par une seule panne de point d'entrée est contrôlé

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

• Les utilisateurs de distribution d'accélération publique, marquent la balise d'accélération de la transmission publique et planifient automatiquement le point d'entrée d'accélération

• Les utilisateurs publics à risque, marquent la balise de risque, planifient automatiquement le point d'entrée d'isolement public et réduisent le quota de bande passante publique

• Les utilisateurs interdomaines du réseau interne, marquent la balise interdomaine et planifient automatiquement le chemin d'accélération de la ligne dédiée du réseau interne

• Les utilisateurs d'accélérateur local, marquent la balise d'accélérateur et montent automatiquement l'accélérateur local

Du programmation assistée 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 d'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 le dépôt 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 sont fournis via ObjectSet pour fournir une forte isolation, évitant ainsi les interférences de voisinage lors de l'exécution d'Agent.

• Disque cloud d'album photo d'entreprise : les services traditionnels d'album photo ou de disque cloud 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 sujet à "l'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 la limite de capacité, la stratégie de sauvegarde et la méthode de cryptage peuvent être définies par utilisateur, réalisant ainsi véritablement "chaque personne 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, fournissant une isolation et un contrôle des autorisations pour les bases de données et les tables stockées sur TOS sans modifier Proton existant sur TOS. - 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, pondérations et configurations d'inférence. La création d'un ObjectSet pour chaque modèle permet d'empaqueter et d'héberger les pondérations 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, grâce aux capacités de mesure natives, il est possible de comptabiliser le coût d'utilisation réel de chaque modèle, ce qui constitue une base pour la facturation et la planification des ressources par 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 des 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 du traitement. Ensuite, grâce à un nom de domaine et une bande passante indépendants, ainsi qu'à des quotas de QPS, il est possible de fournir une garantie de service et une limitation de débit différenciées pour différents fournisseurs, réalisant ainsi une infrastructure de distribution de données "une plateforme, plusieurs fournisseurs, isolés les uns des autres mais collaborant de manière contrôlée".

Référence :

• 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/