Тема: От теории к практике — как закладывать архитектуру, которая не упадет под нагрузкой.
1. Введение. Почему системы ломаются?
Разбираем реальные кейсы падения крупных сервисов (Amazon, Twitter, Spotify). Вместо «хорошо бы сделать надежно» — учимся проектировать с запасом прочности и понимать компромиссы.
2. Свойства информационных систем (Quality Attributes)
Каждое свойство разбираем через призму измерений и метрик:
- Надежность (Reliability): как избежать единой точки отказа (SPOF). Что такое MTBF, MTTR и SLA/SLO/SLI.
- Масштабируемость (Scalability): вертикальное vs горизонтальное масштабирование. В чем разница между scaling up и scaling out.
- Производительность (Performance): задержка (latency) vs пропускная способность (throughput). Почему P99 важнее среднего значения.
- Удобство сопровождения (Maintainability): операбельность, наблюдаемость (observability) и простота эволюции.
- Безопасность (Security): не только про взломы, но и про защиту от DDoS, rate limiting и аутентификацию на всех слоях.
3. Критерии классификации систем
Учимся определять тип системы на старте, чтобы выбрать правильные инструменты:
- Data / Compute intensive — где узкое место (диск, память или процессор)?
- Read / Write intensive — выбираем кэширование или очереди.
- Low latency vs High throughput — какой сценарий критичен для бизнеса (онлайн-игра или аналитический отчет)?
4. Балансировка нагрузки (Load Balancing)
Разбираем полный стек — от пользователя до базы данных:
- Где балансировать: клиентская (SDK) и серверная (аппаратная/программная).
- DNS и GeoDNS: как направить пользователя на ближайший дата-центр.
- Уровни L4 (транспортный) и L7 (прикладной): когда использовать IP-балансировку, а когда — балансировку по HTTP-заголовкам (URL, User-Agent, Cookie).
- Алгоритмы с примерами:
Random / Round Robin — простые, но неэффективные при неравномерных запросах.
Weighted RR — для серверов разной мощности.
Least Connections / Least Response Time — для долгих сессий.
Sticky Sessions (привязка к сессии) — зачем нужны и в чем их опасность.
Power of Two Choices — почему это лучший компромисс между случайностью и детерминизмом.
5. Проксирование (Proxying)
Четкое разделение и кейсы:
- Forward Proxy — прокси для клиентов (обход блокировок, анонимность, кэширование).
- Reverse Proxy — прокси для серверов (балансировка, SSL-терминация, защита от прямого доступа, кэширование ответов).
6. Функциональные и нефункциональные требования
Как правильно собирать требования, чтобы не перепроектировать систему:
- Функциональные (FR): ЧТО система должна делать (фичи, юз-кейсы, бизнес-логика).
- Нефункциональные (NFR): КАК система это делает (скорость, доступность, безопасность, цена).
- Практика: учимся превращать слова заказчика («должно быть быстро») в измеримые метрики («время ответа < 200 мс для 99% запросов»).
7. Расчет нагрузки (Capacity Planning)
Инженерный подход к цифрам:
- Оценка трафика (RPS — requests per second, чтения/записи).
- Оценка данных (объем хранилища на день/месяц/год, рост).
- Оценка сетевого входящего/исходящего трафика (bandwidth).
- Расчет пиковых нагрузок (Black Friday, запуск рекламной кампании).
Что вы получите в результате урока:
✅ Научитесь классифицировать систему по ее слабым местам (CPU, I/O, Memory).
✅ Научитесь выбирать алгоритм балансировки под конкретный сценарий работы.
✅ Сможете формализовать требования в виде документа, понятного разработчикам и бизнесу.
✅ Приобретете навык «прикидки» нагрузки на салфетке (back-of-the-envelope calculation).
✅ Узнаете, какие компромиссы (CAP-теорема, согласованность vs доступность) придется делать.
Бонусная часть (Live-сессия):
Вместе с преподавателем «оживляем» требования для популярного приложения (например, онлайн-кинотеатр или мессенджер).
Мы реально посчитаем нагрузку для такой системы:
- Сколько серверов нужно?
- Какой должен быть размер кэша?
- Какие метрики мониторить в первую очередь?
Домашнее задание :
Задача: Вы — главный архитектор стартапа. Вам нужно спроектировать фундамент для будущей социальной сети (аналог X/Twitter).
Что нужно сделать в письменном отчете:
- Сформулируйте 5–7 функциональных требований (что пользователи могут делать).
- Сформулируйте 5 нефункциональных требований с указанием конкретных цифр (например: доступность 99.99%, время загрузки ленты < 500 мс, поддержка 100K одновременных пользователей).
- Рассчитайте нагрузку на систему при следующих вводных (данные вводные выдаются преподавателем):
Количество активных пользователей в день: 10 млн.
Каждый пользователь пишет 2 поста в день.
Каждый пост читается в среднем 100 раз.
Пост содержит текст (~1 КБ) и медиа (фото ~2 МБ).
Оцените: RPS на запись, RPS на чтение, требуемое место на диске за год, пиковый исходящий трафик. - Предложите схему балансировки для этого сервиса: какой тип прокси и алгоритм вы выберете на входе (API Gateway) и почему.
Формат сдачи: текстовый документ (Google Docs / Markdown) с расчетами и пояснениями.
Критерии оценки ДЗ:
- Корректность расчетов (единицы измерения, учет роста).
- Логичность выбора алгоритмов под требования.
- Наличие обоснования каждого решения («выбрал X, потому что...»).