Агенты искусственного интеллекта — ваши новые пользователи, и они требуют нового подхода к инфраструктуре данных. Макс Лю, соучредитель и генеральный директор TiDB, приводит на портале The New Stack контрольный список для оценки вашей готовности.
Команды данных, преуспевшие в последней волне масштабирования платформ «ПО как услуга» (SaaS), не гнались за ажиотажем. Они приняли несколько разумных решений: внедрили облачные операции, сделали видимыми затраты и ресурсы, а также выбрали архитектуры, которые могли быстро адаптироваться к меняющимся условиям.
Как оказалось, именно эти методы требуются в эпоху агентных систем.
Если вы посмотрите, как команды данных управляют переходом на ИИ, вырисовывается четкая закономерность: тем, у кого был жесткий контроль над производительностью и расходами, оказалось проще всего поддерживать агентов. Они уже практиковали изоляцию арендаторов. Они уже вносили оперативные изменения в рабочее время. Они уже использовали восстановление на основе объектного хранилища. Все, что агенты от них потребовали, они уже делали. Они просто применили те же принципы, которые уже использовали, к новому типу пользователей.
Начнем с этой предпосылки: агенты — ваши новые пользователи. Мы рассмотрим, чем они отличаются от других пользователей и как лучше всего их поддерживать. Попутно мы обсудим четыре архитектурных фактора, влияющих на возможность работы в масштабе. И завершим контрольным списком, который вы можете использовать для оценки пригодности вашей текущей платформы для рабочих нагрузок, управляемых агентами.
Агенты — ваши новые «пользователи»
Большинство платформ данных были созданы для людей и сервисов с относительно стабильными, предсказуемыми потребностями. Агентные системы совершенно другие. Они запускают приложения с коротким сроком жизни, проводят эксперименты, запускают миграции, создают новые наборы данных и все это удаляют — часто параллельно и непредсказуемо.
Это можно видеть на примере компаний, которые предлагают универсальные платформы агентного ИИ, чьи рои агентов для «широких исследований» ежедневно запускают тысячи кратковременных рабочих нагрузок. Речь идёт уже не об управлении единой монолитной базой данных, а об организации за кулисами миллионов крошечных, временных, похожих на ветви сред.
В масштабе агентам нужна не монолитная, постоянно растущая база данных. По сути, нужны миллионы крошечных, изолированных баз данных или ветвей, появляющихся и исчезающих. Как только вы принимаете эту предпосылку, естественным образом вытекают четыре требования к агентным архитектурам:
- Изоляция по умолчанию. Границы для каждого арендатора или агента предотвращают превращение экспериментов в проблему для всех.
- Оперативные изменения в рабочее время. Схемы и индексы должны быть настраиваемыми в пределах задержек p95/p99 в рамках целевых показателей уровня обслуживания (SLO).
- Размещение и квоты. Горячие данные должны храниться рядом с вычислительными ресурсами с низкой задержкой; холодные данные могут размещаться в недорогом хранилище; а «шумные» арендаторы должны быть изолированы.
- Автоматизация жизненного цикла. Необходима возможность создавать и удалять среды за считанные секунды с гигиеной чистоты метаданных и распределением затрат.
Вот четыре архитектурных решения, которые поддерживают потребности ваших агентов:
1. Два важных аспекта масштабируемости
Агенты могут быстро потреблять общие ресурсы. Чтобы этого не происходило, разделите вычисления и хранение, чтобы вы могли добавлять мощности без перемещения данных. Затем разделите вычислительные ресурсы, чтобы выделить для оперативной обработки транзакций (OLTP), аналитики и обслуживания отдельные каналы и SLO.
- Разделение вычислений и хранения. Подключение SQL/вычислительных механизмов без сохранения состояния к надежному общему объектному хранилищу позволяет:
- Масштабироваться эластично: добавление и удаление мощностей без необходимости высокоскоростного копирования данных или миграции в выходные дни.
- Восстанавливаться предсказуемо: новые узлы могут получать состояние из хранилища и «теплых» кэшей и начинать обслуживание, не перегружая другие узлы.
- Быстро клонировать: ветви с копированием при записи могут быть быстро созданы из метаданных, а не из полных физических копий.
Что нужно проверить:
- Можно ли добавлять вычислительные узлы за считанные минуты без перебалансировки данных?
- Используют ли новые узлы объектное хранилище, а не другие узлы?
- Являются ли клонирование и ветвление инкрементальными и эффективными с точки зрения использования пространства?
Разделение вычислений. Когда тысячи агентов одновременно разветвляют данные, создают индексы и отправляют запросы, SQL-интерфейсы, аналитические средства чтения, фоновое обслуживание (компактирование, обратная заливка), резервное копирование/восстановление и плоскости управления должны масштабироваться и управляться независимо, чтобы обеспечить их бесперебойную работу.
Что нужно проверить:
- Можно ли ограничивать скорость обратной заливки независимо от трафика OLTP?
- Имеют ли аналитические сканирования собственные ресурсы и ограничения?
- Можно ли выполнить обновление версий для одной плоскости без использования окна для другой?
2. Сделайте затраты видимыми (и действенными)
Традиционные платформы данных часто недогружают ЦП на
Таким образом, инженеры будут знать, какие запросы нужно оптимизировать и какой экономии ожидать. Отделы разработки продуктов и финансов могут устанавливать бюджеты и лимиты, соответствующие реальной работе, а платформенные команды могут рекомендовать улучшения, основываясь на фактических затратах, а не на интуиции.
Что нужно проверить:
- Можете ли вы относить затраты к арендаторам, приложениям и дайджестам запросов?
- Можете ли вы автоматически обеспечивать соблюдение бюджетов и лимитов?
- Есть ли у вас цикл «Top Five Digests», связанный с регрессионными тестами задержки и стоимости?
3. Используйте объектное хранилище в качестве основы
Для агентных архитектур использование объектного хранилища (S3/Google Cloud Storage/Azure Blob и т. п.) в качестве основы данных является обязательным. Это обеспечивает масштабирование с учетом контекста за счет извлечения данных из общего объектного хранилища и локального кэширования горячих данных для обеспечения сверхнизкой задержки, гарантируя, что база данных всегда будет нужного размера в данный момент. Во время масштабирования или восстановления новые вычислительные ресурсы должны извлекать состояние из надежного хранилища, а не копировать его с других узлов. Там же должны храниться и резервные копии и долгосрочные снимки.
Преимущества:
- Предсказуемое масштабирование и восстановление: меньше межузловых сбоев во время роста или обработки отказа.
- Многоуровневая экономика: можно продумать и заложить в бюджет пути горячих/теплых/холодных ресурсов.
- Быстрое ветвление базы данных: клонирование базы данных становится операцией с указателями плюс семантика объектного хранилища.
Что нужно проверить:
- Хранятся ли резервные копии, снимки и метаданные ветвлений в объектном хранилище по умолчанию?
- Сколько времени требуется новому узлу для начала обработки трафика после сбоя?
- Можно ли автоматически удалять ненужные ветви и объекты с помощью сборщика мусора?
4. Рассматривайте оперативные изменения как первостепенную возможность
Когда вашими пользователями являются агенты, изменения происходят постоянно. Эволюция схемы, индексирование, перемещение данных и обновления должны происходить в режиме онлайн, с четкой видимостью происходящего.
Вот как это выглядит на практике:
- Изменения трехфазной схемы (подготовка → реорганизация → фиксация) с многоверсионным управлением параллелизмом, чтобы чтение-запись продолжались во время выполнения обратной заливки.
- Обслуживание с ограничением скорости, учитывающее бюджеты p95/p99.
- Поэтапные обновления с автоматическим выбором лидера и без перерывов на обслуживание.
Что нужно проверить:
- Можно ли добавить индекс к горячей таблице в пиковый период и удерживать p95/p99 в рамках SLO?
- Являются ли блокировки метаданных короткими и предсказуемыми?
- Встроены ли в конвейер предварительные проверки, пороговые значения для прерывания и план отката?
Антипаттерны, которых следует избегать
Выше речь шла о том, чего вам следует постараться добиться. А вот чего следует избегать:
- Сложность сегментирования: сегментирование на уровне приложения выглядит простым до тех пор, пока вам не приходится самостоятельно выполнять маршрутизацию, перебалансировку, обработку отказа и перекрестные объединения сегментов.
- Один большой пул: если рассматривать все вычисления как взаимозаменяемые, это приведет к возникновению инцидентов с шумными соседями и резкому увеличению задержки.
- Невидимые затраты: выставление счетов на уровне экземпляра скрывает потери, связанные с каждым запросом; помните, что вы не можете управлять тем, чего не видите.
- Зависимость от однорангового копирования: процессы восстановления и масштабирования, зависящие от загруженных соседей, могут рухнуть под давлением.
Контрольный список для оценки минимальной готовности
Используйте следующий контрольный список для сравнения платформ для агентных рабочих нагрузок:
- Подготовка баз данных. Сколько изолированных баз данных, схем и ветвей вы можете создать в минуту? Как они отслеживаются и выводятся из эксплуатации?
- Два уровня разделения. Проверка независимости вычислений и хранения, а также независимости вычислений друг от друга при реальной нагрузке.
- Модель затрат. Насколько хорошо инженеры могут отслеживать стоимость каждого запроса для каждого арендатора/приложения? Какие существуют ограничения и как они обеспечиваются?
- Объектное хранилище. Демонстрация подключения и восстановления узлов с использованием объектного хранилища. Измерение времени обслуживания.
- Оперативные изменения. Тестирование возможности добавления индекса в пиковые нагрузки; проверка p95/p99, частоты ошибок и пороговых значений прерывания.
- Тренировка на случай сбоя. Отключение лидера или зоны доступности (AZ); наблюдение за выборами, повторными попытками клиентов и задержкой завершения.
- Чистота метаданных. Доказательство того, что заброшенные ветви и объекты удаляются сборщиком мусора без ручного создания тикетов.
Агентные системы не требуют совершенно нового подхода к инфраструктуре. Правильная архитектура для агентов — это правильная архитектура для любого крупномасштабного современного сценария использования. Новизна в том, что агенты являются движущей силой.
Команды данных не могут позволить себе роскошь придерживаться монолитных платформ, которые медленно масштабируются и сложны в управлении. Агенты поставят эти старые архитектуры на колени. Но, как показали самые успешные команды данных, если проектировать с учетом гибкости, прозрачности и производительности, используя описанные выше методы, вы будете выпускать продукты быстрее и с меньшим количеством экстренных ситуаций по выходным, даже когда число ваших «пользователей» исчисляется миллионами — и большинство из них не люди.
