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

1,602 views

Published on

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,602
On SlideShare
0
From Embeds
0
Number of Embeds
281
Actions
Shares
0
Downloads
31
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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

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

    ×