Квест 5: Прикидка нагрузки на салфетке · Проектирование веб-приложений

Зачем

Проверить, как архитектура вашего приложения поддерживает основной пользовательский сценарий: какую нагрузку получает система, что может ограничить её работу и как она должна вести себя при отказе или перегрузке.

Результат — анализ основного сценария, приблизительная оценка нагрузки, описание допустимой деградации и одно архитектурное решение в ADR. Расчёт должен помочь принять решение для вашего проекта, а не просто получить число запросов в секунду.

Стартовый набор

Работа командная, над собственным проектом. Нужны:

требования и уже описанные пользовательские сценарии;
диаграммы System Context и Container из квеста 4;
оценка аудитории, которую вы использовали на представлении проекта;
общий документ для записи анализа и калькулятор.

Повторно описывать идею проекта и рисовать схемы с нуля не требуется. Все числа могут быть приблизительными: важно записать основания и допущения.

Что нужно сделать

1. Проследите основной сценарий по архитектуре

Выберите один уже описанный сценарий, без которого приложение теряет основную ценность. Отметьте его маршрут на готовой схеме либо запишите последовательность:

Действие пользователя → компонент → передаваемые данные → следующий компонент → результат.

Для каждого шага укажите:

какой компонент выполняет работу;
какие данные получает или создаёт;
должен ли шаг завершиться до получения основного результата или может быть отложен;
что произойдёт со сценарием, если шаг не завершится.

Перечислите критические зависимости — компоненты и взаимодействия, без которых основной результат невозможно получить. Отдельно отметьте вспомогательные действия, которые можно временно не выполнять.

2. Оцените ожидаемую нагрузку

Задайте один реалистичный режим использования приложения. Укажите:

общее число пользователей и число одновременно активных — можно опираться на оценку аудитории с представления проекта;
частоту выполнения выбранного сценария одним активным пользователем;
число запросов или операций, которое вызывает одно выполнение сценария;
среднюю нагрузку и возможный кратковременный пик;
объём файлов или данных, если он существенно влияет на работу.

Для оценки частоты выполнения сценария:

Выполнений в секунду ≈ активные пользователи × выполнений сценария одним пользователем за минуту / 60.

Для выбранного компонента:

Запросов в секунду ≈ выполнений сценария в секунду × обращений к компоненту на одно выполнение.

Пользовательское действие может вызывать несколько HTTP-запросов, но только часть из них обращается к базе данных или внешнему сервису. Укажите, какую именно нагрузку вы считаете, и подписывайте единицы измерения.

Для длительных операций дополнительно оцените одновременную обработку:

Одновременно выполняемых операций ≈ запусков в секунду × средняя длительность операции в секундах.

Эта оценка предполагает относительно устойчивый поток и отсутствие постоянно растущей очереди; она не доказывает, что система способна выдержать такую нагрузку.

Пример: 60 активных пользователей запускают генерацию раз в 5 минут. Получается 12 запусков в минуту, или 0,2 в секунду. При длительности 30 секунд одновременно могут выполняться примерно 6 генераций.

Опишите ситуацию, создающую пик, и объясните выбранный масштаб. Если естественного пика нет, укажите это и отдельно задайте условную повышенную нагрузку для анализа перегрузки.

Для локального приложения используйте подходящие показатели вместо RPS: число операций, размер набора данных, размер файлов и время обработки.

Запишите основания и допущения. Не выдавайте расчёт за результат измерений.

3. Выберите потенциальное узкое место

На основании маршрута и нагрузки выберите одно наиболее правдоподобное ограничение: базу данных, backend, внешний API, последовательную обработку, очередь, сеть, диск, память или процессор.

Опишите его:

Компонент или ресурс → условие возникновения проблемы → почему он может не справиться → что заметит пользователь.

Различайте:

Критическую зависимость: без компонента сценарий не завершится.
Узкое место: компонент или ресурс ограничивает скорость обработки.

Например, провайдер LLM может быть критической зависимостью при недоступности и узким местом при ограничении параллельных запросов.

Если при ожидаемой нагрузке явного узкого места не видно, так и запишите. Выберите вероятный ограничивающий ресурс при росте нагрузки и предложите способ проверить гипотезу. Не добавляйте компоненты ради сложности схемы.

4. Продумайте отказы и допустимую деградацию

Рассмотрите две разные ситуации:

Один компонент критического пути временно недоступен.
Компонент работает, но поток операций превышает его возможности.

Для каждой ситуации укажите:

что перестанет работать;
какие функции продолжат работать полностью или в ограниченном режиме;
что увидит пользователь и какие действия ему будут доступны;
что произойдёт с введёнными данными и незавершёнными операциями;
есть ли риск потери данных, повторного выполнения или неконсистентности;
допустимо ли это поведение с учётом требований;
какая простая мера позволит сохранить часть функций или корректно остановить операцию.

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

