Требования к вычислительным ресурсам

Deckhouse Development Portal (DDP) устанавливается модулем development-platform в кластере Deckhouse Platform (DP).

Для разных сценариев установки выделите следующие CPU, память и диск:

Бюджет DDP включает API, веб-интерфейс, платформенный AI-агент и воркеры. Для демо-установки рекомендуется режим managed для баз данных, для остальных профилей — режим external.

Бюджет для каждой внешней базы данных указан на один сервер. Он рассчитан по сценариям и допущениям ниже. CPU рассчитан по частоте и стоимости операций, память — по рабочему набору данных и параллельности, диск — по накопленным данным и месту для обслуживания. Дополнительно учтите ресурсы всех реплик, резервного копирования и служебных компонентов.

Расчёт охватывает первые 180 дней эксплуатации. Как получены значения, описано в расчёте CPU и памяти и в расчёте дискового пространства.

Бюджет портала — это свободные ресурсы для подов DDP. Дополнительно учтите потребление DP, операционной системы, других приложений, временных подов при обновлении и запас на отказ узлов.

Требуется DP версии 1.72 или новее с доступным модулем development-platform, модуль user-authn и постоянное хранилище для баз данных в кластере. Порядок установки и подключения баз данных приведён в руководстве по установке.

Демо-установка

Сценарий демо-установки предполагает одного пользователя, небольшой каталог и выполнение одного-двух процессов одновременно. Для демо-установки используйте PostgreSQL, Redis и ClickHouse в режиме managed. До установки включите модули DP managed-postgres, managed-valkey и managed-clickhouse. В этом режиме Redis заменяется совместимым с ним Valkey. ClickHouse хранит историю параметров, доступную для демонстрации возможностей портала.

Для DDP вместе с managed-экземплярами баз данных выделите следующие ресурсы в уже работающем кластере DP:

Бюджет компонентов портала для демо составляет 4 CPU и 8 GB памяти. Managed-экземпляры по умолчанию добавляют 5 CPU по сумме лимитов и 14 GB памяти. Сумма составляет 9 CPU и 22 GB памяти. При coreFraction: 50 для PostgreSQL и coreFraction: "50%" для Valkey и ClickHouse гарантированный запрос CPU managed-экземпляров составляет суммарно 2,5 CPU. Бюджет рассчитан по полным лимитам CPU.

При двух процессах с двумя активными шагами каждый воркер сможет выполнять четыре задачи процессов и одну дополнительную фоновую задачу одновременно. Ресурсы самой DP, образы контейнеров и временный диск добавляются к этому бюджету.

Добавьте следующие настройки в ModuleConfig development-platform. Остальные параметры установки не меняйте:

spec:
  settings:
    postgres:
      mode: managed
    redis:
      mode: managed
    clickhouse:
      mode: managed
    workers:
      replicas: 1
      maxTasks: 5

В примере используются ресурсы managed-экземпляров по умолчанию. Чтобы изменить их, задайте CPU в instance.cpu, память в instance.memory и размеры томов в instance.persistentVolumeClaim.size, затем пересчитайте суммарный бюджет. Класс managed-экземпляра должен допускать выбранные CPU, память и размеры томов. Параметры экземпляров описаны в руководстве по установке с managed-экземплярами.

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

Сценарии нагрузки

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

Выбирайте профиль по всем параметрам сценария вместе. Число зарегистрированных пользователей влияет на накопление запусков процессов, а число активных пользователей — на частоту запросов к API и базам данных. Установка на 10 пользователей с частыми синхронизациями большого каталога может потребовать больше воркеров, чем профиль на 100 пользователей. Число сущностей само по себе также не задаёт необходимую память: учитывайте размер параметров и объём одной синхронизации.

API, веб-интерфейс и платформенный AI-агент работают по одной реплике в каждом профиле. Количество воркеров повышает параллельность фоновых задач. Для профиля на 1000 пользователей отдельно проверьте производительность API и баз данных. Увеличение числа воркеров не повышает производительность всех компонентов одновременно.

Допущения расчёта

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

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

Ресурсы компонентов DDP

Для профилей на 10–1000 пользователей бюджет складывается из следующих ресурсов компонентов. В таблице указаны приблизительные значения на один экземпляр до округления:

Для N воркеров сумма ресурсов API, веб-интерфейса, AI-агента и воркеров составляет 6 + 2 × N CPU и около 11,81 + 8,59 × N GB памяти. Например, для двух воркеров сумма для портала равна 6 + 2 × 2 = 10 CPU и примерно 11,81 + 8,59 × 2 = 28,99 GB памяти. После округления вверх бюджет составит 16 CPU и 32 GB памяти без баз данных.

Расчёт CPU и памяти баз данных

Расчёт CPU исходит из пиковой частоты операций и их стоимости в процессорном времени. Расчёт включает двукратный запас на различия CPU и целевую загрузку до 50%. Поэтому потребление Σ(операций в секунду × мс CPU на операцию) / 1000 умножается на 4, после чего округляется вверх до степени двойки.

Стоимость типичных операций принята по измерениям запросов и команд с синтетическими данными. Для запросов истории использована история одной сущности из 900 записей за 180 дней:

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

CPU и память PostgreSQL

Расчёт CPU учитывает чтения пользователей, поиск и пиковый поток изменений от синхронизаций. Минимальный бюджет в модели составляет 2 CPU. Например, в профиле на 1000 пользователей работают 200 активных пользователей и поступает до 579 изменений сущностей в секунду в пике. Расчётное потребление составляет около 2,1 CPU. После умножения на 4 и округления бюджет равен 16 CPU.

Рабочий набор памяти включает текущий каталог, события за 5 дней и данные запусков за последние 30 календарных дней, приблизительно 22 рабочих дня. Объём рабочего набора умножается на 1,5 для индексов и кеширования. Расчёт дополнительно добавляет служебный запас 2 GB, 32 MB на чтение каждого активного пользователя и по 8 MB на каждое из 10 параллельных обновлений одной фоновой задачи. Минимальный бюджет памяти в модели составляет 8 GB. Учтите параллельные операции и соединения также в настройках PostgreSQL. PostgreSQL расходует память сортировок и хеш-операций на каждую операцию, как описано в документации PostgreSQL.

CPU и память Redis

В расчёт CPU входят следующие операции Redis:

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

На событие учтены запись, продление срока хранения и чтение с подтверждением двумя получателями. Расчёт дополнительно учитывает до 35 коротких команд в секунду на воркер и до 2 обращений в секунду на активного пользователя. В профиле на 1000 пользователей это около 4500 команд в секунду. Минимальный бюджет в модели равен 2 CPU, включая запас на сохранение данных. Для указанных частот расчёт CPU остаётся в этом бюджете.

Для памяти расчёт учитывает полные потоки: число ресурсов каталога × 10 000 событий. Лимит действует на каждый поток ресурса отдельно. Redis соблюдает его приблизительно. Новое событие продлевает срок жизни всего потока. Срок хранения событий в PostgreSQL не ограничивает возраст событий активного потока Redis. При изменении events.streamMaxLen пересчитайте объём потоков. При значении 0 или меньше ограничение длины отключается.

К событиям расчёт добавляет очередь из 10 000 задач и результаты завершённых задач за 3 минуты. Общий объём умножается на 1,3 для структур Redis и ещё на 2 для временной копии при сохранении данных. Расчёт добавляет 0,5 GB служебного запаса и по 1 MB буферов на активного пользователя. Минимальный бюджет памяти в модели равен 4 GB.

В профиле на 1000 пользователей полезные данные занимают около 8,54 GB. Расчёт с запасами даёт около 23 GB и округляется до 32 GB. Влияние сохранения данных описано в документации Redis.

CPU и память ClickHouse

Расчёт CPU учитывает запросы истории, восстановление параметров на дату, вставку изменений и фоновые слияния. При 20 запросах истории в секунду и пиковых 579 вставках в секунду расчётное потребление составляет около 0,32 CPU. После умножения на 4 потребление остаётся ниже минимального бюджета модели в 4 CPU. Поэтому CPU в указанных профилях одинаковый.

