HighLoad весна 2014 лекция 1

Проектирование
высоконагруженных
систем

Лекция №1

Быков Александр

HighLoad. Лекция №1

О преподавателе
 Быков Александр Сергеевич
 Сотрудник Mail.Ru c 2004 года

 Технический руководитель рекламной системы
 Начинал с позиции веб-разработчика в Почте
 Выпускник МГТУ им. Н.Э.Баумана 2006 года

2


Определения
Система — множество элементов, находящихся в
отношениях и связях друг с другом, которое образует
определѐнную целостность, единство. (М.: БРЭ. — 2003,
с. 1437)
В нашем случае – множество серверов и программ на них
работающих, представляющих в сумме веб-сервис для
конечного пользователя.

3


Определения
Нагрузка — совершаемая полезная работа

Максимальная нагрузка – верхний предел совершаемой
полезной работы в данной конфигурации системы
Высоконагруженная система – система выполняющая
объем работы значительно превышающий общепринятый

4


Предметная область: веб-сервисы
 Ярко выраженный эффект масштаба
 Популярность изменяется очень быстро

 Могут использоваться миллионами людей
 Необходимо учитывать нагрузку при проектировании
 Умение держать нагрузку – вопрос выживания

5


Задача: миллиард пользователей
 Как должна быть устроена такая система ?
 Как должна быть организована работа кампании ?

 Как планировать закупки оборудования ?
 Как предсказать изменения нагрузки ?
 Это вообще возможно ?

6


Цели курса
 Получение теоретических знаний в области
проектирования и эксплуатации высоконагруженных
систем

 Получение практических навыков разработки
высокопроизводительных сервисов
 Получение практических навыков анализа архитектуры
интернет-проектов и технологий

7


Место курса в программе обучения
Предшествующие:
 1 семестр: Web-технологии

 2 семестр: Базы данных
Параллельные:
 QA и Безопасность
Последующие:
 4 семестр: Разработка веб-сервисов
 4 семестр: Системный анализ для архитекторов
8


Входные требования
 Отличное знание протокола HTTP
 Навыки разработки многопоточных приложений

 Навыки проектирования баз данных
 Базовые навыки работы в ОС семейства UNIX
 Базовые знания об устройстве сетей

9


Выходные требования
 Навык разработки распределенного ПО
 Навык разработки ПО с учетом нагрузки

 Навык разработки ПО пригодного для эксплуатации
 Навык проектирования распределенных систем

10


Программа курса: лекции
1. Планирование мощностей
2. Сетевая подсистема

3. Оперативная память
4. Дисковая подсистема
5. Фронтенд-оптимизация
6. Масштабирование нагрузки
7. Планирование архитектуры

11


Программа курса: домашние задания
1. Разработка быстрого веб-сервера (5 апреля)
2. Нагрузочное тестирование веб-сервера (19 апреля)

3. Измерение размера кэша процессора (17 мая)
4. Анализ архитектуры интернет-проекта (24 мая)
Сдача раньше срока приветствуется
Сдача позже срока – половина баллов

12


Контроль знаний
1. Разработка быстрого веб-сервера (20 баллов)
2. Нагрузочное тестирование веб-сервера (10 баллов)

3. Измерение размера кэша процессора (10 баллов)
4. Анализ архитектуры интернет-проекта (10 баллов)
5. Экзамен (60 баллов)
Оценка на экзамене: удовл. – 20 баллов, хор. – 40 баллов
Пороговый рейтинг 60 баллов
13


Конец вводной части
 Познакомились друг с другом
 Разобрались зачем нужен этот курс

 Убедились в важности этого курса
 Узнали что нас ждет на занятиях

14


Содержание лекции
 Анализ предметной области
 Управление вычислительными мощностями

 Архитектура многопоточного сетевого ПО

15


Анализ предметной области
 Особенности интернет проектов
 Аудитория интернета

 Продуктовые метрики

16


Особенности интернет-проектов

17


Легкость входа на рынок
 Доступность сервиса из любой точки мира
 Низкая стоимость доставки сервиса потребителю

 Низкая стоимость разработки и эксплуатации
 Практически «нулевой» порог входа

18


Динамичность рынка
 Высокая конкурентность рынка
 Низкая привязанность пользователей к сервису

 Популярность сервиса может расти очень быстро
 … а падать еще быстрее
 Факторы: качество обслуживания

19


Особенности монетизации
 Низкая/нулевая доходность на одного пользователя
 Сначала аудитория потом монетизация

 ИТ-инфраструктура основная статья расходов
 В некоторых случаях начальные затраты велики
 Не все проекты выходят на окупаемость

