2. HighLoad. Лекция №1
О преподавателе
Быков Александр Сергеевич
Сотрудник Mail.Ru c 2004 года
Технический руководитель рекламной системы
Начинал с позиции веб-разработчика в Почте
Выпускник МГТУ им. Н.Э.Баумана 2006 года
2
3. HighLoad. Лекция №1
Определения
Система — множество элементов, находящихся в
отношениях и связях друг с другом, которое образует
определѐнную целостность, единство. (М.: БРЭ. — 2003,
с. 1437)
В нашем случае – множество серверов и программ на них
работающих, представляющих в сумме веб-сервис для
конечного пользователя.
3
4. HighLoad. Лекция №1
Определения
Нагрузка — совершаемая полезная работа
Максимальная нагрузка – верхний предел совершаемой
полезной работы в данной конфигурации системы
Высоконагруженная система – система выполняющая
объем работы значительно превышающий общепринятый
4
5. HighLoad. Лекция №1
Предметная область: веб-сервисы
Ярко выраженный эффект масштаба
Популярность изменяется очень быстро
Могут использоваться миллионами людей
Необходимо учитывать нагрузку при проектировании
Умение держать нагрузку – вопрос выживания
5
6. HighLoad. Лекция №1
Задача: миллиард пользователей
Как должна быть устроена такая система ?
Как должна быть организована работа кампании ?
Как планировать закупки оборудования ?
Как предсказать изменения нагрузки ?
Это вообще возможно ?
6
7. HighLoad. Лекция №1
Цели курса
Получение теоретических знаний в области
проектирования и эксплуатации высоконагруженных
систем
Получение практических навыков разработки
высокопроизводительных сервисов
Получение практических навыков анализа архитектуры
интернет-проектов и технологий
7
8. HighLoad. Лекция №1
Место курса в программе обучения
Предшествующие:
1 семестр: Web-технологии
2 семестр: Базы данных
Параллельные:
QA и Безопасность
Последующие:
4 семестр: Разработка веб-сервисов
4 семестр: Системный анализ для архитекторов
8
9. HighLoad. Лекция №1
Входные требования
Отличное знание протокола HTTP
Навыки разработки многопоточных приложений
Навыки проектирования баз данных
Базовые навыки работы в ОС семейства UNIX
Базовые знания об устройстве сетей
9
10. HighLoad. Лекция №1
Выходные требования
Навык разработки распределенного ПО
Навык разработки ПО с учетом нагрузки
Навык разработки ПО пригодного для эксплуатации
Навык проектирования распределенных систем
10
11. HighLoad. Лекция №1
Программа курса: лекции
1. Планирование мощностей
2. Сетевая подсистема
3. Оперативная память
4. Дисковая подсистема
5. Фронтенд-оптимизация
6. Масштабирование нагрузки
7. Планирование архитектуры
11
12. HighLoad. Лекция №1
Программа курса: домашние задания
1. Разработка быстрого веб-сервера (5 апреля)
2. Нагрузочное тестирование веб-сервера (19 апреля)
3. Измерение размера кэша процессора (17 мая)
4. Анализ архитектуры интернет-проекта (24 мая)
Сдача раньше срока приветствуется
Сдача позже срока – половина баллов
12
14. HighLoad. Лекция №1
Конец вводной части
Познакомились друг с другом
Разобрались зачем нужен этот курс
Убедились в важности этого курса
Узнали что нас ждет на занятиях
14
15. HighLoad. Лекция №1
Содержание лекции
Анализ предметной области
Управление вычислительными мощностями
Архитектура многопоточного сетевого ПО
15
16. HighLoad. Лекция №1
Анализ предметной области
Особенности интернет проектов
Аудитория интернета
Продуктовые метрики
16
18. HighLoad. Лекция №1
Легкость входа на рынок
Доступность сервиса из любой точки мира
Низкая стоимость доставки сервиса потребителю
Низкая стоимость разработки и эксплуатации
Практически «нулевой» порог входа
18
19. HighLoad. Лекция №1
Динамичность рынка
Высокая конкурентность рынка
Низкая привязанность пользователей к сервису
Популярность сервиса может расти очень быстро
… а падать еще быстрее
Факторы: качество обслуживания
19
20. HighLoad. Лекция №1
Особенности монетизации
Низкая/нулевая доходность на одного пользователя
Сначала аудитория потом монетизация
ИТ-инфраструктура основная статья расходов
В некоторых случаях начальные затраты велики
Не все проекты выходят на окупаемость
20
21. HighLoad. Лекция №1
ИТ-инфраструктура
Основа бизнеса и основная статья расходов
Высокие требования по скорости разработки
Высокие требования по масштабированию
Высокие требования по эффективности
Невыполнение равно выходу из бизнеса
21
29. HighLoad. Лекция №1
Возможные продуктовые метрики
Количество зарегистрированных пользователей
Суточная/недельная/месячная аудитория
Максимальное количество пользователей онлайн
Количество пользователей использующих функцию
Интенсивность использования разных функций
Средний размер данных пользователя
и т.п.
29
30. HighLoad. Лекция №1
Управление вычислительными мощностями
Роли людей в проекте
Постановка целей управления
Подготовка точек измерения
Подготовка точек масштабирования
Принципы выбора оборудования
Единицы измерения
Методика измерения
30
31. HighLoad. Лекция №1
Роли в проекте
Product Management
Development Engineering (Разработка)
Operations Engineering (Эксплуатация)
31
34. HighLoad. Лекция №1
Роли в рамках различных лекций
В рамках этой лекции мы в отделе эксплуатации либо
на позиции технического директора
Наши задачи в качестве руководителя разработки мы
рассмотрим в последних лекциях про архитектуру
34
35. HighLoad. Лекция №1
Установка целей
Получить требования от продуктовых менеджеров
Сформулировать требования в конкретных метриках
(время ответа, % ошибок в ответах, uptime)
Проверить измеримость исполнения требований
Зафиксировать в Service Level Agreement (SLA)
35
36. HighLoad. Лекция №1
Входная информация для планирования
Прогноз по росту проекта в продуктовых метриках
Статистика по проекту за предыдущий период
Ограничения (бюджет) по расходам на ИТ
Ограничения по качеству работы сервиса (SLA)
36
37. HighLoad. Лекция №1
Доступность (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
38. HighLoad. Лекция №1
Вопросы на которые нужно уметь отвечать
Какую нагрузку может выдержать сервис в текущей
конфигурации ?
Какую нагрузку сервис выдержит если добавить N
дополнительных серверов ?
Сколько и каких серверов нужно чтобы обслуживать
заданную нагрузку в заданных условиях ?
Как планировать закупки оборудования исходя из
планирующегося роста ?
38
39. HighLoad. Лекция №1
Сервер имеет ограниченные ресурсы
Disk utilization
Disk storage
CPU
RAM
Network
39
40. HighLoad. Лекция №1
Первый сервер Павла Дурова
БД и веб-сервер на одном физическом сервере
Можно настроить снятие метрик (как указано далее)
Однако невозможно понять какой сервис какие ресурсы
сервера использует в каком
Невозможно понять каким из сервисов вызвана
перегрузка ресурса
Возможен частный случай когда используемые ресурсы
не пересекаются но он довольно редкий
40
41. HighLoad. Лекция №1
Подготовка точек измерения
Система должны быть разбита на компоненты
Один компонент - одна или несколько функций
Разные функции должны «жить» на разных серверах
Под каждую функцию выделяется своя группа серверов
внутри которой осуществляется горизонтальное
масштабирование
Можно проследить связь между полезной нагрузкой на
компоненту и загрузкой подсистем физического сервера
41
42. HighLoad. Лекция №1
Определение максимальной нагрузки
Сервис расходует разные компоненты по-разному
При повышении нагрузки какой-то один ресурс кончится
Значение нагрузки в этот момент – предельное
Дальше сервис как правило не работает
Такой метод – самый надежный и простой
42
43. HighLoad. Лекция №1
Выбор конфигурации оборудования
Разные сервисы имеют разные узкие места
Под каждый сервис отдельная конфигурация
На неиспользуемых ресурсах экономим
Используемыми ресурсами набиваем по максимуму
Железо со временем становится мощнее
Замена оборудования на новое может окупиться
(по использованию электроэнергии и юнитам в стойке)
43
44. HighLoad. Лекция №1
Масштабирование
Вертикальное
(покупаем все более и более мощный сервер)
Горизонтальное
(покупаем много дешевых однотипных серверов)
“Диагональное”
(термин Jonh Allspaw описывает существующий метод)
* Нужно учитывать совокупные затраты, построение
горизонтально масштабируемого ПО стоит денег
44
45. HighLoad. Лекция №1
Требования к инструментам измерения
Хранение истории измерений
Возможность добавления пользовательских метрик
Удобная визуализация данных (графики!)
Сравнение метрик из разных источников
Импорт/экспорт данных
45
46. HighLoad. Лекция №1
Выбор инструмента измерения
Не так важно какой инструмент использовать
Важно выбрать правильные метрики для измерения
Важно выбрать ключевые метрики для анализа
Съем метрик с сервера не должен его нагружать
Примеры систем: Cacti, Munin, Ganglia, MRTG, Graphite*
46
47. HighLoad. Лекция №1
Взаимодействие с системами мониторинга
Не нужно путать систему построения графиков с
другими системами понимаемыми под «мониторингом»
Графики не создают аварийных уведомлений, не
включают сирену и ничего сами не «мониторят»
Графики просто используются для анализа
функционирования системы во времени
Часто это полностью независимая система
47
58. HighLoad. Лекция №1
Страницы ошибок
Как правило не предназначены для пользователя
Плохо настроены потому что падать не планируется
Иногда встречаются настоящие шедевры
58
67. HighLoad. Лекция №1
Архитектура сетевого приложения
Самое распространенное приложение: веб-сервер
Самый распространенный веб-сервер: Apache
К сожалению далеко не самый быстрый
На примере этой задачи будем учиться писать ПО для
высоких нагрузок
67
75. HighLoad. Лекция №1
Домашнее задание №1
Разработать веб-сервер отдающий статику с диска
Рекомендуется выбрать эффективную архитектуру
Требования и методика тестирования по ссылке:
https://github.com/init/http-test-suite
75
76. HighLoad. Лекция №1
Список литературы
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
77. HighLoad. Лекция №1
Список литературы
5. Building Scalable Web Sites
ISBN: 978-0-596-10235-7
6. Scalable Internet Architectures
ISBN: 978-0-596-51857-8
77
10 лет в веб-разработкеКакими проектами я занимался (Почта, Фото, Блоги, Реклама)Какой архитектурный опыт у меня имеется (рост почты с десятков до нескольких тысяч серверов)Почему я трачу свое время на чтение этого курса ?- хочу научить делать то что я умею, и что не умеют обычные разработчики- каждый разработчик должен хотеть стать системным архитектором, а админ – техническим директором
Сослаться на теорию управления (кибернетику, АСУ)
Пишем веб – подразумеваем любой сервис ориентированный на массового пользователя работающий по сети интернет.Многие подходы (но не все) могут быть применимы к другим отраслям.(ссылка на блок про предметную область который будет дальше в этой лекции)Примечания:Эффект масштаба – уменьшение издержек на пользователя (победитель получает все)Facebook – 1.23 млрд активных пользователей в декабре 2013 (месячная аудитория)
Если ничего не делать сервис не выдержит нагрузки и «упадет» то пользователи уйдут к конкуренту, навсегда.Сервис который регулярно «лежит» или тормозит пользователям не нравится, они хотят предсказуемости и удобства.
Задача научить думать нагрузками как при написании кода, так и при системном администрированииРазработчики должны думать как админы когда пишут код, а админы всегда думают про нагрузку и масштабирование
До этого вы делали просто сайт и просто базу данных (уточнить что было в БД про «нагрузки»),теперь масштабируем то что написали на много много серверов (= пишем заново правильно).Когда пишем код учитываем требования QA, Безопасности, масштабируемости, надежности (курсы в этом семестре) а еще удобства поддержки и модификации под изменяющиеся бизнес-требования (4 семестр).
Профилировка аудитории, вопросы:Чем отличаются процессы от потоков, что делает fork, что такое GIL, как выделяется/чистится память в C/Java, что такое pooling, сколько пакетов нужно чтобы установить и разорвать TCP/IP соединение, как работает MySQL репликация, чем отличается MyISAM от InnoDB, что такое chunked-encoding, как работает keep-alive, как на одном IP живет несколько сайтов, чем отличается apache от nginx ? Кто читает хабрахабр ?К 3-ей лекции должны выучить целиком, незнание протокола – неуд на экзаменеRFC 2616: HypertextTransferProtocol -- HTTP/1.1
Мы почти НЕ обсуждаем:сбор бизнес требованийуправление разработкойнепосредственно разработку ПОСейчас мы работаем админами и решаем задачи отдела эксплуатации (почти).
Подразумеваем ОС Linux.Формат взаимодействия: интерактивный, если вы не будете активно участвовать и задавать вопросы - толку не будетВ этой области нет теории которую можно выучить, есть практический опыт которым можно поделиться.
На этом курсе у вас только программирование под Android, а поскольку технопарк ориентирован на практику я вынужден давать практические домашние задание по разработке в то время как курс у вас про архитектуру, зато пощупаете нагрузку, да и админы (Игорь Сысоев) тоже иногда программируют решая свои админские задачи.
Подробнее будет в курсе «Управление продуктом», сейчас только те моменты которые нам нужны
1. На самом деле доступность ресурсов на другом континенте может быть не довольно низкой, об этом в Лекции №22. Для видео-сервисов стоимость канала уже один из важнейших факторов в структуре затрат3. Ошибки легко находить прямо на пользователях и на них же править, моментальное применение новых версий4. На самом деле есть вещи которые привязывают пользователя (данные), и ограничивают миграцию (язык)
1. На самом деле доступность ресурсов на другом континенте может быть не довольно низкой, об этом в Лекции №22. Для видео-сервисов стоимость канала уже один из важнейших факторов в структуре затрат3. Ошибки легко находить прямо на пользователях и на них же править, моментальное применение новых версий
Рост по экспоненте довольно частое явлениеПример умерших сервисовне справившихся с нагрузкой: mySpaceНа самом деле есть вещи которые привязывают пользователя (данные), и ограничивают миграцию (язык)
Twitter – пример сервиса который очень популярен но не научился зарабатыватьFacebook – пример сервиса который долго был безприбылен, а потом исправилсяПоиск – пример сервиса с очень дорогим начальным взносом
Расходы: см. публичные отчеты Mail.Ru, Yandex, Google, Facebook, зарплаты и сервера вот и все расходыЭффективность важна - иначе не будет окупаться (потом в вертикальном масштабировании указать на важность стоимости)Пример умерших сервисовне справившихся с нагрузкой: mySpace (правда твиттеру это не сильно помешало)
1. На самом деле доступность ресурсов на другом континенте может быть не довольно низкой, об этом в Лекции №22. Для видео-сервисов стоимость канала уже один из важнейших факторов в структуре затрат3. Ошибки легко находить прямо на пользователях и на них же править, моментальное применение новых версий4. На самом деле есть вещи которые привязывают пользователя (данные), и ограничивают миграцию (язык)
Надо заменить слайд потому что нет Google, но по нему данных нетНадо дать скорректированную аудиторию Facebook:
Источник: TNS
Аудиторные метрики позволяют планировать размеры хранилищ и сложность операций поискаФункциональные метрики измеряют конкретные запросы обработка которых загружает вычислительные мощностиПривести ключевые метрики разных сервисовmail.ru
Как вариант позиция главного инженера координирующего работу отделов и являющегося экспертом в работе всех отделов.Как правило это технический руководитель проекта (технический директор)
Нужно перевести продуктовые метрики в нагрузку на сервера и расширить узкие места, соблюдая все ограничения
Ответить на эти вопросы невозможно без детального анализа архитектуры, общих взаимосвязей между компонентами и анализа загрузки по отдельным подсистемам.
Может еще упереться по некоторым другим метрикам
Проект начинающий путь к мировому господствуПример: memcached на фронтендах в архитектуре LiveJournalПоэтому общее правило на следующем слайде: разлеляй всеЯ лично видел много проектов где из-за несоблюдения правила было много проблем (Яндекс и OOM-killer)
Подробнее про дизайн архитектуры в последних лекциях, сейчас мы формулируем требованияКниги по архитектуре интернет проектов – в списке литературы
Аналогия с максимальной допустимой массой на мосту и методом ее установки запуском грузовиков.Способ получения: веса в балансировщике нагрузки (4-ая лекция)Контроль на новых версиях ПО: сервер с постоянной двойной нагрузкой
Но при этом следим за удельной стоимостью ресурса – в местах где легко горизонтально масштабируется.Там где нет сравниваем потенциальную экономию на железе и затраты на разработку (исскуство, формальных критериев нет)
Суть метода: «вертикально масштабируем горизонтально масштабируемые ноды»Неиспользование последнего метода ведет к резкому увеличению затрат на железо, а для второго случая и затрат на разработку сложного распределенного ПО.Создание Share nothing архитектуры часто бывает сложным или невозможным
Cacti иMunin по отзывам не расчитаны на большое кол-во серверов но наиболее популярны.Ganglia разработана для больших кластеров и должна подойти.MRTG – для сетевого оборудования (SNMP)К сожалению я знаком только с одной системой – Graphite, она не занимается сбором данных, а только строит графики.
Графики позволяют делать capacity decisions и problem resolution, в том числе аварийное.Организацию мониторинга, управления изменениями и качеством будем рассматривать позднее.
Измерение отдельных подсистем будем рассматривать отдельно в следующих лекциях
Кол-во запросов иногда измеряют в запросах в минуту, когда цифра запросов в секунду слишком маленькая/неудобная.
Проблемы с доступностью вконтакте.
Проблемы с доступностью вконтакте.
в данном случае «1 UDP-пакет» = «1 запрос»1сервер «тянет» порядка 120 000 PPS,, поэтому используем много серверов
Он же «хабраэффект»
Заказали конкуренты
В качестве эталонного сервера будем расказывать про nginx.