Agent Bucket: Agent-native lagringsbeholder for billioner av objekter

I dagens verden, hvor AI-agenter dukker opp som paddehatter etter regn, bygger utviklere fantasifulle, intelligente applikasjoner i et enestående tempo. Fra programmeringsassistenter som hjelper deg med å skrive kode, til kreative verktøy som genererer en hel film fra en enkelt setning, til personlige, intelligente assistenter som alltid er klare, omformer agenter måten vi samhandler med den digitale verden på. Bak denne bølgen er det en økende enighet: Ved hjelp av Serverless-arkitektur (som Lambda), store språkmodeller (LLM) og skylagring (som S3, TOS), kombinert med Vibe Coding, kan hvem som helst raskt sette opp sin egen AI-agent på 30 minutter.

Fra å være "brukbar" til å være "god å bruke", må Agent-utviklere fortsatt overvinne vanskeligheter i overgangen fra "leketøy" til "produksjonsklar applikasjon". Etter hvert som virksomheten vokser til et stort antall brukere, må utviklere møte en ekstremt kompleks utfordring: Hvordan bygge en komplett lagringsløsning for et stort antall sluttbrukere på objektlagring? For de fleste utviklere er dette ikke bare en teknisk terskel, men også en kløft som hindrer storskala distribusjon av agenter. Agent Bucket har som mål å forenkle byggeprosessen for flerleiersystemer fullstendig gjennom AI-native lagringsdesign, og tilby mer brukervennlige Agent-muligheter.

Når milliarder av brukere strømmer til, er tradisjonell objektlagring "ikke nok"

Tenk deg at du har utviklet en populær AIGC-applikasjon. Hver bruker vil generere og lagre et stort antall bilder, videoer og midlertidige filer. Som utvikler vil du naturligvis velge modne, skalerbare objektlagringstjenester som S3 og TOS. Men her er problemet: Hvordan administrere data for et stort antall brukere?

S3-bloggen fra 2022, 《Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3》, beskriver to metoder, "bruk av separate S3-bøtter for hver leietaker" og "delt S3-bøtte basert på prefiks-isolasjon":

• Opprett en separat "bøtte" (Bucket) for hver bruker: Dette er mulig når det er få brukere, men når antallet brukere vokser til titusenvis eller millioner, vil antallet bøtter eksplodere raskt, og administrasjonskostnadene og ressursbegrensningene vil bli uutholdelige. S3 tilbyr en total bøttekvote på 10 000 for hele regionen, men for populære AI-muligheter er 10 000 langt fra nok.

• Bruk "prefiks" for å skille brukere i samme bøtte: Dette har blitt den vanlige løsningen. For eksempel vil filene til bruker A begynne med user-a/, mens filene til bruker B vil begynne med user-b/, akkurat som å bruke mapper til å administrere filer på en datamaskin. Objektlagring har imidlertid ingen native mapper, og denne løsningen skiller flere leietakere gjennom "felles prefiks" (Prefix) i et "K-V"-lagringssystem.

Denne "bøtte"- eller "prefiks"-baserte løsningen har vært mye brukt de siste ti årene. Men det er følgende problemer:

• Flerleierisolasjon: Dataene til alle brukere er blandet i samme bøtte, og en brukers unormale høyfrekvente tilgang kan påvirke alle andre brukere, og skape en "naboeffekt". Ytelsesisolasjon og feilisolasjon er umulig.

• Tillatelseskontroll: Komplekse tillatelsespolicyer (IAM Policy) er vanskelige å vedlikeholde, og det er lett å gjøre konfigurasjonsfeil, noe som fører til at brukerdata blir utilsiktet tilgjengelige, spesielt når det er nødvendig å samhandle med andre skytjenester, er risikoen større.

