Эталонные архитектуры¶
Эталонные архитектуры AppSec.Code — это проверенные, готовые к использованию проекты среды для развертывания AppSec.Code в большом масштабе. Каждая архитектура предоставляет подробные спецификации, которые вы можете использовать или адаптировать в соответствии со своими требованиями.
Доступные эталонные архитектуры¶
Следующие эталонные архитектуры доступны в качестве рекомендуемых отправных точек для вашей среды.
Архитектуры названы в соответствии с пиковой нагрузкой, основанной на количестве пользователей или количествах запросов в секунду (RPS). RPS рассчитывается на основе усредненных реальных данных.
Каждая архитектура спроектирована так, чтобы быть масштабируемой и эластичной. Их можно соответственно отрегулировать в зависимости от вашей рабочей нагрузки, в сторону увеличения или уменьшения. Например, некоторые известные «тяжелые» сценарии, такие как использование больших монорепозиториев или значительные дополнительные рабочие нагрузки.
20 RPS или 1000 пользователей¶
Целевая нагрузка: API: 20 RPS (Requests Per Second, запросов в секунду), Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS.
Высокая доступность: Нет.
Для высокой доступности обратитесь к архитектуре 60 RPS или 3000 пользователей.
| Компонент | Минимум | Рекомендовано для стабильности |
|---|---|---|
| CPU | 4 ядра | 8+ ядер |
| RAM | 8 ГБ | 16–32 ГБ |
| Диск | SSD, 100 ГБ | SSD, 200+ ГБ, NVMe для больших репозиториев |
| Сеть | 1 Гбит/с | 1 Гбит/с |
| База данных | Встроенный PostgreSQL (Omnibus) | Внешний PostgreSQL для больших нагрузок |
40 RPS или 2000 пользователей¶
Целевая нагрузка: API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS.
Высокая доступность: Нет.
Для высокой доступности обратитесь к архитектуре 60 RPS или 3000 пользователей.
Рекомендованная минимальная конфигурация сервера:
| Сервис | Ноды | Конфигурация |
|---|---|---|
| Внешний балансировщик нагрузки | 1 | 4 vCPU, 3.6 ГБ памяти |
| PostgreSQL | 1 | 2 vCPU, 7.5 ГБ памяти |
| Redis | 1 | 1 vCPU, 3.75 ГБ памяти |
| Gitaly | 1 | 4 vCPU, 15 ГБ памяти |
| Sidekiq | 1 | 4 vCPU, 15 ГБ памяти |
| GitLab Rails | 2 | 8 vCPU, 7.2 ГБ памяти |
| Узел мониторинга | 1 | 2 vCPU, 1.8 ГБ памяти |
60 RPS или 3000 пользователей¶
Целевая нагрузка: API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS.
Высокая доступность: Да, но для Praefect требуется стороннее PostgreSQL решение.
Рекомендованная минимальная конфигурация сервера:
| Сервис | Ноды | Конфигурация |
|---|---|---|
| Внешний балансировщик нагрузки | 1 | 4 vCPU, 3.6 ГБ памяти |
| Consul | 3 | 2 vCPU, 1.8 ГБ памяти |
| PostgreSQL | 3 | 2 vCPU, 7.5 ГБ памяти |
| PgBouncer | 3 | 2 vCPU, 1.8 ГБ памяти |
| Внутренний балансировщик нагрузки | 1 | 4 vCPU, 3.6 ГБ памяти |
| Redis/Sentinel | 3 | 2 vCPU, 7.5 ГБ памяти |
| Gitaly | 3 | 4 vCPU, 15 ГБ памяти |
| Praefect | 3 | 2 vCPU, 1.8 ГБ памяти |
| Praefect PostgreSQL | 1+ | 2 vCPU, 1.8 ГБ памяти |
| Sidekiq | 2 | 4 vCPU, 15 ГБ памяти |
| GitLab Rails | 3 | 8 vCPU, 7.2 ГБ памяти |
| Узел мониторинга | 1 | 2 vCPU, 1.8 ГБ памяти |
| Объектное хранилище (Object Storage) | - | - |
100 RPS или 5000 пользователей¶
Целевая нагрузка: API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS.
Высокая доступность: Да, но для Praefect требуется стороннее PostgreSQL решение.
Рекомендованная минимальная конфигурация сервера:
| Сервис | Ноды | Конфигурация |
|---|---|---|
| Внешний балансировщик нагрузки | 1 | 4 vCPU, 3.6 ГБ памяти |
| Consul | 3 | 2 vCPU, 1.8 ГБ памяти |
| PostgreSQL | 3 | 4 vCPU, 15 ГБ памяти |
| PgBouncer | 3 | 2 vCPU, 1.8 ГБ памяти |
| Внутренний балансировщик нагрузки | 1 | 4 vCPU, 3.6 ГБ памяти |
| Redis/Sentinel | 3 | 2 vCPU, 7.5 ГБ памяти |
| Gitaly | 3 | 8 vCPU, 30 ГБ памяти |
| Praefect | 3 | 2 vCPU, 1.8 ГБ памяти |
| Praefect PostgreSQL | 1+ | 2 vCPU, 1.8 ГБ памяти |
| Sidekiq | 2 | 4 vCPU, 15 ГБ памяти |
| GitLab Rails | 3 | 16 vCPU, 14.4 ГБ памяти |
| Узел мониторинга | 1 | 2 vCPU, 1.8 ГБ памяти |
| Объектное хранилище (Object Storage) | - | - |
200 RPS или 10000 пользователей¶
Целевая нагрузка: API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS.
Высокая доступность: Да, но для Praefect требуется стороннее PostgreSQL решение.
Рекомендованная минимальная конфигурация сервера:
| Сервис | Ноды | Конфигурация |
|---|---|---|
| Внешний балансировщик нагрузки | 1 | 4 vCPU, 3.6 ГБ памяти |
| Consul | 3 | 2 vCPU, 1.8 ГБ памяти |
| PostgreSQL | 3 | 8 vCPU, 30 ГБ памяти |
| PgBouncer | 3 | 2 vCPU, 1.8 ГБ памяти |
| Внутренний балансировщик нагрузки | 1 | 4 vCPU, 3.6 ГБ памяти |
| Redis/Sentinel - Cache | 3 | 4 vCPU, 15 ГБ памяти |
| Redis/Sentinel - Persistent | 3 | 4 vCPU, 15 ГБ памяти |
| Gitaly | 3 | 16 vCPU, 60 ГБ памяти |
| Praefect | 3 | 2 vCPU, 1.8 ГБ памяти |
| Praefect PostgreSQL | 1+ | 2 vCPU, 1.8 ГБ памяти |
| Sidekiq | 4 | 4 vCPU, 15 ГБ памяти |
| GitLab Rails | 3 | 32 vCPU, 28.8 ГБ памяти |
| Узел мониторинга | 1 | 4 vCPU, 3.6 ГБ памяти |
| Объектное хранилище (Object Storage) | - | - |
500 RPS или 25000 пользователей¶
Целевая нагрузка: API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS.
Высокая доступность: Да, но для Praefect требуется стороннее PostgreSQL решение.
Рекомендованная минимальная конфигурация сервера:
| Сервис | Ноды | Конфигурация |
|---|---|---|
| Внешний балансировщик нагрузки | 1 | 8 vCPU, 7.2 ГБ памяти |
| Consul | 3 | 2 vCPU, 1.8 ГБ памяти |
| PostgreSQL | 3 | 16 vCPU, 60 ГБ памяти |
| PgBouncer | 3 | 2 vCPU, 1.8 ГБ памяти |
| Внутренний балансировщик нагрузки | 1 | 8 vCPU, 7.2 ГБ памяти |
| Redis/Sentinel - Cache | 3 | 4 vCPU, 15 ГБ памяти |
| Redis/Sentinel - Persistent | 3 | 4 vCPU, 15 ГБ памяти |
| Gitaly | 3 | 32 vCPU, 120 ГБ памяти |
| Praefect | 3 | 4 vCPU, 3.6 ГБ памяти |
| Praefect PostgreSQL | 1+ | 2 vCPU, 1.8 ГБ памяти |
| Sidekiq | 4 | 4 vCPU, 15 ГБ памяти |
| GitLab Rails | 5 | 32 vCPU, 28.8 ГБ памяти |
| Узел мониторинга | 1 | 4 vCPU, 3.6 ГБ памяти |
| Объектное хранилище (Object Storage) | - | - |
1000 RPS или 50000 пользователей¶
Целевая нагрузка: API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS.
Высокая доступность: Да, но для Praefect требуется стороннее PostgreSQL решение.
Рекомендованная минимальная конфигурация сервера:
| Сервис | Ноды | Конфигурация |
|---|---|---|
| Внешний балансировщик нагрузки | 1 | 16 vCPU, 14.4 ГБ памяти |
| Consul | 3 | 2 vCPU, 1.8 ГБ памяти |
| PostgreSQL | 3 | 32 vCPU, 120 ГБ памяти |
| PgBouncer | 3 | 2 vCPU, 1.8 ГБ памяти |
| Внутренний балансировщик нагрузки | 1 | 16 vCPU, 14.4 ГБ памяти |
| Redis/Sentinel - Cache | 3 | 4 vCPU, 15 ГБ памяти |
| Redis/Sentinel - Persistent | 3 | 4 vCPU, 15 ГБ памяти |
| Gitaly | 3 | 64 vCPU, 240 ГБ памяти |
| Praefect | 3 | 4 vCPU, 3.6 ГБ памяти |
| Praefect PostgreSQL | 1+ | 2 vCPU, 1.8 ГБ памяти |
| Sidekiq | 4 | 4 vCPU, 15 ГБ памяти |
| GitLab Rails | 12 | 32 vCPU, 28.8 ГБ памяти |
| Узел мониторинга | 1 | 4 vCPU, 3.6 ГБ памяти |
| Объектное хранилище (Object Storage) | - | - |
Прежде чем начать¶
Запуск любого приложения в рабочей среде сложен, это же относится и к AppSec.Code. Существуют общие сложности, связанные с персональными требованиями к архитектуре. Необходимо управлять всеми аспектами, такими как оборудование, операционные системы, сеть, хранилище, безопасность, сам AppSec.Code и многое другое. Это относится не только к первоначальной настройке среды, но и к долгосрочному обслуживанию.
С какой архитектуры начать¶
Эталонные архитектуры призваны обеспечить баланс между тремя важными факторами: производительностью, отказоустойчивостью и стоимостью. Они созданы для того, чтобы упростить настройку AppSec.Code в любом масштабе. Главный принцип, которые необходимо понять: чем более производительной и/или отказоустойчивой вы хотите видеть свою среду, тем она сложнее.
В этом разделе объясняется, что следует учитывать при выборе эталонной архитектуры.
Ожидаемая нагрузка (RPS или количество пользователей)¶
Правильный размер архитектуры зависит в первую очередь от ожидаемой пиковой нагрузки вашей среды. Наиболее объективным показателем этой нагрузки является пиковое количество запросов в секунду (RPS), поступающих в среду.
Каждая архитектура предназначена для обработки определенных целей RPS для разных типов запросов (API, Интернет, Git).
Для быстрой оценки RPS можно использовать следующие возможные варианты:
- Решения для мониторинга.
- Статистика балансировщика нагрузки.
Если вы не можете определить свой показатель RPS, мы предлагаем альтернативный метод определения размера, основанный на эквивалентном количестве пользователей по категориям нагрузки. Это количество сопоставлено с типичными значениями числа запросов в секунду с учетом как ручного, так и автоматического использования.
Начальный размер¶
Чтобы определить, какую архитектуру выбрать для ожидаемой нагрузки, см. следующую таблицу начальных размеров:
| Категория нагрузки | API RPS | Веб RPS | Git Pull RPS | Git Push RPS | Типичное количество пользователей | Эталонная архитектура |
|---|---|---|---|---|---|---|
| X-малый | 20 | 2 | 2 | 1 | 1000 | До 20 запросов в секунду или 1000 пользователей |
| Малый | 40 | 4 | 4 | 1 | 2000 | До 40 запросов в секунду или 2000 пользователей |
| Средний | 60 | 6 | 6 | 1 | 3000 | До 60 запросов в секунду или 3000 пользователей |
| Большой | 100 | 10 | 10 | 2 | 5000 | До 100 запросов в секунду или 5000 пользователей |
| X-большой | 200 | 20 | 20 | 4 | 10 000 | До 200 запросов в секунду или 10 000 пользователей |
| 2X-большой | 500 | 50 | 50 | 10 | 25 000 | До 500 запросов в секунду или 25 000 пользователей |
| 3X-большой | 1000 | 100 | 100 | 20 | 50 000 | До 1 000 запросов в секунду или 50 000 пользователей |
Начните с большего размера¶
Если вы не уверены в требуемом размере среды, вам стоит начать с большего размера, отслеживайте нагрузку, а затем уменьшите ресурсы.
Начинать с большего размера, а затем уменьшать масштаб — это разумный подход, когда:
- Вы не можете определить RPS.
- Нагрузка на окружающую среду может быть нетипично выше ожидаемой.
- У вас большие монорепозитории или значительные рабочие нагрузки. Например, если у вас 3000 пользователей, но вы также знаете, что существует автоматизация, которая значительно увеличит одновременную нагрузку, тогда вы можете начать со среды класса 100 RPS / 5000 пользователей, отслеживать ее и, если метрики удовлетворительные, масштабировать все компоненты сразу или один за другим.
Автономный (без высокой доступности)¶
Для сред с нагрузкой до 2000 пользователей обычно достаточно автономного развертывания без высокой доступности, в одноузловой или многоузловой конфигурации. В этом случае можно полагаться на автоматические бэкапы и другие механизмы восстановления. Такой подход дает приемлемые значения ключевым метрикам для планирования аварийного восстановления IT-систем — RTO (Recovery Time Objective, целевое время восстановления) и RPO (Recovery Point Objective, целевая точка восстановления), и при этом избавляет от сложности, связанной с высокой доступностью.
Высокая доступность¶
Высокая доступность (High Availability, HA) обеспечивает устойчивость каждого компонента AppSec.Code к сбоям за счет дополнительных механизмов отказоустойчивости. Но реализация такой архитектуры сложна и требует заметных ресурсов.
Для сред от 3000 пользователей и выше мы обычно рекомендуем использовать подход с высокой доступностью. На этом уровне любые сбои затрагивают больше людей, поэтому все архитектуры для такого масштаба уже включают высокую доступность по умолчанию.
Большие монорепозитории/Дополнительные рабочие нагрузки¶
Крупные монорепозитории или существенные дополнительные рабочие нагрузки могут заметно снизить производительность среды. В зависимости от ситуации могут потребоваться отдельные настройки.
Поддерживаемые типы дисков¶
Большинство стандартных типов дисков совместимы с AppSec.Code, однако обратите внимание на следующие моменты:
- Для Gitaly существуют специальные требования к дискам для хранения репозиториев.
- Диски с поддержкой прерываемой нагрузки не рекомендуются из-за нестабильной производительности.
- Остальные типы дисков обычно работают корректно; выбор зависит от ваших приоритетов, например долговечности или стоимости.
Поддерживаемая инфраструктура¶
AppSec.Code совместим с большинством инфраструктур.
Однако это не гарантирует работу во всех возможных конфигурациях.
Сеть (высокая доступность)¶
Сетевые требования для запуска AppSec.Code в режиме высокой доступности:
- Сетевая задержка должна быть минимальной, чтобы поддерживать синхронную репликацию в AppSec.Code, например баз данных, и обычно не должна превышать 5 мс.
Большие монорепозитории¶
Архитектуры тестировались на репозиториях разных размеров с учётом лучших практик.
Однако крупные монорепозитории (несколько гигабайт и более) могут существенно снизить производительность AppSec.Code и всей среды. Их использование создает нагрузку на компоненты от Gitaly до базовой инфраструктуры.
Основное влияние носит программный характер, поэтому увеличение аппаратных ресурсов приносит лишь частичное улучшение.
Для поддержания производительности и контроля расходов:
- Оптимизируйте репозиторий, например с помощью LFS для хранения двоичных файлов и других методов уменьшения размера.
- В зависимости от репозитория могут понадобиться дополнительные ресурсы для Gitaly, Praefect, Gitlab Rails и балансировщиков нагрузки.
- Для очень больших репозиториев (20 ГБ и более) могут потребоваться отдельные бэкенды Gitaly или расширенные спецификации среды.
- Учитывайте пропускную способность сети и дисков. При большом числе одновременных клонов (например, в CI) может потребоваться ограничение полных клонов или увеличение ресурсов для поддержки трафика, что зависит от провайдера облака.
Дополнительные рабочие нагрузки¶
Эталонные архитектуры разрабатывались и тестировались с учётом стандартных настроек AppSec.Code на основе реальных данных.
Дополнительные рабочие нагрузки могут усилить нагрузку на систему и вызвать побочные эффекты. В таких случаях может потребоваться корректировка рекомендованных характеристик, если вы используете:
- Средства безопасности на узлах.
- Сотни одновременных CI-задач для больших репозиториев.
- Часто выполняемые пользовательские сценарии.
- Интеграции с крупными проектами.
- Серверные хуки.
- Системные хуки.
Рекомендуется организовать надежный мониторинг для оценки влияния дополнительных нагрузок и внесения необходимых изменений.
Балансировщики нагрузки¶
В архитектурах может использоваться до двух балансировщиков нагрузки:
- Внешний балансировщик — распределяет трафик к внешним компонентам, прежде всего к Gitlab Rails.
- Внутренний балансировщик — распределяет трафик между внутренними компонентами, развернутыми в HA-режиме, например Praefect или PgBouncer.
Подробности настройки балансировщиков выходят за рамки документации AppSec.Code. Обычно их настраивают на узлах или используют облачные сервисы. В гибридной Cloud Native среде внешний балансировщик можно настроить через Kubernetes Ingress.
Каждый класс архитектуры содержит рекомендации по базовым характеристикам машин, но может потребоваться их корректировка в зависимости от типа балансировщика, ожидаемой нагрузки и пропускной способности сети.
Алгоритм балансировки¶
Чтобы обеспечить равное распределение вызовов к узлам и хорошую производительность, по возможности используйте алгоритм балансировки нагрузки на основе наименьшего количества соединений или его эквивалент.
Мы не рекомендуем использовать циклические алгоритмы, поскольку известно, что на практике они не распределяют соединения одинаково.
Лучшие практики для сервисов Redis¶
Используйте внешнюю службу Redis с официальной, производительной и поддерживаемой версией. Сервис должен обеспечивать:
- Автономный режим (Primary + Replica); режим Redis Cluster не поддерживается.
- Высокую доступность через репликацию.
- Возможность настройки политики вытеснения.
Поскольку Redis в основном однопоточный, для сред с нагрузкой около 200 запросов в секунду или 10000 пользователей и выше, рекомендуется разделять экземпляры на кэш и постоянные данные для оптимальной производительности.
Бессерверные реализации Redis в настоящее время не поддерживаются.
Рекомендации по хранению объектов¶
AppSec.Code протестирован с различными объектными хранилищами, которые должны работать корректно.
Рекомендуется использовать надежное решение с полной совместимостью с S3.
Отклонение от предлагаемых эталонных архитектур¶
Чем больше вы отклоняетесь от эталонных архитектур, тем сложнее получать поддержку, поскольку каждое отклонение добавляет уровень сложности, затрудняющий устранение проблем.
Эти архитектуры используют официальные пакеты Linux или Helm Charts для установки и настройки компонентов. Компоненты развернуты на отдельных машинах.
Компоненты AppSec.Code можно запускать в Docker, включая Docker Compose. Docker хорошо поддерживается и обеспечивает согласованные спецификации в разных средах, но добавляет дополнительный уровень, который может усложнять поддержку, например невозможность использовать strace внутри контейнера.
Неподдерживаемая архитектура¶
Хотя мы стремимся обеспечить надежную поддержку проектов AppSec.Code, некоторые подходы работают неэффективно. Ниже описаны такие неподдерживаемые методы.
Компоненты с сохранением состояния в Kubernetes¶
Запуск компонентов с сохранением состояния в Kubernetes, таких как Postgres и Redis, не поддерживается.
Можно использовать другие поддерживаемые облачные сервисы, если явно не указано обратное.
Отдельные узлы Gitaly допускается развертывать в Kubernetes с ограниченной доступностью, обеспечивая работу без высокой доступности, где каждый репозиторий хранится на одном узле.
Целевые показатели эффективности¶
Каждая эталонная архитектура проверяется на соответствие целевым показателям пропускной способности, основанным на реальных данных клиентов. Для каждых 1000 пользователей тестируются следующие показатели:
- API: 20 RPS.
- Веб-интерфейс: 2 RPS.
- Git Pull: 2 RPS.
- Git Push: 0,4 RPS (округляется до ближайшего целого).
Эти значения RPS основаны на реальных нагрузках клиентов, включая CI и другие рабочие процессы.
В тестовых средах задержка сети между компонентами была меньше 5 мс, но это не является строгим требованием.
Масштабирование среды¶
Эталонные архитектуры служат отправной точкой и остаются гибкими и масштабируемыми. После развертывания может потребоваться адаптация среды под конкретные требования, например для повышения производительности или снижения затрат. Масштабирование можно выполнять поэтапно или сразу до следующего уровня архитектуры, если метрики показывают, что компонент достиг предела ресурсов.
Если компонент регулярно исчерпывает выделенные ресурсы, обратитесь в поддержку перед выполнением масштабирования.
Для большинства компонентов доступны как вертикальное, так и горизонтальное масштабирование, но учитывайте следующие моменты:
- При вертикальном масштабировании Puma и Sidekiq нужно скорректировать число рабочих процессов. Puma масштабируется автоматически при следующей перенастройке, а для Sidekiq может потребоваться ручная настройка.
- Redis и PgBouncer однопоточные; при нехватке CPU возможно горизонтальное масштабирование.
- Consul, Redis Sentinel и Praefect требуют нечетного числа узлов для кворума при HA-развертывании.
- Масштабирование некоторых компонентов может сильно повлиять на производительность среды.
Если метрики показывают избыточные ресурсы, среду можно масштабировать вниз итеративно, чтобы избежать проблем.
Масштабирование эффектов¶
Значительное масштабирование одного компонента может негативно повлиять на производительность зависимых компонентов. Архитектуры разработаны так, чтобы обеспечить баланс между взаимозависимыми компонентами, но масштабирование одного элемента может потребовать увеличения ресурсов для связанных компонентов. Перед масштабированием отслеживайте показатели всех зависимых сервисов. Если несколько взаимозависимых компонентов достигают предела ресурсов, их следует масштабировать одновременно, а не по очереди, чтобы избежать смещения узких мест.
Архитектуры гибки и поддерживают масштабирование вышестоящих компонентов, но перед внесением существенных изменений рекомендуется обратиться в поддержку.
Компоненты, масштабирование которых может повлиять на другие:
- Puma и Sidekiq — увеличение рабочих процессов повышает нагрузку на внутренний балансировщик, PostgreSQL (через PgBouncer, если используется), Gitaly (через Praefect, если используется) и Redis.
- Redis однопоточный; при росте нагрузки может понадобиться разделение на отдельные экземпляры (например, кэш и постоянные данные), чтобы избежать перегрузки CPU.
- PgBouncer также однопоточный; масштабирование может добавить новые пулы и увеличить общее число подключений к Postgres. Рекомендуется делать это только при опыте управления соединениями и при необходимости консультироваться с поддержкой.
- Gitaly Cluster (Praefect) / PostgreSQL — добавление узлов может ухудшить HA и производительность из-за роста количества репликационных вызовов на основной узел.