Agent Bucket: Agent-native storage bucket i petabyte-skala

I dag, hvor AI-agenter skyder op som paddehatte efter regn, bygger udviklere intelligente applikationer med fantasi i et hidtil uset tempo. Fra programmeringsassistenter, der kan hjælpe dig med at skrive kode, til kreative værktøjer, der kan generere en film ud fra en enkelt sætning, til personlige intelligente assistenter, der altid er klar, er agenter ved at omforme den måde, vi interagerer med den digitale verden på. Bag denne bølge er der en voksende konsensus: Ved hjælp af Serverless-arkitektur (såsom Lambda), store sprogmodeller (LLM'er) og cloud storage (såsom S3, TOS) kombineret med Vibe Coding kan enhver hurtigt bygge deres egen AI-agent på 30 minutter.

Fra at være "brugbar" til at være "god at bruge" skal Agent-udviklere stadig overvinde vanskelighederne med at gå fra "legetøj" til "produktionsklare applikationer". Efterhånden som forretningen bevæger sig mod et stort antal brugere, er udviklere tvunget til at stå over for en ekstremt kompleks udfordring: Hvordan bygger man en komplet storage-løsning til et stort antal slutbrugere på objektlager? For de fleste udviklere er dette ikke kun en teknisk barriere, men også en kløft, der hindrer storskala distribution af agenter. Agent Bucket har til formål at forenkle byggeprocessen af multi-tenant systemer fuldstændigt gennem AI-native storage design og give mere venlige Agent-kapaciteter.

Når hundreder af millioner af brugere strømmer til, er traditionel objektlagring "ikke nok"

Forestil dig, at du har udviklet en populær AIGC-applikation. Hver bruger vil generere og gemme et stort antal billeder, videoer og midlertidige filer. Som udvikler vil du naturligvis vælge modne og skalerbare objektlagringstjenester som S3 og TOS. Men her er problemet: Hvordan administrerer man data for et stort antal brugere?

S3's blog fra 2022, "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3", beskriver to metoder, "Brug af separate S3-buckets for hver tenant" og "Delte S3-buckets isoleret baseret på præfiks":

• Opret en separat "bucket" for hver bruger: Dette er muligt, når der er få brugere, men når antallet af brugere vokser til titusinder eller millioner, vil antallet af buckets eksplodere hurtigt, og administrationsomkostningerne og ressourcebegrænsningerne vil være uudholdelige. S3 giver en samlet bucket-kvote på 10.000 i hele regionen, men for populære AI-kapaciteter er 10.000 langt fra nok.

• Brug "præfikser" til at skelne brugere i den samme bucket: Dette er blevet den almindelige løsning. For eksempel starter bruger A's filer alle med user-a/, og bruger B's starter med user-b/, ligesom at administrere filer i mapper på en computer. Objektlagring har dog ikke native mapper, og denne løsning skelner mellem multi-tenants gennem "fælles præfiks" (Prefix) i et "K-V" lagringssystem.

Denne "bucket"- eller "præfiks"-baserede løsning er blevet brugt i vid udstrækning i de sidste ti år. Men der er følgende problemer:

• Multi-tenant isolation: Alle brugerdata er blandet i den samme bucket, og en brugers unormale højfrekvente adgang kan påvirke alle andre brugere og skabe en "naboeffekt". Ydelsesisolation og fejlisolation er umulige.

• Adgangskontrol: Komplekse adgangspolitikker (IAM Policy) er vanskelige at vedligeholde, og det er let at lave konfigurationsfejl, hvilket fører til utilsigtet adgang til brugerdata, især når der er behov for at interagere med andre cloudtjenester, er risikoen større.

• Omkostningsklarhed: Det er svært præcist at vide, hvor meget lagerplads hver bruger bruger, og hvor mange trafikomkostninger der genereres. Når du vil opkræve betaling fra betalende brugere baseret på forbrug, bliver fakturering og måling en rodet affære.Hvorfor er disse tilsyneladende grundlæggende behov så "tunge" for Agent-udviklere at implementere på objektlagring? En dybere undersøgelse af årsagerne viser, at der i den nuværende cloud-native arkitektur er et stort tomrum mellem "objektlagring" som S3 og traditionelle "filsystemer". Objektlagring (S3/TOS) er i bund og grund "flad", og designet er beregnet til simpel lagring af massive data, som et stort lager. Selvom kapaciteten er næsten ubegrænset, er den logiske struktur ekstremt simpel. Den mangler indbygget avanceret katalogstyring, finkornet metadatastyring og ægte lejerbevidsthed. Når udviklere forsøger at simulere et "tredimensionelt" multi-tenant filsystem på den "flade" S3 ved hjælp af hårdkodede præfikser, bruger vi faktisk en "statisk KV-lagring" til at understøtte en "katalogsemantik, stærk isolering" Agent-applikations filadgangsmetode. Det vil sige, at Agent skal bruge yderligere tokens til at administrere filer og kontrollere og løse multi-tenant tilladelser og isolering. Disse yderligere forbrugte tokens indikerer alle, at S3's definerede simple lagringstjeneste ikke er simpel nok for Agent.

S3-bloggen fra 2025, "Design patterns for multi-tenant access control on Amazon S3", uddyber yderligere S3 Access Point. Dette betyder, at du kan oprette flere virtuelle netværksadgangspunkter og konfigurere en tilpasset adgangspunktpolitik for hvert adgangspunkt, hvilket giver nogle løsninger på netværksplanlægningsniveau for multi-tenant scenarier.

Agent Wonderland

En ideel Agent-udvikler kan, når han udvikler en AI Agent, bygge en fuldt serverless Agent baseret på "Agent SDK + lagring + MaaS-tjenester":

• Agent kan køre fuldt serverless

• Kan sammensætte eksisterende produktfunktioner for at bygge Agent gennem Vibe Coding

• Behøver kun at vedligeholde "ADK" python-scripts

• Lagring bruger objektlagring

• AI-funktioner bruger Doubao

• Teoretisk set ingen ECS eller andre instansbaserede produkter

Samtidig skal lagringen give følgende muligheder:

• Agent kan have en objektsemantisk lagring (gemme filer), give multi-tenant adgang, starte med millioner og kan udvides til milliarder

• Agent kan give hver bruger et uafhængigt rum (mellem flere virksomheder kan virksomheder eller uid have samme navn)

• Agent kan direkte konfigurere båndbredden for hver bruger og konfigurere den samlede størrelsesgrænse for brugerobjekter

• Agent kan fakturere, overvåge og observere i henhold til brugeren

• Agent kan konfigurere adgangspolitikker for hver brugers filer

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

For grundlæggende at løse dette problem har vi foreslået et nyt objektlagringsparadigme - Agent Bucket. Dens kerneinnovation er at introducere et nyt native ressourcelag mellem den traditionelle "bucket" og "objekt": objektsamling.

Kerneideen bag dette design er ekstremt enkel: match et eksklusivt ObjectSet til hver af dine slutbrugere. Du kan tænke på ObjectSet som et "datasikkert skab" eller "personligt cloud-rum", der er skræddersyet til hver bruger. Logisk set tilhører det din (udviklerens) Bucket, men fysisk og administrativt har det sin egen uafhængige "personlighed" og "livscyklus".Agent Bucket understøtter 100 millioner ObjectSets per bucket, hvilket betyder, at du nemt kan betjene hundredvis af millioner af slutbrugere, som om hver slutbruger "lever" i deres eget uafhængige lagerområde, uden at skulle bekymre dig om multi-tenant lagerstyring.

ObjectSet Design - Agent-venlige funktioner

I Agent Bucket er ObjectSet ikke kun et ekstra lag, men også de mest vanskelige krav i multi-tenant scenarier er blevet til native, out-of-the-box funktioner. Når dataejerskabet er tydeligt defineret på ObjectSet-niveau, bliver en række funktioner, der tidligere var svære at implementere, en selvfølge.

• Native isolation: På ObjectSet-niveau kan du indstille uafhængige QPS-, båndbreddebegrænsninger og kapacitetskvoter for hver bruger. Betalende brugeres oplevelse kan garanteres, og gratis brugeres unormale adfærd vil ikke påvirke andre. Dette er ægte fejldomæneisolation, der sikrer, at "naboer" ikke længere forstyrrer hinanden.

• Native tilladelser: Hver ObjectSet kan have et uafhængigt domænenavn. Det betyder, at du kan give bruger A en eksklusiv adgangsadresse som user-a.yourapp.com i stedet for at afsløre hele storage bucket'ens domænenavn. Endnu mere smart er designet med "to låse": Den første lås er et midlertidigt adgangsbevis (STS) udstedt af cloud-udbyderen, der styrer adgangstilladelser på applikationsniveau; den anden lås er ObjectSet's uafhængige domænenavn, som låser adgangsanmodninger til brugerens eget dataområde fra netværksniveau. Dette forbedrer datasikkerheden betydeligt.

• Native overvågning: På overvågningsdashboardet kan du ikke længere kun se oversigtsdata for hele bucket'en. Du kan nedbryde overvågningsdiagrammerne by-ObjectSet og tydeligt se, hvilken slutbruger der foretager et stort antal adgange, og dermed træffe præcise drifts- og optimeringsbeslutninger.

• Native kapacitetsnedbrydning: Politikker, der tidligere kun kunne indstilles på bucket-niveau, kan nu nedbrydes til hver bruger. Du kan indstille forskellige datalivscyklusser for forskellige niveauer af brugere eller bruge forskellige krypteringsnøgler for hver ObjectSet for at opnå mere granulær og sikker datastyring.

• Native måling: Vil du vide, hvor meget lagerplads hver bruger optager? Vil du fordele lageromkostningerne præcist til hver bruger? Det er nu nemt. Agent Bucket vil automatisk beregne kapaciteten og brugen af hver ObjectSet, hvilket gør din fakturering og fordeling klar og tydelig.

• Native fakturering: Udviklere kan nemt implementere omkostningsdeling og præcist tilskrive de omkostninger, der genereres af lager, til hver slutbruger. For eksempel kan du opkræve forskellige priser baseret på de faktiske omkostningsforhold for forskellige brugere A, B og C, hvilket giver datasupport til Agent's kommercialisering.

• Native kapacitetsgrænse: For at kontrollere Agent's driftsomkostninger kan du indstille en kvote (kapacitetsgrænse) for hver ObjectSet. Når den forudindstillede værdi er nået, vil systemet begrænse brugeren fra at generere nye filer, hvilket fundamentalt undgår ressourcemisbrug i multi-tenant scenarier.

• Native intelligens: Agent Bucket lader Agent bryde ud af begrænsningerne ved traditionel simpel "lagring og hentning" af filer, giver Object native intelligens og understøtter mere effektivt Agent one-stop-udvikling. ObjectSet kan aktivere smart indeksering med et enkelt klik, hvilket giver Agent native venlige multimodale spørgsmål og svar-funktioner, der erstatter den mekaniske betjening af traditionel Object CRUD; den understøtter endda aktivering af Agentself-tilstand med et enkelt klik, forbinder vektorer, viden, modeller og prompts og afslører direkte scenariebaserede sub-Agent-funktioner, så overordnede Agent-udviklere kan fokusere på at skabe vigtige forretningsworkflows og fuldt ud frigøre intelligent monetariserings effektivitet.

Tekniske udfordringer som følge af applikationsskala-eksplosion

Agent Bucket giver applikationsudviklere en elegant og effektiv måde at administrere data for hundredvis af millioner af slutbrugere ved at introducere det native koncept ObjectSet. Hver brugers digitale aktiver er sikkert gemt i deres eksklusive ObjectSet, hvilket naturligt implementerer isolation, fakturering og kvotestyring.

Med den hurtige udvidelse af applikationsskalaen bliver kompleksiteten af administration af massive sæt, vanskeligheden ved isolation og fysiske flaskehalse tydelige på samme tid:

• Problem med hierarkisk administration af massive brugere: Når applikationen differentieret administrerer ressourcer og funktioner for et stort antal brugere på forskellige niveauer, er det nødvendigt at designe og implementere brugerens hierarkiske metadata og associere objektlagringsfunktionskontakter. At hjælpe udviklere med elegant at administrere brugerhierarkier på det native koncept Set er vigtigt for at fremskynde applikationsimplementeringen.- Enkelt klynge kapacitetsflaskehals: Selvom Agent Bucket i teorien kan udvides uendeligt, gemmes dens metadata som standard i en enkelt fysisk klynge. Når det samlede antal objekter i bucketen når hundreder af milliarder eller endda billioner, bliver den fysiske kapacitet af en enkelt klynge en uoverstigelig grænse.

• Adgangspunkt delingsproblem: Mangfoldigheden af Agents forretninger og det enorme antal brugere medfører større sikkerhedsrisici og eksplosionsradius for selve adgangspunktet. Hvordan man udfører dynamisk planlægning baseret på forskellene mellem et stort antal forskellige forretninger og brugere for at opnå differentieret sikkerhed, isolering og accelerationsfunktioner er en udfordring.

Set Tagging: Tag-baseret styring af brugerklassificering

ObjectSet giver en indbygget tag-baseret styringsmetode, der giver Agent-udviklere mulighed for nemt at bruge set tagging-funktioner til at fuldføre brugerklassificeringsstyring. Udviklere kan definere et tag for hvert bruger niveau og aktivere forskellige kvoter og funktioner for hvert tag. Alle ObjectSets, der er tagget med dette tag, vil anvende de tilsvarende kvoter og funktioner. Tag f.eks. V1, V2 og V3 niveauer:

• V1: Standardniveau, gratis brugere, standardtagget for alle ObjectSets, kan konfigureres til at gemme maksimalt 1 GiB data, offentlig netværksdistribution må ikke overstige 100 mbps båndbredde, og downloadhastigheden for en enkelt stream er begrænset til 1 mbps;

• V2: Grundlæggende betalende medlemmer, konfigureret til at gemme maksimalt 10 GiB data, offentlig netværksdistribution må ikke overstige 10 gbps båndbredde, og downloadhastigheden for en enkelt stream er begrænset til 10 mbps;

• V3: Avancerede betalende medlemmer, ud over at give større lager- og offentlige netværksdistributionskvoter, understøtter de også konfiguration af yderligere offentlig netværksacceleration med svag netværk og højtydende medieaccelerationsfunktioner;

Agent-udviklere kan fleksibelt bruge V1/V2/V3 tagging til at administrere de ressourcer og merværdifunktioner, som disse brugere kan bruge, for forskellige brugeres forskellige udviklingscyklusser.

Set Slice: Indbygget isolering af massive brugerdata

Når antallet af Sets i en Agent Bucket når hundreder af millioner, og antallet af objekter når hundreder af milliarder eller billioner, vil det faktum, at "alle metadata for en enkelt Bucket er koncentreret i en enkelt KV-klynge" i sig selv medføre dobbelte risici for kapacitet og ydeevne.

Set Slice giver en idé om "logisk ikke-opdeling, fysisk opdeling":

• Logisk set administrerer du stadig kun en enkelt Agent Bucket.

• Fysisk set opdeles metadata i flere Slice (skiver) i henhold til omfanget af Set og objektnavnene i Set. Hver Slice kan gemmes på forskellige klynger, og flere Sets er naturligt isoleret, og en enkelt Set kan udvides vandret.

Set Slice er en yderligere udvidelse og garanti for ObjectSet-funktioner. Det løser det underliggende problem med ubegrænset udvidelse af fysisk kapacitet og sikrer samtidig stabiliteten og konsistensen af den øverste ObjectSet-styringsmodel.

• Stabil styringsgrænse: Selvom dataene for en enkelt Agent Bucket spænder over flere fysiske klynger, er ObjectSet stadig den eneste grundlæggende enhed for tilladelser, kvoter, fakturering og overvågning. De politikker, der er konfigureret af udviklere for ObjectSet (såsom adgangskontrol, kapacitetsgrænse), træder automatisk i kraft på alle relaterede Slices uden at skulle bekymre sig om distributionen af underliggende data.

• Enkelt Set kan udvides lineært: Når datamængden af en bestemt ObjectSet vokser hurtigt, vil dens data naturligt blive distribueret til flere Slices. Med udvidelsen af den samlede klynge vil kapaciteten af denne ObjectSet også vokse problemfrit og lineært. Udviklere behøver ikke at udføre nogen destruktive operationer såsom opdeling eller migrering af selve ObjectSet.

• Ressourceisolering på tværs af Sets: Ved at distribuere objekter i forskellige områder på forskellige fysiske klynger realiserer SetSlice en højere dimension af ressourceisolering. Kombineret med ObjectSets kvotestyring kan det effektivt forhindre, at datavæksten for en bestemt "superbruger" ObjectSet fortrænger alle ressourcerne i en enkelt klynge og derved påvirker stabiliteten af andre ObjectSets, hvilket gør den samlede kapacitetsrisiko kontrollerbar.- Logisk enhed og kompatibilitet: For virksomheder og udviklere er der altid en logisk samlet Agent Bucket, uanset hvor mange Slice der er underliggende. Alle operationer på bucket, ObjectSet og objekter forbliver de samme, hvilket realiserer fuldstændig gennemsigtighed af fysisk udvidelse for applikationer på øverste niveau.

Set AccessPoint: Isolerer hver brugers adgangspunkt

Agent Bucket understøtter aktivering af uafhængige adgangspunkter (uafhængige domæner) for hver ObjectSet og udvider differentierede sikkerheds-, isolations- og accelerationsfunktioner på adgangspunktet. Systemet skal understøtte planlægning af millioner af uafhængige adgangspunkter og differentierede konfigurationsfunktioner.

Uafhængigt adgangsdomæne {$apid}.tos-objectset-ap.volces.com: To-lags sikkerhedsbeskyttelse

• Første lag Obscurity (skjulthed): Uafhængigt underdomæne efter bruger/ObjectSet, apid høj entropi hash, ekstremt lav kollisionssandsynlighed, kan ikke gætte og udtømme en bestemt brugerindgang fra adgangsdomænets perspektiv;

• Andet lag Containment (indeslutning): Agent-udviklere bruger sts til at distribuere ObjectSet-niveauadgangstilladelser, selvom sts lækkes, kan det kontrollere dets adgangsområde til at være begrænset til en begrænset gyldighedsperiode for en bestemt ObjectSet;

Heuristisk planlægningssystem: Beregning af planlægningsstrategi for millioner af domæner

• Differentieret adgangsstrategi efter bruger/ObjectSet:tag

• Flere brugere/ObjectSet spredes automatisk på forskellige offentlige netværksindgange, og antallet af brugere, der er påvirket af en enkelt indgangsfejl, er kontrolleret

• Fuld regional elastisk planlægning, enhver enkelt indgangsfejl/overbelastning fuldfører automatisk trafikboksning og -flytning

• Brugere af offentlig netværksaccelerationsdistributionstype, markeret med et offentligt netværkstransmissionsaccelerationstag, planlægger automatisk accelerationsindgangen

• Brugere af offentlig netværksrisikotype, markeret med et risikotag, planlægger automatisk den offentlige netværksisolationsindgang og reducerer den offentlige netværksbåndbreddekvote

• Brugere af intern netværks-cross-domain-type, markeret med et cross-domain-tag, planlægger automatisk den interne netværks dedikerede linjeaccelerationssti

• Brugere af lokalitetsaccelerator, markeret med et acceleratortag, monterer automatisk lokalitetsacceleratoren

Fra programmeringsassistent til AI-skyharddisk, de uendelige muligheder for Agent Bucket

Agent Bucket giver en komplet løsning til Agent, og ObjectSets designapplikationsscenarier er langt mere end dette. Det kan nemt udvides til alle applikationer, der skal levere tjenester til et stort antal slutbrugere:

• Kodelager: Tidligere, når virksomheder eller enkeltpersoner hostede kode i skyen, var de ofte nødt til at bygge et - Model Hosting Platform: I model hosting-scenarier er hver model ikke kun enorm, men kan også have forskellige versioner, vægte og inferenskonfigurationer. Ved at oprette et ObjectSet for hver model kan modelvægte, Tokenizer, konfigurationsfiler og relaterede evalueringsdata pakkes og hostes i samme rum. Driftsfolk kan indstille differentierede krypteringspolitikker, backup-politikker og båndbreddekontrol for forskellige modeller. Samtidig kan den faktiske brugsomkostning for hver model statistikeres gennem native målingsfunktioner, hvilket giver et grundlag for fakturering og ressourceplanlægning på modelniveau.

• Data SaaS-tjenester: Data distributionsplatforme, der er rettet mod et stort antal slutbrugere, skal ofte oprette forbindelse til mange dataudbydere samtidigt. Det er nødvendigt at sikre, at data grænserne for hver part er klare, og at undgå risikoen for, at "en stor spand trækker alle ned". Ved hjælp af Agent Bucket kan hver dataudbyder have sit eget ObjectSet til at administrere rådata og behandlingsresultater samlet. Gennem uafhængige domæner og båndbredde, QPS-kvoter, kan differentierede servicegarantier og hastighedsbegrænsning implementeres for forskellige udbydere, hvilket realiserer en datadistributionsinfrastruktur med "en platform, flere udbydere, isoleret og kontrollerbart samarbejde".

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/