Ключевые выводы
- Deployment profiles CDP — это не размер «футболки», а архитектурная модель: каждый профиль определяет набор компонентов, а не просто количество серверов
- Minimum (1 узел) закрывает пилот и первый production для 50-150 тыс. профилей — без дополнительных зависимостей
- Recommended (3 узла) покрывает 80% enterprise-сценариев за счёт событийной шины и кеш-слоя
- HA (5 узлов) — для production, где простой клиентского контура недопустим; резервирование каждого компонента
- Переход между профилями — плановая процедура на 2-4 недели, а не миграция с нуля
Один из первых вопросов при внедрении on-prem CDP: сколько серверов нужно? Вопрос звучит просто, но за ним стоит архитектурное решение, которое определит стоимость владения на годы вперёд. Ошибка в обе стороны — перепроектирование «на вырост» и экономия на инфраструктуре — обходится одинаково дорого.
В этом материале разберём три deployment profiles CDP — Minimum, Recommended и HA — и дадим конкретные критерии выбора. Без маркетинговых обещаний, на уровне архитектуры.
Почему deployment profiles CDP — это не про количество серверов
Типичная ошибка при планировании инфраструктуры — считать узлы. «Нам нужно 5 серверов» — фраза, которая ничего не говорит об архитектуре. Поэтому в enterprise-мире используют deployment profiles — предопределённые конфигурации, где каждый профиль определяет не только количество узлов, но и набор компонентов, модель отказоустойчивости и потолок масштабирования.
Для on-prem CDP это особенно важно. В отличие от SaaS, где инфраструктура — проблема вендора, в on-prem ответственность за инфраструктурные решения лежит на вашей команде. Однако правильно спроектированные профили превращают эту ответственность из риска в преимущество — вы точно знаете, что работает и за что платите.
Рассмотрим три профиля, которые покрывают весь спектр enterprise-сценариев — от пилота до критичного production.
Minimum: один узел для старта
Deployment profiles CDP начинаются с Minimum — и это не «урезанная версия». Это полноценный production-ready контур на одном узле, который не требует дополнительных компонентов для базовых сценариев.
| Параметр | Значение |
|---|---|
| Узлы | 1 |
| Ресурсы | 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe SSD |
| Клиентская база | 50-150 тыс. профилей |
| Пользователи | 3-15 |
| Компоненты | Ядро + БД (всё на одном узле) |
| Оркестрация | Docker Compose |
Minimum подходит для двух сценариев: пилотный проект (когда нужно доказать ценность платформы до полноценного внедрения) и первый production у mid-market компании с базой до 150 тыс. клиентов.
Ключевое архитектурное решение Minimum — отсутствие обязательных middleware-зависимостей. Нет отдельной событийной шины, нет внешнего кеша, нет поискового движка. Все функции реализованы внутри ядра и основной БД. Это сознательный выбор: меньше компонентов — меньше точек отказа — проще эксплуатация.
Overprovisioning инфраструктуры на старте увеличивает стоимость владения на 40-60%. Серверы, которые простаивают, не генерируют ценность — но требуют лицензий, мониторинга и обслуживания.
Recommended: три узла для enterprise
Recommended — рабочая лошадка enterprise-внедрений. Три узла — это не «Minimum x3», а качественно другая архитектура с разделением ответственности между компонентами.
| Параметр | Значение |
|---|---|
| Узлы | 3 |
| Ресурсы | 20 vCPU, 64 ГБ RAM, 1,5+ ТБ SSD/NVMe |
| Клиентская база | 150-700 тыс. профилей |
| Пользователи | 10-50 |
| Компоненты | Ядро + БД + событийная шина + кеш + мониторинг |
| Оркестрация | Docker Compose |
Что появляется в Recommended по сравнению с Minimum:
- Событийная шина — асинхронная обработка клиентских событий, триггеры не блокируют основной поток
- Кеш-слой — ускорение запросов к профилям и сегментам, снижение нагрузки на БД
- Мониторинг — метрики производительности, алертинг, дашборды для эксплуатации
- Опциональная аналитика — можно подключить аналитический модуль на отдельном узле
Recommended покрывает 80% enterprise-сценариев. Более того, для большинства компаний с клиентской базой до 500-700 тысяч профилей этот профиль остаётся целевым на 2-3 года вперёд. Переход на HA нужен не «когда вырастете», а когда требования к SLA достигнут уровня «ноль простоя».
HA: пять узлов для критичного production
HA — профиль для компаний, где клиентский контур является бизнес-критичной системой. Банки, телеком, крупный retail с непрерывными коммуникациями — здесь простой CDP напрямую влияет на выручку.
| Параметр | Значение |
|---|---|
| Узлы | 5 |
| Ресурсы | 36 vCPU, 112 ГБ RAM, ~2,9 ТБ SSD/NVMe |
| Клиентская база | Enterprise production с резервированием |
| Компоненты | App x2 + БД primary/standby + Infra node |
| Оркестрация | k3s / lightweight Kubernetes |
Архитектурный принцип HA — отсутствие единой точки отказа. Каждый критичный компонент имеет standby-копию: два узла приложения работают в active-active, БД — в режиме primary/standby с автоматическим failover, инфраструктурный узел обеспечивает мониторинг и оркестрацию.
Тем не менее HA — это не только про надёжность. Два application-узла позволяют делать zero-downtime обновления: один узел обслуживает трафик, второй обновляется, затем роли меняются. Для enterprise с жёсткими окнами обслуживания это критично.
Матрица выбора: какой профиль подходит вам
Вместо субъективных рекомендаций — конкретные критерии. Ответьте на 4 вопроса, и профиль определится однозначно:
| Критерий | Minimum | Recommended | HA |
|---|---|---|---|
| Клиентская база | до 150 тыс. | 150-700 тыс. | 500 тыс.+ |
| Требования к SLA | Допустим плановый простой | Простой до 4 часов | Простой недопустим |
| Стадия проекта | Пилот / первый production | Production 1-3 года | Критичный production |
| Стартовые затраты | от 2,1 млн ₽ | от 4,3 млн ₽ | от 8,1 млн ₽ |
| Сопровождение | от 60 тыс. ₽/мес | от 120 тыс. ₽/мес | от 220 тыс. ₽/мес |
Правило большого пальца: если вы сомневаетесь между двумя профилями — выбирайте младший. Апгрейд на следующий профиль — плановая процедура на 2-4 недели. Downgrade после overprovisioning — потерянные деньги и время.
Путь апгрейда: от Minimum до HA
Архитектура deployment profiles CDP спроектирована так, чтобы переход между профилями был плановым, а не аварийным. Каждый шаг добавляет компоненты, но не требует переписывания конфигурации с нуля.
Minimum → Recommended (2-3 недели)
- Добавление двух узлов в кластер
- Вынос БД на отдельный узел с миграцией через репликацию
- Подключение событийной шины и кеш-слоя
- Настройка мониторинга
Recommended → HA (3-4 недели)
- Добавление двух узлов: второй application и standby БД
- Переход на lightweight Kubernetes (k3s)
- Настройка автоматического failover
- Конфигурация zero-downtime обновлений
Ключевой момент — данные не мигрируют «с нуля». Подключение PostgreSQL standby происходит через нативную репликацию, без остановки production. Приложение начинает работать на новых узлах параллельно, затем нагрузка переключается.
Нюансы, о которых молчат в маркетинговых материалах
Несколько архитектурных нюансов, которые стоит учесть при выборе deployment profiles CDP:
Minimum — не значит «игрушечный». Один узел с 32 ГБ RAM и NVMe SSD — это серьёзная конфигурация. Полнотекстовый поиск, сегментация, триггерные сценарии — всё работает. Ограничение — не в функционале, а в потолке масштабирования и отсутствии резервирования.
Recommended не требует выделенных DBA. Управление БД в рамках Recommended — это стандартные задачи эксплуатации: backup, vacuum, мониторинг размера. Сложные операции (репликация, sharding) появляются только в HA.
HA — когда это НЕ нужно. Если ваш клиентский контур — не бизнес-критичная система 24/7, HA может быть overprovisioning. Batch-сценарии (импорт данных, ночные рассылки, аналитика) прекрасно работают на Recommended с плановым окном обслуживания.
FAQ о deployment profiles CDP
Можно ли начать с Minimum и потом перейти на HA без простоя?
Да, архитектура предполагает плановый апгрейд. Переход Minimum → Recommended занимает 2-3 недели. Recommended → HA — 3-4 недели. Миграция данных происходит без остановки production — через репликацию и поэтапное подключение новых узлов.
Какой профиль выбрать для пилота на 50 тысяч клиентов?
Minimum. Один узел с 8 vCPU и 32 ГБ RAM закрывает пилотные сценарии с запасом. Добавлять компоненты имеет смысл, когда появляются реальные данные о нагрузке — а не на основе прогнозов.
Чем Recommended отличается от Minimum помимо количества узлов?
В Recommended появляются событийная шина для асинхронной обработки, кеш-слой для ускорения запросов и мониторинг. Это не просто «больше железа» — это архитектурное расширение, которое открывает сценарии real-time сегментации и высоконагруженных триггеров.
Обязателен ли HA для соответствия 152-ФЗ?
Нет. 152-ФЗ регулирует обработку и хранение персональных данных, а не отказоустойчивость. HA нужен, когда бизнес не может позволить себе простой клиентского контура — это решение по SLA, а не по compliance.
Итого
Выбор deployment profiles CDP — это архитектурное решение, которое определяет баланс между стоимостью владения, потолком масштабирования и уровнем отказоустойчивости. Minimum для старта, Recommended для большинства enterprise-сценариев, HA для бизнес-критичных контуров — и плановый путь апгрейда между ними.
Главное правило: начинайте с профиля, который закрывает текущие требования, а не гипотетические. Overprovisioning обходится дороже, чем плановый апгрейд.
Если вы планируете развёртывание on-prem CDP и хотите определить оптимальный профиль для вашего сценария — запросите архитектурную консультацию. Разберём нагрузку, интеграции и SLA-требования и подберём конфигурацию с запасом, но без переплаты.