'

Разработка высоконагруженных проектов

Понравилась презентация – покажи это...





Слайд 0

Разработка высоконагруженных проектов Олег Бунин


Слайд 1

Что такое “большой” проект? Сотни тысяч, миллионы, десятки миллионов хитов; Бесперебойная работа; Сложная структура: серверный парк, большое количество кода; Большое количество данных.


Слайд 2

В чем измерять нагрузку? Посетители; Хосты; Хиты. Технический отдел меряет посещаемость в хитах! Имея прогноз посещаемости можно сделать выводы о использовании процессора, памяти и жестких дисков.


Слайд 3

Зависимость серверного парка от типа проекта Это сравнительная таблица, количество серверов указано относительное именно для сравнения , а не как абсолютные цифры.


Слайд 4

Что такое рост нагрузки с технической точки зрения?


Слайд 5

Типы роста нагрузки Рост ресурсов, требуемых на обработку потока запросов; Рост ресурсов, требуемых для хранения пользовательских данных; Рост ресурсов, требуемых для передачи данных между пользователями и сервером.


Слайд 6

Типичные узкие места проектов


Слайд 7

Требуемые ресурсы при росте посещаемости


Слайд 8

Общее решение


Слайд 9

Горизонтальное масштабирование Увеличение производительности системы за счет подключения дополнительных cерверов. Отлично работает для вычисляющих серверов, а как быть с базой данных? Что делать со связанными общими для нескольких серверов данными?


Слайд 10

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


Слайд 11

Функциональное разбиение Разные функциональные части работают и хранятся на разных серверах системы. В какой то момент мы все равно упремся в физические возможности сервера.


Слайд 12

Шардинг Разбиение данных на кусочки, которые раскладываются по серверам-шардам. Как правильно разбить данные для шардинга? Как правильно идентифицировать данные? У них просто нет выбора:


Слайд 13

Разбиение данных для шардинга Статическое: по первой букве логина, хэширование идентификаторов или логинов. Единого центра нет, соответственно нет узкого места, зато есть сложности с разрешением заранее непредусмотренных ситуаций. Динамическое: есть координирующий центр, который отвечает на вопрос “где лежит”? Он же является узким местом, зато добавление новых серверов происходит без изменения кода.


Слайд 14

Как облегчить масштабирование? Низкая степень связности данных и кода; Разделение кода на слои (как минимум слой связи с базой данных и слой кэширования); Рефакторинг, высокое качество кода, минимизация workaround’ов; Контроль над системой, мониторинг; Минимизация академических решений (построение таблиц “на лету”, ORM).


Слайд 15

Серебряная пуля


Слайд 16

Отдельно о базах данных База данных – типичное узкое место. Для базы данных актуальны все вышеперечисленные методы увеличения производительности: горизонтальное и вертикальное масштабирование, функциональное разбиение, шардинг. Горизонтальное масштабирование в случае с БД достигается с помощью репликации.


Слайд 17

Репликация Синхронизация нескольких копий объекта. Наиболее эффективна при небольшом количестве слейвов, иначе усложняется схема распространения изменений, которое, в дальнейшем, становится узким местом. Усложнение программной архитектуры – например, чтение данных с слейва, до которого не докатились изменения.


Слайд 18

Типичная архитектура: обычный сайт


Слайд 19

Структура типичного веб-проекта Фронтенд – легкий быстрый сервер, отвечающий за отдачу статических картинок; Бекенд – тяжелый программный сервер, производящий вычисления и строящий веб-страницы; База данных, хранилище данных.


Слайд 20

Узкие места


Слайд 21

Узкие места - 2


Слайд 22

Развитие проекта


Слайд 23

Быстрый рост нагрузки – что делать?


Слайд 24

Быстрая помощь Программные решения наиболее эффективны, но требуют много времени; Требуемый уровень специалистов иногда запредельно высок; Хостинг; Более мощное аппаратное обеспечение; Покупка Oracle ;-) Редуцирование функциональности; Уменьшение качества; Оптимизация нагрузки;


Слайд 25

Прогнозирование нагрузки Нагрузочное тестирование. Организация нагрузочного тестирования. Почему стоит заказывать нагрузочное тестирование на стороне? Формулы экстраполяции результатов тестирования на реальную работу. Пиковый характер http-трафика. “Тестирование сферического коня в вакууме”. Опытные оценки, примеры.


Слайд 26

oleg.bunin@ontico.ru LiveJournal: oleg_bunin


×

HTML:





Ссылка: