Agent Bucket: Сховище Agent-ів на трильйон об'єктів

У часи, коли AI Agent-и з'являються, як гриби після дощу, розробники з безпрецедентною швидкістю створюють інтелектуальні додатки, сповнені уяви. Від помічників з програмування, які допомагають вам писати код, до інструментів для створення фільмів з одного речення, і до особистих інтелектуальних помічників, які завжди напоготові, Agent-и змінюють спосіб нашої взаємодії з цифровим світом. За цією хвилею все чіткіше простежується консенсус: за допомогою Serverless архітектури (такої як Lambda), великих мовних моделей (LLM) і хмарного сховища (такого як S3, TOS), у поєднанні з Vibe Coding, будь-хто може швидко створити власний AI Agent за 30 хвилин.

Від "можна використовувати" до "зручно використовувати", Agent-розробникам все ще потрібно подолати труднощі, щоб перейти від "іграшки" до "промислового застосування". Зі збільшенням бізнесу до величезної кількості користувачів, розробники змушені стикатися з надзвичайно складним завданням: як створити повноцінне рішення для зберігання даних для величезної кількості кінцевих користувачів в об'єктному сховищі? Для більшості розробників це не тільки технічний бар'єр, але й прірва, що перешкоджає масштабному розповсюдженню Agent-ів. Agent Bucket має на меті повністю спростити процес створення багатокористувацьких систем за допомогою AI-оригінального дизайну сховища, забезпечуючи більш зручні можливості Agent-ів.

Коли мільярди користувачів входять, традиційного об'єктного сховища "не вистачає"

Уявіть собі, що ви розробили популярний додаток AIGC. Кожен користувач генеруватиме та зберігатиме велику кількість зображень, відео та тимчасових файлів. Як розробник, ви, природно, оберете зрілі та масштабовані служби об'єктного сховища, такі як S3 і TOS. Але виникає питання: як керувати даними для величезної кількості користувачів?

У блозі S3 2022 року «Розділення та ізоляція багатокористувацьких SaaS-даних за допомогою Amazon S3» описано два способи: «Використання окремих S3-bucket-ів для кожного орендаря» та «Спільний S3-bucket, ізольований на основі префіксів»:

• Створення окремого "bucket-а" для кожного користувача: це можливо, коли користувачів небагато, але коли кількість користувачів зростає до десятків тисяч, мільйонів, кількість bucket-ів швидко вибухає, а витрати на управління та обмеження ресурсів стають нестерпними. S3 надає загальну квоту в 10 000 bucket-ів для всього регіону, але для популярних можливостей AI 10 000 далеко не достатньо.

• Розрізнення користувачів за допомогою "префіксів" в одному bucket-і: це стало основним рішенням. Наприклад, файли користувача A починаються з user-a/, а файли користувача B починаються з user-b/, як і керування файлами за допомогою папок на комп'ютері. Однак в об'єктному сховищі немає власних папок, це рішення полягає в розрізненні кількох орендарів за допомогою "загального префікса" (Prefix) в системі зберігання "K-V".

Цей підхід на основі "bucket-ів" або "префіксів" широко використовувався протягом останніх десяти років. Але є такі проблеми:

• Ізоляція кількох орендарів: дані всіх користувачів змішані в одному bucket-і, і ненормально часті звернення одного користувача можуть вплинути на всіх інших користувачів, створюючи "ефект сусіда". Про ізоляцію продуктивності та ізоляцію відмов не може бути й мови.

• Контроль дозволів: складні політики дозволів (IAM Policy) важко підтримувати, і легко допустити помилки конфігурації, що призведе до випадкового доступу до даних користувачів, особливо коли потрібно взаємодіяти з іншими хмарними службами, ризики ще більші.

• Чіткість витрат: вам важко точно дізнатися, скільки місця для зберігання даних спожив кожен користувач і скільки було згенеровано плати за трафік. Коли ви хочете стягувати плату з платних користувачів на основі використання, облік і вимірювання стають незрозумілими.Чому ці, здавалося б, базові потреби, Agent-розробники реалізують на об'єктному сховищі дещо "важко"? Глибоке дослідження показує, що в сучасній хмарній архітектурі існує величезна порожнина між "об'єктним сховищем" (S3/TOS) і традиційною "файловою системою". Суть об'єктного сховища (S3/TOS) полягає в "спрощенні", початковий задум - просте зберігання величезних обсягів даних, як величезний склад, хоча ємність майже необмежена, але логічна структура надзвичайно проста. Йому не вистачає вбудованого розширеного керування каталогами, детального контролю метаданих і справжнього розпізнавання орендарів. Коли розробники намагаються на "плоскому" S3 імітувати "тривимірну" багатоклієнтську файлову систему шляхом жорсткого кодування префіксів, ми фактично використовуємо "статичне KV-сховище" для підтримки "каталожної семантики, суворої ізоляції" способу доступу до файлів Agent-додатку. Тобто Agent потребує додаткових витрат токенів для керування файлами та контролю вирішення прав і ізоляції багатоклієнтності. Ці додаткові витрати токенів показують, що проста служба зберігання, визначена S3, недостатньо проста для Agent.

У блозі S3 за 2025 рік «Design patterns for multi-tenant access control on Amazon S3» додатково роз'яснюється S3 Access Point. Це означає, що можна створити кілька віртуальних точок доступу до мережі та налаштувати для кожної точки доступу спеціальну політику доступу, що пропонує деякі рішення на рівні мережевого планування для сценаріїв багатоклієнтності.

Agent Wonderland

В ідеалі, розробник Agent під час розробки AI Agent може створити повністю serverless Agent на основі "Agent SDK + сховище + MaaS-сервіс":

• Agent може працювати повністю serverless

• Можна створити Agent, комбінуючи існуючі можливості продукту за допомогою Vibe Coding

• Потрібно лише підтримувати python-скрипт "ADK"

• Сховище використовує об'єктне сховище

• AI-можливості використовують Doubao

• Теоретично немає ECS або інших продуктів інстансного типу

Водночас, сховище має надавати такі можливості:

• Agent може мати сховище з об'єктною семантикою (зберігати файли), надавати можливості багатоклієнтського доступу, починаючи з мільйона і розширюючись до мільярдів

• Agent може надавати кожному користувачеві незалежний простір (між кількома бізнесами, бізнеси або uid можуть мати однакові назви)

• Agent може безпосередньо налаштовувати пропускну здатність для кожного користувача, налаштовувати верхню межу загального розміру об'єктів користувача

• Agent може виставляти рахунки, здійснювати моніторинг і спостереження на основі користувача

• Agent може налаштовувати політику доступу до файлів для кожного користувача

Agent Bucket: Впровадження "багатоклієнтських власних" генів в AI Agent

Щоб принципово вирішити цю проблему, ми запропонували абсолютно нову парадигму об'єктного сховища - Agent Bucket. Її основна інновація полягає у введенні нового рівня власних ресурсів між традиційними "bucket" і "об'єктами": набір об'єктів.

Основна ідея цього дизайну надзвичайно проста: зіставте кожен набір об'єктів, призначений для кожного кінцевого користувача. Ви можете уявити ObjectSet як "сейф даних" або "особистий простір у хмарі", створений спеціально для кожного користувача. Логічно він належить вашому (розробника) Bucket, але фізично та в управлінні він має свою незалежну "індивідуальність" і "життєвий цикл".Agent Bucket: кожен бакет підтримує 100 мільйонів ObjectSet, що означає, що ви можете спокійно обслуговувати сотні мільйонів кінцевих користувачів, ніби кожен кінцевий користувач "живе" у власному незалежному просторі зберігання, і більше не потрібно турбуватися про управління багатокористувацьким зберіганням.

Дизайн ObjectSet – можливості, дружні до Agent

В Agent Bucket ObjectSet – це не просто додавання рівня, а перетворення найскладніших потреб у сценаріях багатокористувацькості на готові до використання власні можливості. Коли право власності на дані чітко визначено на рівні ObjectSet, низка можливостей, які раніше було важко реалізувати, стають природними.

• Власна ізоляція: на рівні ObjectSet ви можете встановити незалежні обмеження QPS, пропускної здатності та квоти ємності для кожного користувача. Досвід платних користувачів може бути гарантований, а ненормальна поведінка безкоштовних користувачів не вплине на інших. Це справжня ізоляція домену відмов, яка дозволяє "сусідам" більше не заважати один одному.

• Власні дозволи: кожен ObjectSet може мати незалежний домен. Це означає, що ви можете надати користувачеві A ексклюзивну адресу доступу user-a.yourapp.com, а не розкривати домен усього бакета зберігання. Більш розумним є дизайн "двох замків": перший замок – це тимчасовий токен доступу (STS), виданий постачальником хмарних послуг, який контролює дозволи доступу на рівні програми; другий замок – це незалежний домен ObjectSet, який блокує запити доступу в просторі даних користувача з мережевого рівня. Це значно підвищує безпеку даних.

• Власний моніторинг: на панелі моніторингу ви більше не можете бачити лише загальні дані всього бакета. Ви можете розбити діаграми моніторингу за ObjectSet, щоб чітко бачити, який кінцевий користувач здійснює велику кількість доступів, щоб приймати точні рішення щодо операцій та оптимізації.

• Власне зниження можливостей: політики, які раніше можна було встановлювати лише на рівні бакета, тепер можна перенести на кожного користувача. Ви можете встановити різні життєві цикли даних для користувачів різних рівнів або використовувати різні ключі шифрування для кожного ObjectSet для більш точного та безпечного управління даними.

• Власне вимірювання: хочете знати, скільки місця для зберігання використовує кожен користувач? Хочете точно розподілити витрати на зберігання між кожним користувачем? Тепер це стає легко. Agent Bucket автоматично підраховує ємність і використання кожного ObjectSet, роблячи ваше виставлення рахунків і розподіл прибутків чіткими.

• Власне виставлення рахунків: розробники можуть легко реалізувати розподіл витрат і точно повернути витрати, пов'язані зі зберіганням, кожному кінцевому користувачеві. Наприклад, диференційовано стягуйте плату відповідно до фактичного співвідношення витрат, понесених різними користувачами A, B і C, щоб забезпечити підтримку даних для комерціалізації Agent.

• Власний ліміт ємності: щоб контролювати операційні витрати Agent, ви можете встановити Quota (ліміт ємності) для кожного ObjectSet. Після досягнення заданого значення система обмежить користувача у створенні нових файлів, щоб уникнути зловживання ресурсами в сценаріях багатокористувацькості.

• Власний інтелект: Agent Bucket дозволяє Agent вийти за рамки простого "зберігання та отримання" традиційних файлів, надаючи Object власний інтелект і більш ефективно підтримуючи розробку Agent в одному місці. ObjectSet може в один клік увімкнути інтелектуальне індексування, щоб надати Agent власні дружні можливості багатомодальних питань і відповідей, замінюючи механічні операції традиційного Object CRUD; він навіть підтримує в один клік увімкнення режиму Agentself, з'єднуючи вектори, знання, моделі та підказки, безпосередньо розкриваючи функціональність суб-Agent, орієнтовану на сценарії, дозволяючи розробникам Agent верхнього рівня зосередитися на створенні основного бізнес-робочого процесу, повністю вивільняючи ефективність монетизації інтелекту.

Технічні виклики, спричинені вибуховим зростанням масштабу додатків

Впроваджуючи власну концепцію ObjectSet, Agent Bucket надає розробникам додатків елегантний і ефективний спосіб керування даними сотень мільйонів кінцевих користувачів. Цифрові активи кожного користувача безпечно зберігаються у власному ObjectSet, природно реалізуючи ізоляцію, виставлення рахунків і управління квотами.

Зі стрімким розширенням масштабу додатків одночасно виникають складність управління, труднощі ізоляції та фізичні вузькі місця величезної кількості Set:

• Проблема багаторівневого управління великою кількістю користувачів: коли додаток диференційовано керує великою кількістю ресурсів і функцій користувачів різних рівнів, йому потрібно самостійно розробляти та реалізовувати метадані багаторівневих користувачів і пов'язувати перемикачі функцій зберігання об'єктів. Допомога розробникам елегантно керувати багаторівневими користувачами на основі власної концепції Set є важливою для прискорення впровадження додатків.- Обмеження ємності одного кластера: хоча Agent Bucket логічно може бути розширений нескінченно, його метадані за замовчуванням зберігаються в одному фізичному кластері. Коли загальна кількість об'єктів у кошику досягає сотень мільярдів або навіть трильйонів, фізична ємність одного кластера стає непереборним обмеженням.

• Проблема спільного доступу до точок входу: різноманітність бізнесу Agent і величезна кількість користувачів створюють більші ризики безпеки та радіус вибуху для самої точки входу. Як динамічно планувати на основі відмінностей між великою кількістю різних бізнесів і користувачів, щоб реалізувати диференційовані можливості безпеки, ізоляції та прискорення, стає складним завданням.

Set Tagging: Ієрархічне керування користувачами за допомогою тегів

ObjectSet надає власний спосіб керування тегами, що дозволяє розробникам Agent легко використовувати можливості set tagging для завершення ієрархічного керування користувачами. Розробники можуть призначити тег кожному визначеному рівню користувача та ввімкнути різні квоти та функції для кожного тегу. Усі ObjectSet, позначені цим тегом, застосовуватимуть відповідні квоти та функції. Візьмемо для прикладу три рівні: V1, V2 та V3:

• V1: рівень за замовчуванням, безкоштовні користувачі, тег за замовчуванням для всіх ObjectSet, можна налаштувати для зберігання максимум 1GiB даних, розподіл загальнодоступної мережі не може перевищувати 100mbps пропускної здатності, а швидкість завантаження одного потоку контролюється на рівні 1mbps;

• V2: платні учасники початкового рівня, налаштовано для зберігання максимум 10GiB даних, розподіл загальнодоступної мережі не може перевищувати 10gbps пропускної здатності, а швидкість завантаження одного потоку контролюється на рівні 10mbps;

• V3: платні учасники преміум-класу, на додаток до забезпечення більшої ємності зберігання та квоти розподілу загальнодоступної мережі, також підтримують налаштування для ввімкнення додаткового прискорення слабкої мережі загальнодоступної мережі та можливостей прискорення високопродуктивних носіїв;

Розробники Agent можуть гнучко використовувати теги V1/V2/V3 для керування ресурсами та додатковими функціями, які можуть використовувати ці користувачі, для різних циклів розвитку різних користувачів.

Set Slice: Власна ізоляція даних для величезної кількості користувачів

Коли кількість Set в Agent Bucket досягає сотень мільйонів, а кількість об'єктів досягає сотень мільярдів або трильйонів, сам факт «усі метадані одного Bucket централізовано в одному KV-кластері» створює подвійні ризики ємності та продуктивності.

Set Slice пропонує ідею «логічно не розділяти, фізично розділяти»:

• З логічної точки зору, ви все ще керуєте лише одним Agent Bucket.

• Фізично, на основі діапазону Set і імен об'єктів у Set, метадані поділяються на кілька Slice (фрагментів), кожен Slice може зберігатися в різних кластерах, кілька Set природно ізольовані, а один Set горизонтально масштабується.

Set Slice є подальшим розширенням і гарантією можливостей ObjectSet. Він вирішує проблему нескінченного розширення фізичної ємності на базовому рівні, забезпечуючи стабільність і узгодженість моделі керування ObjectSet верхнього рівня.

• Стабільний кордон керування: навіть якщо дані Agent Bucket охоплюють кілька фізичних кластерів, ObjectSet все ще є єдиною основною одиницею дозволів, квот, виставлення рахунків і моніторингу. Політики, налаштовані розробниками для ObjectSet (наприклад, контроль доступу, обмеження ємності), автоматично набувають чинності на всіх пов'язаних Slices, не турбуючись про розподіл базових даних.

• Один Set може лінійно масштабуватися: коли обсяг даних певного ObjectSet швидко зростає, його дані природно розподіляються між кількома Slices. З розширенням загального кластера ємність цього ObjectSet також плавно та лінійно зростає. Розробникам не потрібно виконувати жодних деструктивних операцій, таких як розділення або перенесення самого ObjectSet.

• Ізоляція ресурсів між Set: розподіляючи об'єкти різних діапазонів у різних фізичних кластерах, SetSlice реалізує вищий вимір ізоляції ресурсів. У поєднанні з керуванням квотами ObjectSet, це може ефективно запобігти збільшенню даних певного ObjectSet «супервеликого користувача» від витіснення всіх ресурсів одного кластера, тим самим впливаючи на стабільність інших ObjectSet, роблячи загальний ризик ємності контрольованим.- Логічна єдність і сумісність: для бізнесу та розробників, незалежно від того, скільки Slice знаходиться в основі, вони завжди мають справу з логічно єдиним Agent Bucket. Усі операції з кошиками, ObjectSet та об'єктами залишаються незмінними, реалізуючи повну прозорість фізичного розширення для програм верхнього рівня.

Set AccessPoint: Ізоляція точки входу для кожного користувача

Agent Bucket підтримує відкриття незалежних точок доступу (незалежних доменів) для кожного ObjectSet, а також розширення диференційованих можливостей безпеки, ізоляції та прискорення в точках доступу. Для цього система повинна підтримувати планування незалежних точок доступу рівня мільярдів і диференційовані можливості конфігурації.

Незалежний домен доступу {$apid}.tos-objectset-ap.volces.com: дворівневий захист безпеки

• Перший рівень Obscurity (непрозорість): незалежний субдомен By User/ObjectSet, висока ентропія хешування apid, надзвичайно низька ймовірність колізій, неможливо вгадати та вичерпати конкретну точку входу користувача з точки зору доменного імені доступу;

• Другий рівень Containment (стримування): розробники Agent використовують sts для розповсюдження прав доступу рівня ObjectSet, навіть якщо sts витік, він також може контролювати діапазон доступу, обмежений обмеженим терміном дії певного ObjectSet;