Примеры:

при недоступности LLM сохраняются просмотр и редактирование готовых материалов, а генерация временно отключается;
при перегрузке обработка откладывается, пользователь видит статус ожидания;
при проблеме сохранения введённые данные сохраняются локально, если это допустимо и технически предусмотрено;
тяжёлая операция временно недоступна, остальные функции продолжают работать.

Для простого приложения рассматривайте его собственные зависимости и ресурсы. Внешние сервисы не обязательны.

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

Отдельно обозначьте уже реализованное поведение и предлагаемые изменения.

5. Оформите одно решение в ADR

Выберите решение, вытекающее из анализа. Например:

оставить операцию синхронной или перенести её в фон;
ограничить размер файлов или количество одновременных операций;
отделить доступ к готовым данным от функции генерации;
определить порядок обработки ошибок и повторной отправки;
сохранить текущую архитектуру, поскольку ожидаемая нагрузка и последствия отказа приемлемы.

Оформите краткий ADR — запись архитектурного решения:

Заголовок и статус: предложено или принято.
Контекст: проблема, требования, расчёт нагрузки, ограничения и допущения.
Альтернативы: выбранный вариант и хотя бы одна содержательная альтернатива.
Решение: что выбрано и почему.
Последствия: преимущества, ограничения, риски, дополнительная сложность и поведение при проблемах.
Условия пересмотра: какие изменения или результаты проверки потребуют вернуться к решению.

Сравнивайте альтернативы по одинаковым критериям. Формулировки «так принято», «это современно» и «это масштабируется» без связи с условиями проекта не являются обоснованием.

Сохранение текущей архитектуры — допустимое решение. Укажите, почему усложнение сейчас не требуется и когда оно может понадобиться.

Проверьте согласованность ADR с C4. Если решение меняет контейнеры или связи, уточните диаграмму. Если влияет только на внутреннюю обработку, достаточно текстового пояснения. Второй ADR можно оформить дополнительно, но он не обязателен.

Чек-лист перед сдачей

Что сдаём

Один документ от команды с анализом и ADR. Укажите название проекта, участников, которые были на паре, и дату.

Шаблон документа лежит на Яндекс Диске.

Команда загружает свой файл в папку сдачи на Яндекс Диске. В названии файла укажите номер практики и название команды или проекта, например: Практика-5_Название-команды.md.

Диаграммы C4 можно приложить внутри документа или дать ссылки на них. Проверьте, что преподаватель сможет их открыть.

Зачтено, если

Оценка выставляется за общий результат команды.

Балл	Когда ставится
1	Представлены все обязательные разделы. Расчёт нагрузки понятен и содержит допущения. Узкое место обосновано. Для отказа и перегрузки описаны допустимая деградация либо причины её невозможности, поведение пользователя и риски для данных. ADR связан с анализом, содержит альтернативу и последствия. Команда может объяснить выводы.
0.5	Представлен содержательный, но неполный результат: например, расчёт не раскрывает обращения к компонентам; одна из проблемных ситуаций разобрана поверхностно; неясно поведение незавершённых операций; в ADR недостаточно обоснованы альтернативы или последствия. Основной сценарий и логика анализа при этом понятны.
0	Работа не представлена либо не достигает требований на 0.5 балла: нет связного анализа сценария, нагрузки и проблемных ситуаций; выводы состоят из общих утверждений; команда не может объяснить принятые решения.

Сложность приложения, наличие внешних сервисов и количество предложенных компонентов сами по себе не повышают оценку.

Типовые грабли

Всех пользователей посчитали одновременно активными. Разделяйте размер аудитории и число людей, которые выполняют сценарий в выбранный момент.
Смешали пользовательские действия, HTTP-запросы и обращения к базе данных. Подписывайте, для какого компонента считается нагрузка.
Получили RPS и объявили, что приложение его выдержит. Расчёт оценивает ожидаемый поток; способность системы справиться проверяется отдельно.
Критическую зависимость назвали узким местом без объяснения. Недоступность компонента и ограничение скорости обработки — разные проблемы.
Для отказа и перегрузки написали только «покажем ошибку». Укажите, что останется доступным, что произойдёт с данными и можно ли повторить операцию.
Добавили очередь, кэш или резервный сервис без необходимости. Каждая мера должна отвечать на конкретную проблему вашего проекта.
В ADR выбрали «современное решение», а альтернативу рассмотрели формально. Сравнивайте варианты по требованиям, нагрузке, рискам и сложности.
Предлагаемое поведение описали как уже реализованное. Явно разделяйте текущее состояние и изменения, которые ещё предстоит сделать.