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

Высоконагруженный маркетплейс в облаке для ВКР: архитектура, метрики и защита

Введение

26 марта 2026 года стало известно, что ИТ-разработчик Win Solutions перенёс маркетплейс игровых товаров на облачные мощности Cloud.ru. Кейс интересен не самим фактом миграции — таких релизов сейчас десятки, — а тем, что перед командой стояла задача удержать высокую нагрузку при пиковых всплесках продаж, когда за минуты приходит трафик, сопоставимый с обычным днём. Для выпускника ИТ-специальности это готовая фактура: за таким кейсом стоит целый пласт тем — от проектирования отказоустойчивой архитектуры до оценки экономии на инфраструктуре.

Проблема в том, что студенты часто берут «облако» как модный ярлык: пишут в актуальности «облачные технологии развиваются», а в практической главе поднимают один виртуальный сервер и на этом останавливаются. Комиссия такое видит сразу. Ниже — как развернуть новость в полноценную защищаемую работу и не утонуть в нормоконтроле.

FAQ: что чаще всего спрашивают по облачным темам ВКР

Можно ли брать реальный кейс компании, если нет доступа к их данным?

Да, и это нормальная практика. Вы работаете не с коммерческой тайной, а с публично описанной архитектурной моделью: воспроизводите тип нагрузки, класс сервисов, схему масштабирования. В главе 1 честно укажите источник и оговорите допущения — «метрики нагрузки смоделированы на основе公开 описанного профиля».

Где брать данные для нагрузочного тестирования?

Никто не даст вам продовый трафик. Синтетику генерируете сами: k6, Locust, JMeter. Главное — обосновать профиль: соотношение чтения/записи, доля пиковых запросов, размер полезной нагрузки. Пример сценария на k6 привожу ниже.

Как считать экономическую эффективность облака, если нет счетов?

Считаете TCO по двум сценариям — on-prem и облако. Формула не требует реальных платежей: берёте конфигурацию из документации провайдера, добавляете ФОТ администраторов, амортизацию железа, стоимость простоя. Допущения оформляете таблицей в приложении.

Обязательно ли разворачивать Kubernetes в дипломе?

Не обязательно, но если тема заявлена как «высоконагруженный сервис», без оркестратора или хотя бы managed-решения аргументация сыпется. Альтернатива — serverless-контейнеры Cloud.ru, но тогда меняется и постановка задач.

Темы ВКР: три вектора на базе кейса

• Тема 1. Проектирование отказоустойчивой облачной архитектуры маркетплейса цифровых товаров.
  Актуальность: Win Solutions выбрал облако именно для эластичности под пиковый трафик.
  Цель: разработать архитектуру, устойчивую к отказу узла и всплеску нагрузки.
  Задачи: анализ профиля нагрузки; выбор managed-сервисов; проектирование схемы развёртывания; оценка отказоустойчивости.
  Структура: Гл.1 — анализ предметной области и аналогов; Гл.2 — проектирование (C4, UML-диаграммы); Гл.3 — реализация и стресс-тесты.
• Тема 2. Автоматизация масштабирования и мониторинга высоконагруженного сервиса.
  Актуальность: без автомасштабирования облако превращается в дорогой хостинг.
  Цель: построить контур автоскейлинга и наблюдаемости на базе OpenTelemetry.
  Задачи: настройка HPA/VPA; сбор метрик и трейсов; определение SLO; валидация реакции системы на нагрузку.
  Структура: Гл.1 — теория SRE и SLO; Гл.2 — конфигурация кластера и пайплайна телеметрии; Гл.3 — эксперименты и графики.
• Тема 3. Оценка экономической эффективности миграции игрового маркетплейса в облако.
  Актуальность: бизнес-обоснование миграции — то, что реально интересует заказчика.
  Цель: сравнить TCO двух сценариев развёртывания.
  Задачи: построение модели затрат; расчёт сценариев; анализ чувствительности; выводы по порогу окупаемости.
  Структура: Гл.1 — методы оценки; Гл.2 — модель и входные данные; Гл.3 — расчёты и выводы.