• Kostnadsklarhet: Det er vanskelig å vite nøyaktig hvor mye lagringsplass hver bruker har brukt, og hvor mye trafikkostnader de har generert. Når du vil belaste betalende brukere basert på bruk, blir fakturering og måling et rot.Objektlagring (S3/TOS) er i bunn og grunn "flat", og designet for enkel lagring av massive mengder data, som et stort lager. Selv om kapasiteten er nesten ubegrenset, er den logiske strukturen ekstremt enkel. Den mangler innebygd avansert katalogadministrasjon, finkornet metadata-kontroll og ekte leietakerbevissthet. Når utviklere prøver å simulere et "tredimensjonalt" filsystem for flere leietakere på den "flate" S3 ved å hardkode prefikser, bruker vi faktisk en "statisk KV-lagring" for å bære en "katalogsemantikk, sterkt isolert" Agent-applikasjons filtilgangsmetode. Det vil si at Agent må bruke ekstra tokens for å administrere filer og kontrollere og løse tillatelser og isolasjon for flere leietakere. Disse ekstra token-kostnadene indikerer alle at S3s definerte enkle lagringstjeneste ikke er enkel nok for Agent.

S3-bloggen fra 2025, "Design patterns for multi-tenant access control on Amazon S3", utdyper S3 Access Point ytterligere. Dette betyr at du kan opprette flere virtuelle nettverkstilgangspunkter og konfigurere en tilpasset tilgangspunktpolicy for hvert tilgangspunkt, som gir noen løsninger for scenarier med flere leietakere på nettverksplanleggingsnivå.

Agent Wonderland

En ideell Agent-utvikler kan, når han utvikler AI Agent, bygge en fullstendig serverløs Agent basert på "Agent SDK + lagring + MaaS-tjenester":

• Agent kan kjøre fullstendig serverløst

• Kan bruke Vibe Coding til å kombinere eksisterende produktegenskaper for å bygge Agent

• Trenger bare å vedlikeholde "ADK" python-skript

• Lagring bruker objektlagring

• AI-evner bruker Doubao

• Teoretisk sett ingen ECS eller andre instansbaserte produkter

Samtidig må lagringen tilby følgende funksjoner:

• Agent kan ha en objektsemantisk lagring (lagre filer), gi tilgang for flere leietakere, starte med millioner og kan utvides til milliarder

• Agent kan gi hver bruker en uavhengig plass (mellom flere tjenester kan tjenester eller uid ha samme navn)

• Agent kan direkte konfigurere båndbredden for hver bruker og konfigurere den totale størrelsesgrensen for brukerobjekter

• Agent kan fakturere, overvåke og observere basert på bruker

• Agent kan konfigurere tilgangspolicyer for hver brukers filer

Agent Bucket: Injiserer "multi-tenant native" gener i AI Agent

For å løse dette problemet fundamentalt, foreslår vi et nytt objektlagringsparadigme – Agent Bucket. Dens kjerneinnovasjon er introduksjonen av et nytt, innebygd ressursnivå mellom den tradisjonelle "bucket" og "objekt": objektsett.

Kjerneideen bak dette designet er ekstremt enkel: match hvert av dine sluttbrukere med et eksklusivt ObjectSet. Du kan tenke på ObjectSet som en "databoks" eller "personlig skyrom" designet for hver bruker. Det tilhører logisk sett din (utviklerens) Bucket, men fysisk og administrativt har det sin egen uavhengige "personlighet" og "livssyklus".Agent Bucket støtter 100 millioner ObjectSet per bøtte, noe som betyr at du enkelt kan betjene hundrevis av millioner av sluttbrukere, som om hver sluttbruker "lever" i sitt eget uavhengige lagringsområde, uten å måtte bekymre deg for administrasjon av lagring for flere leietakere.

ObjectSet-design – Agent-vennlig funksjonalitet

I Agent Bucket er ObjectSet mer enn bare et ekstra nivå; det gjør de mest vanskelige kravene i scenarier med flere leietakere til innebygde, brukervennlige funksjoner. Når dataeierskapet er tydelig definert på ObjectSet-nivå, blir en rekke funksjoner som tidligere var vanskelige å implementere, enkle å realisere.

• Innebygd isolasjon: På ObjectSet-nivå kan du angi uavhengige QPS-, båndbreddebegrensninger og kapasitetskvoter for hver bruker. Opplevelsen for betalende brukere kan garanteres, og unormal oppførsel fra gratisbrukere vil ikke påvirke andre. Dette er ekte feildomeneisolasjon, som hindrer "naboer" i å forstyrre hverandre.

• Innebygde tillatelser: Hver ObjectSet kan ha et uavhengig domene. Dette betyr at du kan gi bruker A en eksklusiv tilgangsadresse som user-a.yourapp.com, i stedet for å eksponere hele lagringsbøttens domene. Enda smartere er designet med "to låser": Den første låsen er en midlertidig tilgangslegitimasjon (STS) utstedt av skyleverandøren, som kontrollerer tilgangstillatelser på applikasjonsnivå; den andre låsen er ObjectSets uavhengige domene, som låser tilgangsforespørsler til brukerens eget dataområde fra nettverksnivå. Dette forbedrer datasikkerheten betydelig.

• Innebygd overvåking: På overvåkingsdashbordet kan du ikke lenger bare se en oversikt over hele bøtten. Du kan bryte ned overvåkingsdiagrammer etter ObjectSet, og tydelig se hvilken sluttbruker som utfører store mengder tilgang, og dermed ta presise drifts- og optimaliseringsbeslutninger.

• Innebygd funksjonalitetsnedbrytning: Retningslinjer som tidligere bare kunne settes på bøttenivå, kan nå brytes ned til hver bruker. Du kan angi forskjellige datalivssykluser for forskjellige nivåer av brukere, eller bruke forskjellige krypteringsnøkler for hver ObjectSet, for å oppnå mer detaljert og sikker datastyring.

• Innebygd måling: Vil du vite hvor mye lagringsplass hver bruker bruker? Vil du fordele lagringskostnadene nøyaktig til hver bruker? Nå er det enkelt. Agent Bucket vil automatisk beregne kapasiteten og bruken av hver ObjectSet for deg, slik at fakturering og deling er tydelig.

• Innebygd fakturering: Utviklere kan enkelt implementere kostnadsdeling og nøyaktig spore kostnadene som genereres av lagring tilbake til hver sluttbruker. For eksempel kan du differensiere priser basert på kostnadsforholdene som faktisk genereres av forskjellige brukere A, B og C, og gi datastøtte for kommersialisering av Agent.

• Innebygd kapasitetsgrense: For å kontrollere driftskostnadene for Agent, kan du angi en kvote (kapasitetsgrense) for hver ObjectSet. Når den forhåndsinnstilte verdien er nådd, vil systemet begrense brukeren fra å generere nye filer, og dermed unngå ressursmisbruk i scenarier med flere leietakere.

• Innebygd intelligens: Agent Bucket lar Agent bryte ut av begrensningene med enkel "lagring og henting" av tradisjonelle filer, og gir Object innebygd intelligens, som støtter Agent one-stop-utvikling mer effektivt. ObjectSet kan aktivere smart indeksering med ett klikk, og gi Agent innebygd vennlig multimodal spørsmåls- og svarfunksjonalitet, som erstatter den mekaniske operasjonen av tradisjonell Object CRUD; den støtter til og med aktivering av Agentself-modus med ett klikk, kobler sammen vektorer, kunnskap, modeller og prompter, og avslører direkte funksjonaliteten til scenariebaserte underagenter, slik at overordnede Agent-utviklere kan fokusere på å skape hovedvirksomhetsarbeidsflyt og frigjøre effektiviteten av intelligent inntektsgenerering.

Tekniske utfordringer brakt av applikasjonsskalering

Ved å introdusere det opprinnelige konseptet ObjectSet, gir Agent Bucket applikasjonsutviklere en elegant og effektiv måte å administrere data for hundrevis av millioner av sluttbrukere. Hver brukers digitale eiendeler lagres sikkert i sin eksklusive ObjectSet, og realiserer naturlig isolasjon, fakturering og kvoteadministrasjon.

