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

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

х систем

Лекция №1

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

HighLoad. Лекция №1

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

О преподавателе

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

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

Определения

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

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

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

Определения

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

проектировании Умение держать нагрузку – вопрос выживания

Предметная область: веб-сервисы

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

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

Задача: миллиард пользователей

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

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

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

Цели курса

Предшествующие: 1 семестр: Web-технологии 2 семестр: Базы данных

Параллельные: QA и Безопасность

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

Место курса в программе обучения

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

Входные требования

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

эксплуатации Навык проектирования распределенных систем

Выходные требования

1. Планирование мощностей

2. Сетевая подсистема

3. Оперативная память

4. Дисковая подсистема

5. Фронтенд-оптимизация

6. Масштабирование нагрузки

7. Планирование архитектуры

Программа курса: лекции

1. Разработка быстрого веб-сервера (5 апреля)

2. Нагрузочное тестирование веб-сервера (19 апреля)

3. Измерение размера кэша процессора (17 мая)

4. Анализ архитектуры интернет-проекта (24 мая)

Сдача раньше срока приветствуетсяСдача позже срока – половина баллов

Программа курса: домашние задания

1. Разработка быстрого веб-сервера (20 баллов)

2. Нагрузочное тестирование веб-сервера (10 баллов)

3. Измерение размера кэша процессора (10 баллов)

4. Анализ архитектуры интернет-проекта (10 баллов)

5. Экзамен (60 баллов)

Оценка на экзамене: удовл. – 20 баллов, хор. – 40 баллов

Пороговый рейтинг 60 баллов

Контроль знаний

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

Конец вводной части

Анализ предметной области Управление вычислительными мощностями Архитектура многопоточного сетевого ПО

Содержание лекции

Особенности интернет проектов Аудитория интернета Продуктовые метрики

Анализ предметной области

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

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

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

Легкость входа на рынок

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

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

Динамичность рынка

Низкая/нулевая доходность на одного пользователя

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

Особенности монетизации

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

ИТ-инфраструктура

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

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

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

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

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

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

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

онлайн Количество пользователей использующих

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

Возможные продуктовые метрики

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

Управление вычислительными мощностями

Product Management Development Engineering (Разработка) Operations Engineering (Эксплуатация)

Роли в проекте

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

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

Роли в рамках различных лекций

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

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

Получить требования от продуктовых менеджеров

Сформулировать требования в конкретных метриках(время ответа, % ошибок в ответах, uptime)

Проверить измеримость исполнения требований Зафиксировать в Service Level Agreement (SLA)

Установка целей

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

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

Входная информация для планирования

Доступность % Время простоя в год Время простоя в месяц

99% ("две девятки") 3.65 дней 7.20 часов

99.5% 1.83 дней 3.60 часов

99.9% ("три девятки") 8.76 часов 43.2 минут

99.95% 4.38 часов 21.56 минут

99.99% ("четыре девятки”) 52.56 минут 4.32 минут

99.999% ("пять девяток") 5.26 минут 25.9 секунд

99.9999% ("шесть девяток”) 31.5 секунд 2.59 секунды

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

Какую нагрузку может выдержать сервис в текущей конфигурации ?

Какую нагрузку сервис выдержит если добавить N дополнительных серверов ?

Сколько и каких серверов нужно чтобы обслуживать заданную нагрузку в заданных условиях ?

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

Вопросы на которые нужно уметь отвечать

Disk utilization Disk storage CPU RAM Network

Сервер имеет ограниченные ресурсы

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

далее) Однако невозможно понять какой сервис какие

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

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

ресурсы не пересекаются но он довольно редкий

Первый сервер Павла Дурова

Система должны быть разбита на компоненты Один компонент - одна или несколько функций Разные функции должны «жить» на разных

серверах Под каждую функцию выделяется своя группа

серверов внутри которой осуществляется горизонтальное масштабирование

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

Подготовка точек измерения

Сервис расходует разные компоненты по-разному

При повышении нагрузки какой-то один ресурс кончится

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

Определение максимальной нагрузки

Разные сервисы имеют разные узкие места Под каждый сервис отдельная конфигурация На неиспользуемых ресурсах экономим Используемыми ресурсами набиваем по

максимуму Железо со временем становится мощнее Замена оборудования на новое может окупиться

(по использованию электроэнергии и юнитам в стойке)

Выбор конфигурации оборудования

Вертикальное(покупаем все более и более мощный сервер)

Горизонтальное(покупаем много дешевых однотипных серверов)

“Диагональное”(термин Jonh Allspaw описывает существующий метод)

* Нужно учитывать совокупные затраты, построение горизонтально масштабируемого ПО стоит денег

Масштабирование

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

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

Требования к инструментам измерения

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

измерения Важно выбрать ключевые метрики для анализа Съем метрик с сервера не должен его

нагружать

Примеры систем: Cacti, Munin, Ganglia, MRTG, Graphite*

Выбор инструмента измерения

Не нужно путать систему построения графиков с другими системами понимаемыми под «мониторингом»

Графики не создают аварийных уведомлений, не включают сирену и ничего сами не «мониторят»

Графики просто используются для анализа функционирования системы во времени

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

Взаимодействие с системами мониторинга

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

RRDTool – циклическая база данных SNMP – протокол удаленного съема метрик Графики по метрикам приложений Графики по логам сервисов

(метрика последней надежды)

Популярные инструменты и методики

RPS – кол-во запросов в секунду (веб-сервер) QPS – кол-во запросов в секунду (БД) PPS – кол-во пакетов в секунду (сетевое

оборудование) Мbit/s – загрузка каналов связи Simultaneous connections – одновременные

соединения

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

Education

Java весна 2014 лекция 2

ТФРВС - весна 2014 - лекция 10

Highload осень 2012 лекция 2

Web весна 2012 лекция 11

C++ весна 2014 лекция 5

Highload осень 2012 лекция 7

Web весна 2013 лекция 9

Web весна 2013 лекция 11

Highload осень 2012 лекция 6

Бизнес весна 2014 лекция 2

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

Highload осень 2012 лекция 1

Highload осень 2012 лекция 4

Тестирование весна 2014 лекция 1

Highload осень 2012 лекция 10

Web весна 2013 лекция 7

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

Java весна 2013 лекция 1

Web весна 2012 лекция 12

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