20


ИТ-инфраструктура
 Основа бизнеса и основная статья расходов
 Высокие требования по скорости разработки

 Высокие требования по масштабированию
 Высокие требования по эффективности
 Невыполнение равно выходу из бизнеса

21


Аудитория интернета

22


Аудитория интернета: Россия

23


Аудитория интернета: Северная Америка

24


Аудитория интернета: Мир

25


Аудитория интернета: Мир

26


Аудитория проектов: Мир

27


Аудитория проектов: Россия

28


Возможные продуктовые метрики
 Количество зарегистрированных пользователей
 Суточная/недельная/месячная аудитория

 Максимальное количество пользователей онлайн
 Количество пользователей использующих функцию
 Интенсивность использования разных функций
 Средний размер данных пользователя
 и т.п.

29


Управление вычислительными мощностями
 Роли людей в проекте
 Постановка целей управления

 Подготовка точек измерения
 Подготовка точек масштабирования
 Принципы выбора оборудования
 Единицы измерения
 Методика измерения

30


Роли в проекте
 Product Management
 Development Engineering (Разработка)

 Operations Engineering (Эксплуатация)

31


Роли в проекте: конфликт интересов

32


Методология DevOps

33


Роли в рамках различных лекций
 В рамках этой лекции мы в отделе эксплуатации либо
на позиции технического директора
 Наши задачи в качестве руководителя разработки мы
рассмотрим в последних лекциях про архитектуру

34


Установка целей
 Получить требования от продуктовых менеджеров
 Сформулировать требования в конкретных метриках
(время ответа, % ошибок в ответах, uptime)
 Проверить измеримость исполнения требований
 Зафиксировать в Service Level Agreement (SLA)

35


Входная информация для планирования
 Прогноз по росту проекта в продуктовых метриках
 Статистика по проекту за предыдущий период

 Ограничения (бюджет) по расходам на ИТ
 Ограничения по качеству работы сервиса (SLA)

36


Доступность (Uptime)
Доступность %

Время простоя в год Время простоя в месяц

99% ("две девятки")

3.65 дней

7.20 часов

99.5%

1.83 дней

3.60 часов

99.9% ("три девятки")

8.76 часов

43.2 минут

99.95%

4.38 часов

21.56 минут

52.56 минут

4.32 минут

99.999% ("пять девяток")

5.26 минут

25.9 секунд

99.9999% ("шесть девяток”)

31.5 секунд

2.59 секунды

99.99% ("четыре девятки”)

37


Вопросы на которые нужно уметь отвечать
 Какую нагрузку может выдержать сервис в текущей
конфигурации ?
 Какую нагрузку сервис выдержит если добавить N
дополнительных серверов ?
 Сколько и каких серверов нужно чтобы обслуживать
заданную нагрузку в заданных условиях ?

 Как планировать закупки оборудования исходя из
планирующегося роста ?

38


Сервер имеет ограниченные ресурсы
 Disk utilization
 Disk storage

 CPU
 RAM
 Network

39


Первый сервер Павла Дурова
 БД и веб-сервер на одном физическом сервере
 Можно настроить снятие метрик (как указано далее)

 Однако невозможно понять какой сервис какие ресурсы
сервера использует в каком
 Невозможно понять каким из сервисов вызвана
перегрузка ресурса

 Возможен частный случай когда используемые ресурсы
не пересекаются но он довольно редкий

40


Подготовка точек измерения
 Система должны быть разбита на компоненты
 Один компонент - одна или несколько функций

 Разные функции должны «жить» на разных серверах
 Под каждую функцию выделяется своя группа серверов
внутри которой осуществляется горизонтальное
масштабирование

 Можно проследить связь между полезной нагрузкой на
компоненту и загрузкой подсистем физического сервера

41


Определение максимальной нагрузки
 Сервис расходует разные компоненты по-разному
 При повышении нагрузки какой-то один ресурс кончится

 Значение нагрузки в этот момент – предельное
 Дальше сервис как правило не работает
 Такой метод – самый надежный и простой

42


Выбор конфигурации оборудования
 Разные сервисы имеют разные узкие места
 Под каждый сервис отдельная конфигурация

 На неиспользуемых ресурсах экономим
 Используемыми ресурсами набиваем по максимуму
 Железо со временем становится мощнее
 Замена оборудования на новое может окупиться
(по использованию электроэнергии и юнитам в стойке)

43


Масштабирование
 Вертикальное
(покупаем все более и более мощный сервер)
 Горизонтальное
(покупаем много дешевых однотипных серверов)
 “Диагональное”
(термин Jonh Allspaw описывает существующий метод)
* Нужно учитывать совокупные затраты, построение
горизонтально масштабируемого ПО стоит денег
44


Требования к инструментам измерения
 Хранение истории измерений
 Возможность добавления пользовательских метрик

 Удобная визуализация данных (графики!)
 Сравнение метрик из разных источников
 Импорт/экспорт данных

45


Выбор инструмента измерения
 Не так важно какой инструмент использовать
 Важно выбрать правильные метрики для измерения

 Важно выбрать ключевые метрики для анализа
 Съем метрик с сервера не должен его нагружать
Примеры систем: Cacti, Munin, Ganglia, MRTG, Graphite*

46


Взаимодействие с системами мониторинга
 Не нужно путать систему построения графиков с
другими системами понимаемыми под «мониторингом»
 Графики не создают аварийных уведомлений, не
включают сирену и ничего сами не «мониторят»
 Графики просто используются для анализа
функционирования системы во времени

 Часто это полностью независимая система

47


Типовое устройство

48


Популярные инструменты и методики
 RRDTool – циклическая база данных
 SNMP – протокол удаленного съема метрик

 Графики по метрикам приложений
 Графики по логам сервисов
(метрика последней надежды)

49


Популярные метрики
 RPS – кол-во запросов в секунду (веб-сервер)
 QPS – кол-во запросов в секунду (БД)

 PPS – кол-во пакетов в секунду (сетевое оборудование)
 Мbit/s – загрузка каналов связи


50

http://www.liveinternet.ru/stat/mail.ru/mins.html

51

http://www.liveinternet.ru/stat/vkontakte.ru/mins.html

52


53


54


55


Slashdot-эффект

56


DDoS атака

57


Страницы ошибок
 Как правило не предназначены для пользователя
 Плохо настроены потому что падать не планируется

 Иногда встречаются настоящие шедевры

58


503 Service Unavailable

59


504 Gateway Timeout

60



61



62



63


500 Internal Server Error

64



65



66


Архитектура сетевого приложения
 Самое распространенное приложение: веб-сервер
 Самый распространенный веб-сервер: Apache

 К сожалению далеко не самый быстрый
 На примере этой задачи будем учиться писать ПО для
высоких нагрузок

67


Блокирующая обработка соединений

68


Методы обработки большого кол-ва соединений
 fork
 prefork

 threads
 threads prefork
 pooling

69


Неблокирующая обработка соединений
Системные вызовы:
 select
 kqueue (FreeBSD 4.1+)
 epoll (Linux 2.6+)
Прикладные библиотеки:
 libevent
 libev

Веб-серверы:
 nginx
 lighttpd
 thttpd
 0W-httpd
 Tornado
 Node.js

70


Статистика по распространенности серверов

71


Устройство типового веб-сайта

/Perl /Python
72


Устройство типового веб-сайта

73


Подключение динамического содержимого
 CGI
 FastCGI и клоны

 Apache: mod_php, mod_perl, mod_python …
 Apache: mod_helloworld
 nginx: ngx_http_helloworld_module
 nginx: content_by_lua

74


Домашнее задание №1
 Разработать веб-сервер отдающий статику с диска

 Рекомендуется выбрать эффективную архитектуру
 Требования и методика тестирования по ссылке:
https://github.com/init/http-test-suite

75


Список литературы
1. The Art of Capacity Planning
ISBN: 978-0-596-51857-8
2. The С10K Problem
http://www.kegel.com/c10k.html
3. Сравнительный анализ архитектур серверных
интернет-приложений для высоких нагрузок. Игорь
Сысоев. 03.11. 2011 (лекция 1ч 31м)
https://www.youtube.com/watch?v=aE0yawwB6h4
4. Hypertext Transfer Protocol -- HTTP/1.1
RFC 2616
76


Список литературы
5. Building Scalable Web Sites
ISBN: 978-0-596-10235-7
6. Scalable Internet Architectures
ISBN: 978-0-596-51857-8

77

СПАСИБО ЗА ВНИМАНИЕ

Быков Александр
bykov@corp.mail.ru

HighLoad весна 2014 лекция 1

More Related Content

Viewers also liked (10)

Similar to HighLoad весна 2014 лекция 1 (20)

More from Technopark (20)

HighLoad весна 2014 лекция 1

Editor's Notes