Расчёт памяти складывается из 8 GB служебного запаса, 0,5 GB на каждого пользователя, который одновременно просматривает историю, и кеша размером 25% объёма истории за последний месяц. Расчёт дополнительно учитывает четыре копии пакета из 10 000 записей при обработке вставки. Минимальный бюджет памяти в модели равен 16 GB. Для профиля на 1000 пользователей расчёт даёт около 22 GB и округляется до 32 GB. Расход памяти на чтение и слияния зависит от запроса, а не только от числа возвращённых строк. Зависимость ресурсов от запросов описана в рекомендациях ClickHouse.

Для нескольких серверов базы данных умножьте бюджет на их число. Если сервер обслуживает другие приложения, добавьте ресурсы для DDP к бюджетам этих приложений.

От чего зависит потребление

Основные источники нагрузки различаются по компонентам. Перед выбором профиля соберите следующие параметры:

При синхронизации DDP обрабатывает коллекцию полученных объектов и загружает сущности соответствующего ресурса каталога. Крупная выборка повышает расход памяти даже при небольшом числе пользователей. Уменьшение числа параллельных синхронизаций снижает их одновременное потребление памяти.

Ресурсы сервиса AI-модели и GPU при самостоятельном размещении модели учитывайте отдельно. Для рабочих пространств отдельно просуммируйте запросы CPU, памяти и хранилища из шаблонов всех одновременно запущенных рабочих пространств. Добавьте ресурсы задач подготовки. Бюджеты профилей включают постоянные компоненты портала. Рабочие пространства, среды разработки, CI-задачи и приложения, которые создают через DDP, добавляются к бюджетам профилей.

Расчёт количества воркеров

Один воркер обрабатывает до workers.maxTasks задач из очереди одновременно. Общий предел параллельности равен workers.replicas × workers.maxTasks. В профилях используется workers.maxTasks: 10, поэтому для 10, 20, 40, 60 и 80 задач профили используют 1, 2, 4, 6 и 8 воркеров. Настройка описана в разделе «Воркеры».

Число выполняющихся процессов и число занятых мест воркеров различаются. Один процесс с параллельными ветками может занимать несколько мест. Процесс не занимает место воркера, пока ждёт подтверждения пользователя. В общий расчёт включайте также синхронизации, проверки статуса, вызовы MCP и запуски AI-агентов. Запуск AI-агента из процесса занимает место до завершения задачи. Перенос истории в ClickHouse и её очистка выполняются дополнительно к задачам очереди и также потребляют ресурсы воркеров.

Для постоянного потока задач оцените среднее число занятых мест как сумму λ × t по всем типам задач. Здесь λ — число поступающих задач в секунду, t — средняя длительность задачи в секундах. Например, 2 задачи в секунду длительностью 5 секунд занимают в среднем 10 мест. При workers.maxTasks: 10 такой поток полностью загружает один воркер. Добавьте запас параллельности для пиков и длительных задач. Пределы параллельности профилей не задают производительность в задачах в секунду.

Увеличение workers.maxTasks повышает одновременное потребление памяти одним подом и число обращений к PostgreSQL и внешним системам. Например, одна синхронизация может обновлять параметры до 10 сущностей параллельно. При десяти таких задачах по разным ресурсам каталога в одном воркере возможно до 100 параллельных операций обновления параметров. Перед увеличением параллельности проверьте соединения с PostgreSQL и ограничения внешних API.

Расчёт дискового пространства

В демо-установке используются следующие размеры постоянных томов managed-экземпляров:

Эти размеры заданы по умолчанию для managed-экземпляров. Они не увеличиваются при изменении числа пользователей или воркеров. При росте данных увеличьте тома или перейдите к профилю с выделенными базами данных. При размещении баз данных в кластере дополнительно учтите репликацию хранилища и резервные копии.

В профилях на 10–1000 пользователей диск каждой базы данных должен быть не меньше её тома в демо-установке. После округления вверх до степени двойки минимальные бюджеты составляют 32 GB для PostgreSQL, 16 GB для Redis и 64 GB для ClickHouse. Для каждого профиля выберите больший из минимального бюджета и бюджета по расчёту ниже.

Диск PostgreSQL

Объём полезных данных D складывается из:

