Опубликовано: 30.09.2026 | Источник: CNews (новости)

Масштабирование мессенджера до 107 млн пользователей: темы ВКР по Cloud/DevOps и метрики для защиты

Поддомен: Cloud/DevOps. Роль эксперта: DevOps/SRE-инженер.

Введение

26 марта 2026 года в приложении Mах зафиксировали более 107 млн зарегистрированных пользователей — всего за год с момента запуска. Для инженера это не новость «про маркетинг», а вводная к задаче: сколько нужно держать узлов, как шардировать хранилище сообщений, где упадёт p99 под всплеском активности в час пик. Именно такие кейсы делают диплом защищаемым: комиссия видит не абстрактное «приложение на Python», а систему с обоснованными SLO, схемой отказоустойчивости и расчётом ресурсов. Ниже — как превратить новость в ВКР по Cloud/DevOps, какие темы брать и что считать в третьей главе, чтобы получить «отлично».

FAQ: что чаще всего спрашивают у научрука по этой теме

Темы ВКР: три варианта под облачный профиль

• Проектирование отказоустойчивой архитектуры мессенджера под 100 млн+ пользователей
  Актуальность: кейс Mах подтверждает — массовые сервисы обмена сообщениями растут в разы за год, а инфраструктура должна расти быстрее.
  Цель: разработать архитектуру с SLA ≥ 99,95% и стоимостью на активного пользователя ниже рыночных аналогов.
  Задачи: анализ CAP-компромиссов, выбор средств шардирования, расчёт ресурсов под пиковую нагрузку, проектирование деградации.
  Структура: Глава 1 — обзор высоконагруженных архитектур; Глава 2 — C4-модель и конфигурация Kubernetes; Глава 3 — нагрузочное тестирование и TCO.
• Наблюдаемость высоконагруженного сервиса на базе OpenTelemetry
  Актуальность: на 107 млн пользователей без трассировки и метрик вы не отличите сбой шарда от сетевой деградации.
  Цель: построить конвейер трейсов, метрик и логов с временем реакции на инцидент менее 5 минут.
  Задачи: выбор семплинга, развёртывание коллектора, дашборды SLO, алертинг.
  Структура: Глава 1 — теория наблюдаемости; Глава 2 — стенд с коллектором и бэкендами хранения; Глава 3 — эксперименты с инцидентами и MTTR.
• Автоскейлинг и управление стоимостью в Kubernetes для сервиса обмена сообщениями
  Актуальность: рост до 107 млн пользователей делает разницу между «правильным HPA» и «ручным скейлом» в десятки миллионов рублей в год.
  Цель: снизить стоимость облачных ресурсов на 30% без падения SLA.
  Задачи: настройка HPA/VPA, Karpenter или Cluster Autoscaler, планирование node pool, расчёт TCO.
  Структура: Глава 1 — паттерны эластичности; Глава 2 — конфигурация кластера и политик; Глава 3 — A/B-сравнение и экономический эффект.

Как встроить кейс Mах в главы работы

Глава 1: статья как источник постановки задачи

Не ограничивайтесь пересказом новости. Используйте цифру 107 млн как отправную точку для модели: если приложение набрало столько регистраций за 12 месяцев, то пиковый суточный прирост — порядка 300–400 тыс. новых учётных записей, а на старте приложения для iOS/Android это означает скачок запросов на балансировщик и сервис аутентификации. Постройте таблицу допущений — она защитит вас от вопроса «откуда цифры».

Схему взаимодействия компонентов опишите в C4-нотации: System Context → Container → Component. Для физического размещения — UML Deployment Diagram. Для сценария регистрации — BPMN. Каждый рисунок должен иметь подпись и ссылку в тексте («на рисунке 5 представлена…»), иначе нормоконтроль отправит на доработку.

Глава 2: реализация — от кластера до шардов

В главе 2 покажите конкретику: манифесты, политики, разделение на stateful и stateless. Ниже — минимальный фрагмент HPA-манифеста, который снимет вопрос «а вы вообще Kubernetes видели».

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: chat-gateway-hpa
  namespace: messenger
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: chat-gateway
  minReplicas: 6
  maxReplicas: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "900"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
    scaleDown:
      stabilizationWindowSeconds: 300

Для хранилища сообщений отдельно опишите стратегию шардирования: по chat_id (consistent hashing) + репликация по схеме leader-follower. Обязательно упомяните про backpressure: при пиковой нагрузке gateway должен отдавать 429, а не падать. Это классическая ошибка SRE — сервис, который героически пытается обработать всё.

Глава 3: метрики и экономический эффект

Здесь защищаются не «скриншоты Grafana», а числа с методикой. Минимальный набор:

• RPS на реплику при CPU 65% — база для расчёта размера кластера.
• p50/p95/p99 latency на каждом хопе: LB → gateway → chat-service → БД.
• Error rate и доля 5xx/429 при пиковой нагрузке.
• Утилизация Kafka consumer lag — сколько сообщений копится за минуту пика.
• TCO на 1 млн MAU: сумма стоимости нод + сетевых + хранилища.

Сравните сценарии: без HPA / с HPA / с Karpenter. Разница в счёте за месяц — и есть тот практический результат, который комиссия запоминает.

Чему вы научитесь

1. Проектировать отказоустойчивые схемы с обоснованным SLA, а не «на глаз».
2. Настраивать автоскейлинг в Kubernetes и считать его экономический эффект.
3. Строить наблюдаемость на OpenTelemetry и привязывать её к SLO.
4. Оформлять архитектурные схемы в C4/UML и приводить их в соответствие с ГОСТ 34.201 и ГОСТ 19.701.
5. Защищать числовые результаты: RPS, p99, MTTR, TCO.
6. Готовить нагрузочные сценарии на k6/Locust и интерпретировать их выводы.

Источник: За год в Мах зарегистрировались 107 миллионов пользователей (опубликовано 2026-03-26)