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

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

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

4. Зависимость серверного парка от
типа проекта
Отношение hit ratio Количество серверов при
одинаковой посещаемости
Корпоративный сайт 1:3 1
СМИ 1:4 1
Интернет-магазин 1:5 1
Фотохостинг 1:10 3
Блогосфера 1:100 5
Социальная сеть 1:50 5
Видеохостинг 1:10 5
Сайт знакомств 1:50 5
Онлайн-игра 30
Это сравнительная таблица, количество серверов указано
относительное именно для сравнения , а не как абсолютные цифры.

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

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

7. Типичные узкие места проектов
Потенциальные проблемы производительности
Корпоративный сайт
СМИ База данных с большим количеством статей,
производительность базы данных
Интернет-магазин Производительность серверов
Фотохостинг Скорость и объемы жестких дисков
Блогосфера Производительность серверов, скорость и объемы
жестких дисков
Социальная сеть Производительность серверов
Видеохостинг Скорость и объемы жестких дисков
Сайт знакомств Производительность серверов
Онлайн-игра Производительность серверов

8. Требуемые ресурсы при росте
посещаемости
18
16
14
12
СМИ
10
Видеохостинг
8
Сайт знакомств
6
Онлайн-игра
4
2
0
1 2 3 4 5 6 7 8

9. Общее решение
Горизонтальное
масштабирование
(scaling out)
Масштабиро- Вертикальное
Шардинг
масштабирование
(sharding)
вание (scaling up)
Функциональное
разделение
(partitioning)

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

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

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

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

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

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

16. Серебряная пуля
Слабосвязанная
Асинхронные
вычисления
Масштабируемая
архитектура
Слоистая
Горизонтальное
масштабирование

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

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

19. Типичная архитектура: обычный сайт
Image Server / 1 Image Server / 2
User images User images
Backend / 1 Database / 1
nginx nginx
PHP MySQL
Backend / 2 Database / 2
MySQL для
PHP
блогов
Frontend
nginx memcached
Backend / 3
PHP
Design images
DNS-Балансинг
DNS-Балансинг Демоны

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

21. Узкие места
Узкое место Характерно для… Решается…
Производительность Для всех типов сайтов, Добавление новых серверов,
вычисляющих особенно для социальных изменением архитектуры
серверов (бекендов) сетей и блогосфер программного обеспечения
Данные не Для некоторых конкретных Покупка более подходящего
помещаются в сервисов: поиск, поиск на аппаратного обеспечения или
оперативную память сайте знакомств, построение изменение архитектуры
френдленты, программного обеспечения
коллаборативная
фильтрация.
Данные не влезают Для фотохостингов, Разбиение хранилища на части и
на диск видеохостингов написание специального алгоритма
маршрутизации файла (например,
по его имени). Разные части
разносятся на разные сервера
Данные нельзя Для почтовых систем, Покупка специальных дисковых
разбить, но они не поисковых систем хранилищ – дорогие устройства с
влезают на один диск повышенной емкостью.

22. Узкие места - 2
Узкое место Характерно для… Решается…
Объем отдаваемого Характерно для Покупка дополнительных серверов
трафика видеохостингов, (фронтендов), покупка специального
онлайн-игр и маршрутизирующего аппаратного
любых крупных обеспечения. Также возможна аренда более
проектов мощного канала и изменение топологии
серверного парка
Производительность Крупные СМИ, Покупка или аренда специализированных
базы данных интернет-магазины серверов для базы данных. Оптимизация и
тюнинг базы данных.
Объем и Для любого В качестве первого шага возможна настройка
производительность крупного сайта кластера баз данных или репликации, когда
базы данных базу данных обслуживает несколько серверов.
Более долгосрочное решение –
переписывание программного кода так, чтобы
он работал с несколькими базами данных или
вообще без них.

23. Развитие проекта
Невозможность
Рефакторинг,
дальнейшего роста
изменение
посещаемости, техн
ологическое архитектуры
ограничение
Рост
посещаемости
через
оптимизацию

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

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

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

27. oleg.bunin@ontico.ru
LiveJournal: oleg_bunin