Med den raske utvidelsen av applikasjonsskalaen, blir kompleksiteten i administrasjonen av massive sett, vanskeligheten med isolasjon og fysiske flaskehalser tydelige samtidig:

• Problem med hierarkisk administrasjon av massive brukere: Når applikasjoner administrerer ressurser og funksjoner for et stort antall brukere på forskjellige nivåer, må de designe og implementere hierarkiske metadata for brukere selv, og knytte objektlagringsfunksjoner til brytere. Å hjelpe utviklere med å administrere brukerhierarkier elegant på det opprinnelige konseptet Set er viktig for å akselerere applikasjonsimplementeringen.- Enkeltklynge kapasitetsflaskehals: Selv om Agent Bucket i teorien kan utvides uendelig, lagres metadataene som standard i en enkelt fysisk klynge. Når det totale antallet objekter i en bucket når hundrevis av milliarder eller til og med billioner, blir den fysiske kapasiteten til en enkelt klynge en uoverkommelig grense.

• Tilgangspunkt delingsproblem: Mangfoldet av Agent-tjenester og det store antallet brukere gir større sikkerhetsrisiko og eksplosjonsradius for selve tilgangspunktet. Hvordan man utfører dynamisk planlegging basert på forskjellene mellom et stort antall forskjellige tjenester og brukere, og realiserer differensiert sikkerhet, isolasjon og akselerasjonsevne, er en utfordring.

Set Tagging: Tag-basert administrasjon av brukergradering

ObjectSet tilbyr en innebygd tag-basert administrasjonsmetode, slik at Agent-utviklere enkelt kan bruke set tagging-funksjonen for å fullføre brukergraderingsstyring. Utviklere kan definere et tag for hvert definerte brukernivå, og aktivere forskjellige kvoter og funksjoner for hvert tag. Alle ObjectSet som er tagget med dette tagget, vil bruke de tilsvarende kvotene og funksjonene. Ta V1, V2 og V3 som eksempler:

• V1: Standardnivå, gratisbrukere, standard tag for alle ObjectSet, kan konfigureres til å lagre maksimalt 1 GiB data, offentlig nettverksdistribusjon kan ikke overstige 100 mbps båndbredde, nedlastingshastighet for enkeltstrøm er kontrollert til 1 mbps;

• V2: Betalende medlemmer på startnivå, konfigurert til å lagre maksimalt 10 GiB data, offentlig nettverksdistribusjon kan ikke overstige 10 gbps båndbredde, nedlastingshastighet for enkeltstrøm er kontrollert til 10 mbps;

• V3: Avanserte betalende medlemmer, i tillegg til å tilby større lagring og offentlig nettverksdistribusjonskvote, støttes også konfigurasjon for å aktivere ekstra offentlig nettverk svak nettverksakselerasjon og høyytelses medieakselerasjonsfunksjoner;

Agent-utviklere kan fleksibelt bruke V1/V2/V3 tagging for å administrere ressursene og merverdifunksjonene som disse brukerne kan bruke, rettet mot forskjellige utviklingssykluser for forskjellige brukere.

Set Slice: Innebygd isolasjon av massive brukerdata

Når antall Set i en Agent Bucket når hundrevis av millioner, og antall objekter når hundrevis av milliarder eller billioner, vil selve det faktum at "alle metadata for en enkelt Bucket er sentralisert i en KV-klynge" medføre doble risikoer for kapasitet og ytelse.

Set Slice gir en idé om "logisk ikke-splitting, fysisk splitting":

• Logisk sett administrerer du fortsatt bare en Agent Bucket.

• Fysisk sett, i henhold til omfanget av Set og objektnavnene i Set, deles metadataene inn i flere Slice (skiver), og hver Slice kan lagres på forskjellige klynger. Flere Set er naturlig isolert, og en enkelt Set kan utvides horisontalt.

