DigitalOcean раскрыла архитектуру MicroVM для Managed Agents

DigitalOcean раскрыла архитектуру MicroVM для Managed Agents. Фото: из архива компании

Инженер Брейден Бассингтуэйт подробно объяснил, как платформа решает фундаментальную проблему агентных нагрузок: агент запускает тесты, редактирует файлы, вызывает модели и ждёт, а затем возобновляет работу с теми же процессами, файлами и контекстом, иногда требуя ответвления среды для параллельной проверки двух подходов.

Традиционная инфраструктура вынуждает выбирать между постоянным расходом ресурсов на простаивающие сессии и полной пересборкой окружения при каждом взаимодействии, поскольку сохранение файловой системы не удерживает работающий интерпретатор, индекс в памяти или процесс на середине задачи.

Именно поэтому Harness Runtime выделяет каждой сессии отдельную microVM на базе Firecracker с аппаратной виртуализацией KVM, а платформа MicroVM управляет изоляцией, сетью, хранилищем и восстановлением из контрольных точек, тогда как Action Gateway обеспечивает управляемый доступ к инструментам.

Ключевое архитектурное решение заключается в разделении сессии и хоста, на котором она выполняется. Гостевая система сохраняет стабильную сетевую конфигурацию, неизменяемое хранилище содержит её дисковые и мнемонические контрольные точки, а хостовые прокси применяют сетевые политики и могут подключать учётные данные, не помещая их в гостевую среду.

Вместо глобального планировщика платформа использует ячейку — самодостаточный экземпляр уровня региона с собственным VPC, кластером DigitalOcean Kubernetes, управляемой базой PostgreSQL, бакетом Spaces и пулом гипервизорных хостов. Ячейка даёт повторяемую единицу ёмкости и изоляции сбоев, хотя и не устраняет общие региональные зависимости. Внутри ячейки выделяются плоскость управления на Kubernetes, принимающая решения о жизненном цикле, размещении и долговечных метаданных, и плоскость хостов на гипервизорных Droplets, где работают Firecracker и сервисы гостевой сети, дисков и памяти.

Отдельного внимания заслуживает сетевая модель. Каждый восстановленный гость получает один и тот же IP-адрес 192.168.240.2, шлюз 192.168.240.1 и фиксированные MAC-адреса, поскольку контрольная точка сохраняет сетевое представление гостевого ядра вместе с памятью приложения.

Смена адресов потребовала бы изменения этого сохранённого состояния, а ветвление сделало бы проблему ещё серьёзнее, ведь каждый форк начинается с одинаковой конфигурации в памяти. Коллизий не возникает, потому что каждое выполнение имеет собственное сетевое пространство имён Linux с TAP-интерфейсом и veth-соединением, а NAT транслирует между хостовым адресом выполнения и фиксированным гостевым адресом.

Фиксированный MAC-адрес шлюза решает тонкую, но важную проблему: если гость сохранил ARP-запись, а восстановление создаст TAP-устройство со случайным MAC, кэшированная запись будет указывать в никуда и даже ответы на входящие соединения могут зависнуть.

Сетевые политики вынесены за пределы управляемого кода, поскольку агенты выполняют код, не проверенный построчно. Переменная окружения с прокси не является границей безопасности, так как код может её проигнорировать, открыть собственный сокет или использовать другой HTTP-клиент.

Поэтому платформа устанавливает правила nftables на уровне пространства имён, блокирующие новые гостевые соединения в обход прокси, после чего Envoy применяет настроенный список разрешённых назначений. Отдельно реализовано внедрение учётных данных: для поддерживаемых HTTP-интеграций привязка учётных данных определяет точное имя хоста, заголовок, авторизационный дескриптор и опциональный префикс пути, а хост получает значение из внутреннего менеджера секретов по mTLS и передаёт его Envoy через механизм SDS.

Гость получает разрешение выполнить аутентифицированный запрос через прокси, но не копию самого API-ключа, что снижает один из источников утечки, хотя и не делает безопасной любую операцию с разрешённым API. Для внедрения заголовка в HTTPS Envoy должен терминировать TLS-соединение гостя, что требует доверия к контролируемому платформой центру сертификации, поэтому корневой отпечаток перехвата записывается в контрольные точки, а доверие устанавливается до запуска рабочих процессов.

Хранилище решает ту же задачу переносимости между хостами: диск состоит из неизменяемой основы в content-addressed storage и приватного локального writable-оверлея для каждого выполнения, которые microvm-ublk представляет как блочное устройство Linux через ublk. Оверлей — это разреженный дельта-файл с одним битом карты на блок в 4 КиБ, где установленный бит означает владение блоком, а чтение идёт от новейшего оверлея к неизменяемой основе.

Даже запись нулей требует установки бита, иначе старые данные родителя проявятся вновь. Индекс в стиле casync описывает упорядоченные чанки с границами, определяемыми содержимым, что переносит требование запуска с загрузки всего диска на обеспечение его адресуемости.

Контрольная точка при этом включает не только диск, но и память с состоянием ядра и процессов, а также состояние устройств и vCPU, причём захват и публикация идут по разным часам: захват требует согласованного мгновения, публикация — времени на перемещение больших артефактов.

Восстановление памяти использует Linux userfaultfd, позволяя отложить загрузку: Firecracker загружает снимок устройств с приостановленной VM и передаёт userfaultfd сервису памяти, после чего возобновляет vCPU, так что первая ошибка страницы всегда находит обработчик.

Как подчёркивает автор, платформа откладывает загрузку, а не устраняет её, а тёплый путь от запроса на выполнение до обслуживания трафика укладывается в менее 200 миллисекунд на p50 во внутреннем тестировании благодаря заранее построенной сети, новому writable-диску поверх общих данных и восстановленной машине, загружающей лишь те страницы, к которым обращается.