• Тема 4. Защита транзакций маркетплейса цифровых товаров в облачной среде.
  Актуальность: игровые товары — частый объект мошенничества и атак на API.
  Цель: снизить риски по OWASP API Security Top 10 для ключевых сценариев.
  Задачи: моделирование угроз; аудит эндпоинтов; внедрение защитных механизмов; тесты на проникновение.
  Структура: Гл.1 — анализ угроз; Гл.2 — реализация защиты; Гл.3 — результаты пентеста.

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

Глава 1: анализ без пересказа пресс-релиза

Новость — это отправная точка, а не содержание. Разложите её на архитектурные требования: эластичность, отказоустойчивость, стоимость владения, время восстановления. Дальше сопоставьте требования с атрибутами качества из ISO/IEC 25010 — производительность, надёжность, масштабируемость, безопасность. Такая таблица «требование → атрибут → метрика → способ проверки» отлично смотрится в первой главе и сразу показывает комиссии системность мышления.

Схемы стройте по C4: контекст (кто пользователи, какие внешние системы), контейнеры (API-шлюз, сервисы, БД, кэш, очередь), компоненты. Для бизнес-процесса покупки — BPMN или диаграмма последовательности UML. Не рисуйте «просто красивые картинки» — каждая должна отвечать на вопрос, поставленный в тексте.

Глава 2: реализация, где видно руки

Здесь облачный кейс превращается в конфигурацию. Минимальный набор артефактов: манифесты Kubernetes, политика автомасштабирования, схема сети, описание managed-сервисов БД и кэша. Ниже — типовой HPA, который уместно показать как фрагмент практической главы.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: marketplace-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: marketplace-api
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
    scaleDown:
      stabilizationWindowSeconds: 300

Обратите внимание на behavior: быстрый подъём при пике и медленный спуск — классика для маркетплейса с волновым трафиком. Если в тексте не объяснить, почему окна разные, конфиг выглядит скопированным из документации.

Нагрузочный сценарий на k6 — компактный и воспроизводимый:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 200 },   // прогрев
    { duration: '1m', target: 2000 },  // пик распродажи
    { duration: '3m', target: 2000 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get(`${__ENV.BASE_URL}/api/v1/items?page=1`);
  check(res, { 'статус 200': (r) => r.status === 200 });
  sleep(0.5);
}

Глава 3: метрики вместо общих слов

Не пишите «система показала высокую производительность». Пишите числа и условия: p95 времени ответа, RPS до деградации, время горизонтального масштабирования, доля ошибок 5xx, стоимость часа пиковой нагрузки. Для наблюдаемости укажите стек: OpenTelemetry для трейсов и метрик, экспортер в хранилище, дашборд. Пять-семь графиков с подписями «до/после» убедительнее двадцати страниц теории.

Для темы про TCO добавьте таблицу сценариев с расчётом на 12 и 36 месяцев и точкой безубыточности — это тот слайд, который запомнит комиссия.

Нормоконтроль: где чаще всего режут

ГОСТ 34.601-90 задаёт стадии создания системы — сопоставьте с ними структуру глав. Схемы алгоритмов и данных оформляйте по ГОСТ 19.701-90. Подписи, нумерация, ссылки в тексте, список источников — стандартный набор, но именно на нём теряют баллы. Диаграммы, вставленные как скриншоты без масштабирования, читаются плохо; векторная вставка или исходник в приложении снимают вопрос.

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

• проектировать отказоустойчивые схемы развёртывания в managed-облаке;
• настраивать автомасштабирование и объяснять выбранные пороги;
• снимать метрики производительности и формулировать SLO;
• считать TCO и защищать экономические допущения;
• оформлять архитектурные схемы по C4 и ГОСТ без переделок.

Источник: Win Solutions развернул в облаке Cloud.ru высоконагруженный игровой маркетплейс (опубликовано 2026-03-26)