• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
HighLoad весна 2014 лекция 1
 

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

on

  • 626 views

 

Statistics

Views

Total Views
626
Views on SlideShare
554
Embed Views
72

Actions

Likes
0
Downloads
6
Comments
0

1 Embed 72

https://tech-mail.ru 72

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.
  • Следующим заданием будет нагрузочное тестирование

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

  • Проектирование высоконагруженных систем Лекция №1 Быков Александр
  • HighLoad. Лекция №1 О преподавателе  Быков Александр Сергеевич  Сотрудник Mail.Ru c 2004 года  Технический руководитель рекламной системы  Начинал с позиции веб-разработчика в Почте  Выпускник МГТУ им. Н.Э.Баумана 2006 года 2
  • HighLoad. Лекция №1 Определения Система — множество элементов, находящихся в отношениях и связях друг с другом, которое образует определѐнную целостность, единство. (М.: БРЭ. — 2003, с. 1437) В нашем случае – множество серверов и программ на них работающих, представляющих в сумме веб-сервис для конечного пользователя. 3
  • HighLoad. Лекция №1 Определения Нагрузка — совершаемая полезная работа Максимальная нагрузка – верхний предел совершаемой полезной работы в данной конфигурации системы Высоконагруженная система – система выполняющая объем работы значительно превышающий общепринятый 4
  • HighLoad. Лекция №1 Предметная область: веб-сервисы  Ярко выраженный эффект масштаба  Популярность изменяется очень быстро  Могут использоваться миллионами людей  Необходимо учитывать нагрузку при проектировании  Умение держать нагрузку – вопрос выживания 5
  • HighLoad. Лекция №1 Задача: миллиард пользователей  Как должна быть устроена такая система ?  Как должна быть организована работа кампании ?  Как планировать закупки оборудования ?  Как предсказать изменения нагрузки ?  Это вообще возможно ? 6
  • HighLoad. Лекция №1 Цели курса  Получение теоретических знаний в области проектирования и эксплуатации высоконагруженных систем  Получение практических навыков разработки высокопроизводительных сервисов  Получение практических навыков анализа архитектуры интернет-проектов и технологий 7
  • HighLoad. Лекция №1 Место курса в программе обучения Предшествующие:  1 семестр: Web-технологии  2 семестр: Базы данных Параллельные:  QA и Безопасность Последующие:  4 семестр: Разработка веб-сервисов  4 семестр: Системный анализ для архитекторов 8
  • HighLoad. Лекция №1 Входные требования  Отличное знание протокола HTTP  Навыки разработки многопоточных приложений  Навыки проектирования баз данных  Базовые навыки работы в ОС семейства UNIX  Базовые знания об устройстве сетей 9
  • HighLoad. Лекция №1 Выходные требования  Навык разработки распределенного ПО  Навык разработки ПО с учетом нагрузки  Навык разработки ПО пригодного для эксплуатации  Навык проектирования распределенных систем 10
  • HighLoad. Лекция №1 Программа курса: лекции 1. Планирование мощностей 2. Сетевая подсистема 3. Оперативная память 4. Дисковая подсистема 5. Фронтенд-оптимизация 6. Масштабирование нагрузки 7. Планирование архитектуры 11
  • HighLoad. Лекция №1 Программа курса: домашние задания 1. Разработка быстрого веб-сервера (5 апреля) 2. Нагрузочное тестирование веб-сервера (19 апреля) 3. Измерение размера кэша процессора (17 мая) 4. Анализ архитектуры интернет-проекта (24 мая) Сдача раньше срока приветствуется Сдача позже срока – половина баллов 12
  • HighLoad. Лекция №1 Контроль знаний 1. Разработка быстрого веб-сервера (20 баллов) 2. Нагрузочное тестирование веб-сервера (10 баллов) 3. Измерение размера кэша процессора (10 баллов) 4. Анализ архитектуры интернет-проекта (10 баллов) 5. Экзамен (60 баллов) Оценка на экзамене: удовл. – 20 баллов, хор. – 40 баллов Пороговый рейтинг 60 баллов 13
  • HighLoad. Лекция №1 Конец вводной части  Познакомились друг с другом  Разобрались зачем нужен этот курс  Убедились в важности этого курса  Узнали что нас ждет на занятиях 14
  • HighLoad. Лекция №1 Содержание лекции  Анализ предметной области  Управление вычислительными мощностями  Архитектура многопоточного сетевого ПО 15
  • HighLoad. Лекция №1 Анализ предметной области  Особенности интернет проектов  Аудитория интернета  Продуктовые метрики 16
  • HighLoad. Лекция №1 Особенности интернет-проектов 17
  • HighLoad. Лекция №1 Легкость входа на рынок  Доступность сервиса из любой точки мира  Низкая стоимость доставки сервиса потребителю  Низкая стоимость разработки и эксплуатации  Практически «нулевой» порог входа 18
  • HighLoad. Лекция №1 Динамичность рынка  Высокая конкурентность рынка  Низкая привязанность пользователей к сервису  Популярность сервиса может расти очень быстро  … а падать еще быстрее  Факторы: качество обслуживания 19
  • HighLoad. Лекция №1 Особенности монетизации  Низкая/нулевая доходность на одного пользователя  Сначала аудитория потом монетизация  ИТ-инфраструктура основная статья расходов  В некоторых случаях начальные затраты велики  Не все проекты выходят на окупаемость 20
  • HighLoad. Лекция №1 ИТ-инфраструктура  Основа бизнеса и основная статья расходов  Высокие требования по скорости разработки  Высокие требования по масштабированию  Высокие требования по эффективности  Невыполнение равно выходу из бизнеса 21
  • HighLoad. Лекция №1 Аудитория интернета 22
  • HighLoad. Лекция №1 Аудитория интернета: Россия 23
  • HighLoad. Лекция №1 Аудитория интернета: Северная Америка 24
  • HighLoad. Лекция №1 Аудитория интернета: Мир 25
  • HighLoad. Лекция №1 Аудитория интернета: Мир 26
  • HighLoad. Лекция №1 Аудитория проектов: Мир 27
  • HighLoad. Лекция №1 Аудитория проектов: Россия 28
  • HighLoad. Лекция №1 Возможные продуктовые метрики  Количество зарегистрированных пользователей  Суточная/недельная/месячная аудитория  Максимальное количество пользователей онлайн  Количество пользователей использующих функцию  Интенсивность использования разных функций  Средний размер данных пользователя  и т.п. 29
  • HighLoad. Лекция №1 Управление вычислительными мощностями  Роли людей в проекте  Постановка целей управления  Подготовка точек измерения  Подготовка точек масштабирования  Принципы выбора оборудования  Единицы измерения  Методика измерения 30
  • HighLoad. Лекция №1 Роли в проекте  Product Management  Development Engineering (Разработка)  Operations Engineering (Эксплуатация) 31
  • HighLoad. Лекция №1 Роли в проекте: конфликт интересов 32
  • HighLoad. Лекция №1 Методология DevOps 33
  • HighLoad. Лекция №1 Роли в рамках различных лекций  В рамках этой лекции мы в отделе эксплуатации либо на позиции технического директора  Наши задачи в качестве руководителя разработки мы рассмотрим в последних лекциях про архитектуру 34
  • HighLoad. Лекция №1 Установка целей  Получить требования от продуктовых менеджеров  Сформулировать требования в конкретных метриках (время ответа, % ошибок в ответах, uptime)  Проверить измеримость исполнения требований  Зафиксировать в Service Level Agreement (SLA) 35
  • HighLoad. Лекция №1 Входная информация для планирования  Прогноз по росту проекта в продуктовых метриках  Статистика по проекту за предыдущий период  Ограничения (бюджет) по расходам на ИТ  Ограничения по качеству работы сервиса (SLA) 36
  • 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
  • HighLoad. Лекция №1 Вопросы на которые нужно уметь отвечать  Какую нагрузку может выдержать сервис в текущей конфигурации ?  Какую нагрузку сервис выдержит если добавить N дополнительных серверов ?  Сколько и каких серверов нужно чтобы обслуживать заданную нагрузку в заданных условиях ?  Как планировать закупки оборудования исходя из планирующегося роста ? 38
  • HighLoad. Лекция №1 Сервер имеет ограниченные ресурсы  Disk utilization  Disk storage  CPU  RAM  Network 39
  • HighLoad. Лекция №1 Первый сервер Павла Дурова  БД и веб-сервер на одном физическом сервере  Можно настроить снятие метрик (как указано далее)  Однако невозможно понять какой сервис какие ресурсы сервера использует в каком  Невозможно понять каким из сервисов вызвана перегрузка ресурса  Возможен частный случай когда используемые ресурсы не пересекаются но он довольно редкий 40
  • HighLoad. Лекция №1 Подготовка точек измерения  Система должны быть разбита на компоненты  Один компонент - одна или несколько функций  Разные функции должны «жить» на разных серверах  Под каждую функцию выделяется своя группа серверов внутри которой осуществляется горизонтальное масштабирование  Можно проследить связь между полезной нагрузкой на компоненту и загрузкой подсистем физического сервера 41
  • HighLoad. Лекция №1 Определение максимальной нагрузки  Сервис расходует разные компоненты по-разному  При повышении нагрузки какой-то один ресурс кончится  Значение нагрузки в этот момент – предельное  Дальше сервис как правило не работает  Такой метод – самый надежный и простой 42
  • HighLoad. Лекция №1 Выбор конфигурации оборудования  Разные сервисы имеют разные узкие места  Под каждый сервис отдельная конфигурация  На неиспользуемых ресурсах экономим  Используемыми ресурсами набиваем по максимуму  Железо со временем становится мощнее  Замена оборудования на новое может окупиться (по использованию электроэнергии и юнитам в стойке) 43
  • HighLoad. Лекция №1 Масштабирование  Вертикальное (покупаем все более и более мощный сервер)  Горизонтальное (покупаем много дешевых однотипных серверов)  “Диагональное” (термин Jonh Allspaw описывает существующий метод) * Нужно учитывать совокупные затраты, построение горизонтально масштабируемого ПО стоит денег 44
  • HighLoad. Лекция №1 Требования к инструментам измерения  Хранение истории измерений  Возможность добавления пользовательских метрик  Удобная визуализация данных (графики!)  Сравнение метрик из разных источников  Импорт/экспорт данных 45
  • HighLoad. Лекция №1 Выбор инструмента измерения  Не так важно какой инструмент использовать  Важно выбрать правильные метрики для измерения  Важно выбрать ключевые метрики для анализа  Съем метрик с сервера не должен его нагружать Примеры систем: Cacti, Munin, Ganglia, MRTG, Graphite* 46
  • HighLoad. Лекция №1 Взаимодействие с системами мониторинга  Не нужно путать систему построения графиков с другими системами понимаемыми под «мониторингом»  Графики не создают аварийных уведомлений, не включают сирену и ничего сами не «мониторят»  Графики просто используются для анализа функционирования системы во времени  Часто это полностью независимая система 47
  • HighLoad. Лекция №1 Типовое устройство 48
  • HighLoad. Лекция №1 Популярные инструменты и методики  RRDTool – циклическая база данных  SNMP – протокол удаленного съема метрик  Графики по метрикам приложений  Графики по логам сервисов (метрика последней надежды) 49
  • HighLoad. Лекция №1 Популярные метрики  RPS – кол-во запросов в секунду (веб-сервер)  QPS – кол-во запросов в секунду (БД)  PPS – кол-во пакетов в секунду (сетевое оборудование)  Мbit/s – загрузка каналов связи  50
  • HighLoad. Лекция №1 http://www.liveinternet.ru/stat/mail.ru/mins.html 51
  • HighLoad. Лекция №1 http://www.liveinternet.ru/stat/vkontakte.ru/mins.html 52
  • HighLoad. Лекция №1 53
  • HighLoad. Лекция №1 54
  • HighLoad. Лекция №1 55
  • HighLoad. Лекция №1 Slashdot-эффект 56
  • HighLoad. Лекция №1 DDoS атака 57
  • HighLoad. Лекция №1 Страницы ошибок  Как правило не предназначены для пользователя  Плохо настроены потому что падать не планируется  Иногда встречаются настоящие шедевры 58
  • HighLoad. Лекция №1 503 Service Unavailable 59
  • HighLoad. Лекция №1 504 Gateway Timeout 60
  • HighLoad. Лекция №1 503 Service Unavailable 61
  • HighLoad. Лекция №1 503 Service Unavailable 62
  • HighLoad. Лекция №1 503 Service Unavailable 63
  • HighLoad. Лекция №1 500 Internal Server Error 64
  • HighLoad. Лекция №1 500 Internal Server Error 65
  • HighLoad. Лекция №1 500 Internal Server Error 66
  • HighLoad. Лекция №1 Архитектура сетевого приложения  Самое распространенное приложение: веб-сервер  Самый распространенный веб-сервер: Apache  К сожалению далеко не самый быстрый  На примере этой задачи будем учиться писать ПО для высоких нагрузок 67
  • HighLoad. Лекция №1 Блокирующая обработка соединений 68
  • HighLoad. Лекция №1 Методы обработки большого кол-ва соединений  fork  prefork  threads  threads prefork  pooling 69
  • HighLoad. Лекция №1 Неблокирующая обработка соединений Системные вызовы:  select  kqueue (FreeBSD 4.1+)  epoll (Linux 2.6+) Прикладные библиотеки:  libevent  libev Веб-серверы:  nginx  lighttpd  thttpd  0W-httpd  Tornado  Node.js 70
  • HighLoad. Лекция №1 Статистика по распространенности серверов 71
  • HighLoad. Лекция №1 Устройство типового веб-сайта /Perl /Python 72
  • HighLoad. Лекция №1 Устройство типового веб-сайта 73
  • HighLoad. Лекция №1 Подключение динамического содержимого  CGI  FastCGI и клоны  Apache: mod_php, mod_perl, mod_python …  Apache: mod_helloworld  nginx: ngx_http_helloworld_module  nginx: content_by_lua 74
  • HighLoad. Лекция №1 Домашнее задание №1  Разработать веб-сервер отдающий статику с диска  Рекомендуется выбрать эффективную архитектуру  Требования и методика тестирования по ссылке: https://github.com/init/http-test-suite 75
  • 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
  • HighLoad. Лекция №1 Список литературы 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