Set Slice er en ytterligere utvidelse og garanti for ObjectSet-funksjonen. Den løser det underliggende problemet med ubegrenset utvidelse av fysisk kapasitet, samtidig som den sikrer stabiliteten og konsistensen til den øvre ObjectSet-administrasjonsmodellen.

• Stabil administrasjonsgrense: Selv om dataene til en Agent Bucket spenner over flere fysiske klynger, er ObjectSet fortsatt den eneste grunnleggende enheten for tillatelser, kvoter, fakturering og overvåking. Strategiene som utviklere konfigurerer for ObjectSet (som tilgangskontroll, kapasitetsgrense) vil automatisk tre i kraft på alle relaterte Slices, uten å måtte bekymre seg for distribusjonen av underliggende data.

• Enkelt Set kan utvides lineært: Når datamengden til en ObjectSet vokser raskt, vil dataene naturlig distribueres til flere Slices. Med utvidelsen av den totale klyngen vil kapasiteten til ObjectSet også vokse sømløst og lineært. Utviklere trenger ikke å utføre noen destruktive operasjoner som splitting eller migrering av selve ObjectSet.

• Ressursisolasjon på tvers av Set: Ved å distribuere objekter i forskjellige områder på forskjellige fysiske klynger, realiserer SetSlice en høyere dimensjon av ressursisolasjon. Kombinert med ObjectSet sin kvoteadministrasjon, kan det effektivt forhindre at dataveksten til en "superstor" ObjectSet overfyller alle ressursene i en enkelt klynge, og dermed påvirker stabiliteten til andre ObjectSet, noe som gjør den totale kapasitetsrisikoen kontrollerbar.- Logisk enhetlighet og kompatibilitet: For virksomheter og utviklere, uansett hvor mange Slice det er i bunnen, står de alltid overfor en logisk enhetlig Agent Bucket. Alle operasjoner rettet mot bucket, ObjectSet og objekter forblir uendret, og realiserer fullstendig transparens av fysisk utvidelse for applikasjoner på øverste nivå.

Set AccessPoint: Isolerer hver brukers tilgangspunkt

Agent Bucket støtter aktivering av uavhengige tilgangspunkter (uavhengige domener) for hver ObjectSet, og utvider differensierte sikkerhets-, isolasjons- og akselerasjonsmuligheter på tilgangspunktet. Systemet må støtte planlegging av milliarder av uavhengige tilgangspunkter og differensierte konfigurasjonsmuligheter.

Uavhengig tilgangsdomene {$apid}.tos-objectset-ap.volces.com: Tosjikts sikkerhetsbeskyttelse

• Første nivå Obscurity (skjulthet): Uavhengig subdomene per bruker/ObjectSet, apid høy entropi hash, ekstremt lav kollisjonssannsynlighet, kan ikke gjette og uttømme en spesifikk brukerinngang fra tilgangsdomenet;

• Andre nivå Containment (begrensning): Agent-utviklere bruker sts for å distribuere ObjectSet-nivå tilgangstillatelser, selv om sts lekker, kan det kontrollere at tilgangsområdet er begrenset til en begrenset gyldighetsperiode for en bestemt ObjectSet;

Heuristisk planleggingssystem: Beregning av planleggingsstrategi for milliarder av domener

• Differensiert tilgangsstrategi etter bruker/ObjectSet:tag

• Flere brukere/ObjectSet spredes automatisk på forskjellige offentlige nettverksinnganger, og antall brukere som påvirkes av en enkelt inngangsfeil er kontrollert

• Elastisk planlegging i hele regionen, automatisk trafikkbokspakking og -flytting fullføres for enhver enkelt inngangsfeil/overbelastning

• Brukere av offentlig nettverksakselerasjonsdistribusjonstype, merket med offentlig nettverksoverføringsakselerasjonstagg, automatisk planlegging av akselerasjonsinngang

