Планирование мощностей

Previous Next

Планирование ресурсов и нагрузки для обеспечения целевой доступности и производительности.

Цели

  • Обеспечить выполнение SLO по доступности и латентности при ожидаемой и пиковой нагрузке; см. SLA / SLO.
  • Избежать неожиданной нехватки ресурсов (CPU, память, соединения к БД, throughput Kafka) при росте трафика или числа сервисов.

Подход

  • Базовые метрики: текущее использование CPU/памяти подов, число соединений к БД, consumer lag и throughput Kafka, RPS по API — собираются в Prometheus; дашборды в Grafana.
  • Прогноз: на основе тренда роста (пользователи, запросы, объём данных) и плановых фич оценивается нагрузка на 3–6–12 месяцев; пересчёт при значимых изменениях (новые сервисы, миграции, смена трафика).
  • Резерв: запас по ресурсам (headroom) для пиков и отказоустойчивости; реплики для критичных сервисов; при необходимости HPA по CPU/памяти или кастомным метрикам.
  • Узкие места: идентификация ограничивающих факторов (БД, Kafka, внешние API); масштабирование или оптимизация по приоритету.

В платформе AIOps

  • Сервисы (Identity, Credential, API Gateway и др.): лимиты и запросы в манифестах K8s; при росте — увеличение реплик или ресурсов по результатам нагрузочного тестирования.
  • PostgreSQL: мониторинг соединений, диска, латентности запросов; при необходимости пул соединений (pgbouncer) и вертикальное/горизонтальное масштабирование (реплики для чтения).
  • Kafka: партиции и репликация по топикам; мониторинг lag; при росте числа потребителей или объёма событий — увеличение партиций и брокеров по процедурам Strimzi/Kafka.
  • Redis: память и число соединений; при необходимости кластер или шардирование по использованию.

Связанные страницы

SLA / SLO Отказоустойчивость