• текущего каталога: число сущностей × 2 KB;
• событий: число сущностей × 5 изменений × 5 дней × 8 KB;
• запусков процессов и действий: число пользователей × 2 запуска × 129 рабочих дней × 256 KB;
• очереди переноса истории за сутки: число сущностей × 5 изменений × 1 KB.

В модели D удваивается для индексов и места, которое расходуют обновления записей. Для журнала предзаписи (WAL) расчёт добавляет больший из двух запасов: 8 GB или двукратный суточный объём записываемых данных. Суточный объём записи складывается из изменений каталога число сущностей × 5 × (2 + 8 + 1) KB и данных запусков число пользователей × 2 × 256 KB в рабочий день. Бюджет диска равен (2 × D + запас WAL) / 0,7, округлённым вверх до степени двойки. Минимальный бюджет составляет 32 GB и покрывает том 20 GB из демо-установки. Деление на 0,7 оставляет 30% свободного места.

Для 1000 пользователей полезные данные занимают около 88,83 GB. С учётом индексов, обновлений, WAL и свободного места требуется около 271 GB. После округления бюджет составляет 512 GB.

Этот расчёт охватывает данные заданного сценария. Диалоги AI, крупные контексты процессов, дополнительные связи и более подробные логи увеличивают объём.

Срок хранения событий events.ttl, по умолчанию 96h, не задаёт срок хранения всех данных DDP. 180 дней для запусков процессов — горизонт планирования, а не автоматический срок удаления.

Если перенос истории в ClickHouse задерживается больше суток, увеличьте запас места под очередь в PostgreSQL пропорционально времени задержки. Для WAL также учтите фактические настройки и возможное отставание реплик.

Диск Redis

Полезный объём B включает потоки событий, очередь задач и временные результаты. Как рассчитать их объём, описано в разделе о памяти Redis. Бюджет диска предусматривает три копии объёма 1,3 × B: сохраняемые данные и место для снимка, журнала AOF и его перезаписи. Расчёт дополнительно добавляет час записей при пиковой частоте событий и завершений задач.

При p событиях и q завершениях задач в секунду часовой объём записи равен (p × 8 KB + q × (16 + 64) KB) × 3600. Бюджет диска равен (3 × 1,3 × B + часовой объём записи) / 0,7, округлённым вверх до степени двойки, с минимумом 16 GB, который покрывает том 10 GB из демо-установки. Для профиля на 1000 пользователей расчёт даёт около 79 GB и округляется до 128 GB.

Бюджет рассчитан для включённого сохранения данных с регулярной перезаписью журнала AOF. При другой политике RDB/AOF, редкой перезаписи или длительной записи на пиковой скорости пересчитайте место под журнал AOF и временные файлы. Диск Redis не заменяет память: потоки, очереди и результаты должны помещаться в RAM.

Диск ClickHouse

Объём истории равен E × Δ × T × S, где:

• E — число сущностей;
• Δ — число изменений отдельных параметров одной сущности в сутки;
• T — срок хранения в сутках;
• S — средний размер записи об изменении.

Повторная синхронизация значения, которое не изменилось, не считается изменением параметра. По умолчанию история хранится 180 дней. Срок задаёт параметр clickhouse.propertyHistory.retentionDays.

В профилях приняты 5 изменений параметров на сущность в сутки и размер записи 1 KB до сжатия. Выигрыш от сжатия в расчёте не учитывается. Бюджет диска включает 16 GB базового запаса, место для истории и её временной копии при обслуживании, а также 30% свободного пространства. Итоговый бюджет равен (16 + 2 × объём истории) / 0,7 GB, округлённым вверх до степени двойки, с минимумом 64 GB, который покрывает том 50 GB из демо-установки:

Выберите том не меньше расчётного бюджета. При изменении частоты изменений, размера записей или срока хранения пересчитайте бюджет диска. Сжатие уменьшает фактический объём данных. Слияния частей и отставание очистки увеличивают временное потребление диска.

Временный диск DDP

На узлах отдельно выделите временное дисковое пространство. API и воркеры используют временные тома emptyDir, в том числе для кеша и работы с репозиториями. Запрос модуля на ephemeral-storage составляет около 0,052 GB на контейнер и покрывает только логи. Клонируемые репозитории, пакеты шаблонов и образы контейнеров в этот запрос не входят.