• Offentlige nettverksrisikobrukere, merket med risikotagg, automatisk planlegging av offentlig nettverksisolasjonsinngang og redusert offentlig nettverksbåndbreddekvote

• Interne nettverkstverrdomenebrukere, merket med tverrdomenetagg, automatisk planlegging av intern nettverks dedikert linjeakselerasjonsbane

• Lokal akseleratorbruker, merket med akseleratortagg, automatisk montering av lokal akselerator

Fra programmeringsassistent til AI-skyharddisk, de ubegrensede mulighetene til Agent Bucket

Agent Bucket gir en komplett løsning for Agent, og designapplikasjonsscenariene til ObjectSet er langt mer enn dette. Det kan enkelt utvides til alle applikasjoner som trenger å tilby tjenester til et stort antall sluttbrukere:

• Kodebibliotek: Tidligere, når bedrifter eller enkeltpersoner hostet kode i skyen, måtte de ofte bygge et "leiersystem" på toppen av objektlagringen for å oppnå konto isolasjon og tilgangskontroll. Nå kan du tildele hver utvikler en eksklusiv ObjectSet for å samle kodebiblioteker, bygge artefakter og avhengigheter. Agent Skills er også naturlig tilpasset ObjectSet. Opplasting og nedlasting av Skills distribueres gjennom ObjectSet for å gi sterk isolasjon og unngå forstyrrelser fra Agent-kjøretid.

• Enterprise Photo Album Network Disk: Tradisjonelle fotoalbum- eller nettverksdisktjenester blander ofte alle brukernes bilder i samme bucket og skiller brukere gjennom prefikser, noe som ikke bare er komplisert å administrere, men også utsatt for "naboeffekter". Basert på ObjectSet faller hver brukers bilder og videoer i sine egne Set, og tilgangstopper forstyrrer ikke hverandre. Du kan også angi kapasitetsgrenser, sikkerhetskopieringsstrategier og krypteringsmetoder per bruker, og virkelig oppnå "alle har et sikkert og kontrollerbart skyalbum".

• Hadoop Data Warehouse: I et enterprise data warehouse deler forskjellige forretningslinjer og forskjellige databaser ofte ressurser på samme underliggende lagring. Ved å kartlegge hver database til en ObjectSet, kan bedrifter realisere isolasjon og kvotekontroll per database på enhetlig lagring. Spesielt gir ObjectSet et ekstra lag med tillatelser på TOS, og gir isolasjon og tillatelseskontroll for databaser og tabeller lagret på TOS uten å endre den eksisterende Proton on TOS.- Modellhostingplattform: I stordatamodellhosting er ikke bare hver modell enorm, men den kan også ha forskjellige versjoner, vekter og inferenskonfigurasjoner. Ved å opprette et ObjectSet for hver modell kan modellvekter, Tokenizer, konfigurasjonsfiler og relaterte evalueringsdata pakkes og hostes i samme område. Driftsiden kan sette differensierte krypteringspolicyer, sikkerhetskopieringspolicyer og båndbreddekontroll for forskjellige modeller. Samtidig kan den bruke native målingsfunksjoner til å beregne de faktiske brukskostnadene for hver modell, og gi et grunnlag for fakturering og ressursplanlegging etter modelldimensjon.

• Data SaaS-tjenester: Datafordelingsplattformer rettet mot et stort antall sluttbrukere må ofte koble til mange dataleverandører samtidig. De må sikre at datagrensene til hver part er klare, og unngå ytelsesrisikoen ved at "en stor bøtte drar ned alle". Ved hjelp av Agent Bucket kan hver dataleverandør ha sitt eget ObjectSet, administrere rådata og prosesseringsresultater samlet, og deretter bruke uavhengige domener og båndbredde/QPS-kvoter for å gi differensiert servicegaranti og trafikkbegrensning for forskjellige leverandører, og realisere en datadistribusjonsinfrastruktur som er "en plattform, flere leverandører, isolert fra hverandre, men kontrollerbar samarbeid".

Referanse:

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