Евристична система планування: обчислення стратегії планування доменів рівня мільярдів

• Диференційована стратегія доступу By user/ObjectSet:tag

• Автоматичне розкидання кількох user/ObjectSet на різні загальнодоступні вхідні точки, кількість користувачів, на яких впливає збій однієї вхідної точки, контролюється

• Еластичне планування по всьому регіону, будь-який збій/перевантаження однієї вхідної точки автоматично завершує переміщення трафіку

• Користувачі загальнодоступного прискореного розповсюдження, позначені тегом прискорення загальнодоступної передачі, автоматично планують точку входу прискорення

• Користувачі загальнодоступного ризику, позначені тегом ризику, автоматично планують загальнодоступну ізольовану точку входу та зменшують квоту загальнодоступної пропускної здатності

• Користувачі внутрішньої мережі між доменами, позначені тегом між доменами, автоматично планують прискорений шлях виділеної лінії внутрішньої мережі

• Користувачі локального прискорювача, позначені тегом прискорювача, автоматично монтують локальний прискорювач

Від помічника з програмування до AI Cloud Disk, безмежні можливості Agent Bucket

Agent Bucket надає Agent повне рішення, і сценарії застосування ObjectSet виходять далеко за рамки цього. Його можна легко розширити до всіх програм, які потребують обслуговування величезної кількості кінцевих користувачів:

• Сховище коду: у минулому, коли підприємства чи окремі особи розміщували код у хмарі, їм часто доводилося будувати «систему орендарів» поверх об’єктного сховища, щоб досягти ізоляції облікових записів і контролю дозволів. Тепер кожному розробнику можна призначити ексклюзивний ObjectSet, щоб об’єднати сховище коду, артефакти збірки та залежності. Agent Skills також природно адаптується до ObjectSet. Завантаження, завантаження та розповсюдження Skills забезпечується ObjectSet для забезпечення суворої ізоляції, щоб уникнути втручання Agent під час виконання.

• Корпоративний фотоальбом/хмарний диск: традиційні фотоальбоми або хмарні диски часто змішують фотографії всіх користувачів в одному кошику та розрізняють користувачів за префіксами. Це не тільки складно керувати, але й схильне до «ефекту сусідства». На основі ObjectSet фотографії та відео кожного користувача потрапляють у власні набори, піки доступу не заважають один одному, а також можна встановити обмеження ємності, стратегії резервного копіювання та методи шифрування для кожного користувача, щоб справді досягти «кожен має безпечний і контрольований хмарний фотоальбом».

• Hadoop Data Warehouse: у корпоративному сховищі даних різні бізнес-лінії та різні бази даних часто спільно використовують ресурси в одному базовому сховищі. Зіставляючи кожну базу даних з ObjectSet, підприємства можуть реалізувати ізоляцію та контроль квот на основі бази даних у єдиному сховищі. Зокрема, ObjectSet надає додатковий рівень дозволів на TOS, забезпечуючи ізоляцію та контроль дозволів для баз даних і таблиць, що зберігаються на TOS, без зміни існуючого Proton on TOS.- Платформа хостингу моделей: У сценаріях хостингу великих моделей кожна модель не тільки має великий обсяг, але й може мати різні версії, ваги та конфігурації висновування. Створення ObjectSet для кожної моделі дозволяє запакувати ваги моделі, Tokenizer, файли конфігурації та відповідні дані оцінювання в один простір. З точки зору експлуатації та обслуговування, можна встановити диференційовані стратегії шифрування, стратегії резервного копіювання та контроль пропускної здатності для різних моделей. У той же час, за допомогою вбудованих можливостей вимірювання можна обчислити фактичну вартість використання кожної моделі, що забезпечує основу для виставлення рахунків за моделлю та планування ресурсів.

• Data SaaS Service: Платформи розповсюдження даних, орієнтовані на велику кількість кінцевих користувачів, часто потребують одночасного підключення до багатьох постачальників даних. Необхідно забезпечити чіткість меж даних кожної сторони та уникнути ризику продуктивності "одна велика бочка тягне всіх вниз". За допомогою Agent Bucket кожен постачальник даних може мати власний ObjectSet, щоб уніфіковано керувати вихідними даними та результатами обробки. Потім, за допомогою незалежних доменних імен і пропускної здатності, квот QPS, можна забезпечити диференційоване обслуговування та обмеження швидкості для різних постачальників, реалізуючи інфраструктуру розповсюдження даних "одна платформа, кілька постачальників, ізольовані один від одного та контрольовані співпрацю".

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/