Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость. Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере). - Зачем оно нужно, если и так всё работает? - Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером. - Типичная схема. - Балансировка нагрузки. - Какие, вообще, проблемы на стороне приложения? - Почему PHP так хорош для масштабирования. - Сессии. - База данных. - Файлы. - Как быть со статистикой?

1. Горизонтальное
масштабирование
Что, зачем, когда и как
Александр Макаров
Yii core team, Stay.com
slides.rmcreative.ru/2015/horizontal-scaling-highload/

2. Что такое
масштабирование?

3. Возможность увеличить производительность проекта
за минимальное время путём добавления ресурсов.

4. Способы
масштабирования
— Вертикальное. Больше памяти, быстрее диск,
лучше процессор в пределах одного сервера.
— Горизонтальное. Больше серверов в кластере.

5. А оно надо? И так всё
работает!

6. Как проверить?
—
— siege
ab

7. ab
ab ‐n 100 ‐c 10 http://example.com/
Concurrency Level: 10
Time taken for tests: 1.889 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 1003100 bytes
HTML transferred: 949000 bytes
Requests per second: 52.94 [#/sec] (mean)
Time per request: 188.883 [ms] (mean)
Time per request: 18.888 [ms] (mean, across all concurrent requests)
Transfer rate: 518.62 [Kbytes/sec] received
Connection Times (ms)
min mean[+/‐sd] median max
Connect: 57 59 1.7 59 64
Processing: 117 126 7.5 124 162
Waiting: 57 62 7.0 60 98
Total: 175 186 8.0 184 224
Percentage of the requests served within a certain time (ms)
50% 184
66% 186
75% 187
80% 188
90% 192
95% 203
98% 216

8. siege
siege ‐b ‐c10 ‐t60S http://example.com/
** SIEGE 2.72
** Preparing 10 concurrent users for battle.
The server is now under siege...
Lifting the server siege... done.
Transactions: 4066 hits
Availability: 100.00 %
Elapsed time: 60.00 secs
Data transferred: 13.73 MB
Response time: 0.22 secs
Transaction rate: 67.77 trans/sec
Throughput: 0.23 MB/sec
Concurrency: 14.95
Successful transactions: 4066
Failed transactions: 0
Longest transaction: 3.28

9. — RPS / TPS
— Response time

10. Бывает, что не надо...
пока
— Обновить PHP (+40%)
— OpCache + потюнить (не должно быть misses)
— Добавить индексы в БД, пооптимизировать
— Включить кеш (memcache, Redis)
— Apache → nginx + php-fpm

11. Далее будут доклады
на тему оптимизации
— PostgreSQL, Илья Космодемьянский
— MySQL, Василий Лукьянчиков

12. Это просто и может
дать вам время

13. Мало!!!

14. Но мы же уже всё
сделали?!

15. Мониторинг
— Выиграйте время
— Настройте мониторинг
— Он покажет, куда и как расти
Повторяйте постоянно.

16. Что может показать
мониторинг
— Упёрлись в диск
— Мало памяти
— Мало процессора
— Сеть не выдерживает
— Всё более-менее, но ошибки валятся
— ...

17. На что обращать
внимание прямо
сейчас
— Доступность
— Нехватка ресурсов
— Ошибки

18. Мониторим ресурсы
—
—
—
—
—
Monit
Zabbix
Munin
Nagios
ServerDensity

19. Мониторим ошибки
—
—
Rollbar
Sentry

20. Нотификации
Важно уведомить, но не стоит спамить.

21. Что анализировать
— RPS
— Response time
— Количество процессов
— Количество потоков
— Размеры очередей
— ...

22. Будет подробно в
докладе Александра
Крижановского завтра

23. Бизнес-анализ
—
—
— На основе своих данных (позже)
Google Analytics
mixpanel

24. Когда?
Нагрузка бывает как запланированная, так и нет:
— Сезонная
— Реклама
— Новости
— Акции

25. Как бороться с
нагрузкой?
Бизнес решает. Важна цена вопроса.

26. Возможно, это будет
дешевле:
— Профайлинг, очевидные оптимизации
— Кеш в memcached
— Правка конфигов сервера
— ...

27. Если железо дешевле
программиста

28. Типичная схема
Балансировщик + несколько серверов приложения

29. Что даёт?
— Возможность обработать больше запросов
— Надёжность

30. Почему PHP так хорош
для масштабирования
Share nothing по умолчанию.
То есть слабая связанность для слоя серверов
приложений.

31. Балансировка
нагрузки
— nginx
—
—
— Аппаратные
Squid
HAProxy

32. Проблемы
— Как выбрать сервер?
— Как хранить сессии?

33. Выбор сервера
— По очереди из списка (round-robin)
— География IP
— Статистика (least-connected, доступность)
— Как-то ещё

34. nginx
h p://nginx.org/en/docs/h p/load_balancing.html

35. А что если упрёмся в
балансировщик?

36. Сессии
— По умолчанию в файлах
— NFS?
— БД?
— Нельзя писать в кеш, если данные в сессии важны
— Можно поместить в общее отдельное хранилище
— Redis однопоточный
— По Redis на каждом инстансе, sticky-сессии (ip-hash)

37. Прокси для memcached
и Redis
h ps://github.com/twi er/twemproxy

38. Не пишите своего
аналога сессий,
используйте PHP!
—
—
h ps://php.net/manual/ru/class.sessionhandler.php
h ps://php.net/manual/ru/function.session-set-save-
handler.php

39. Закрывайте сессии
session_write_close();

40. Файлы
— Специализированное решение
— «Шардирование» средствами PHP

41. Специализированные
решения
—
—
GlusterFS
Amazon S3

42. PHP
Flysystem

43. Раздача
—
—
nginx
Varnish

44. Замечания
— Не хранить в базе!
— Можно хранить локальный кеш. Например, для
роутинга запросов.

45. База данных
— Репликация master-slave
— Репликация master-master
— Репликация руками
— Шардирование
— Партицирование (расскажет Денис Иванов далее)

46. master-slave

47. Зачем?
— Читаем больше, чем пишем? Будет быстрее.
— Отказоустойчивость.
— Бэкапы (реплику можно остановить).
— Тяжёлые вычисления (о статистике далее).

48. read/write split
— 2 пула серверов: master, slave
— Соединение по требованию
— Логика выбора соединения варьируется...

49. Логика
— Писать всегда в master
— Только чтение с slave (array_rand())
— Чтение для записи - ...

50. Засада... репликация
лагает
Иногда данные попадают с master на slave с задержкой.
Для MySQL:
mysql ‐e "SHOW SLAVE STATUS;" | grep Seconds_Behind_Master
PostgreSQL:
select now() ‐ pg_last_xact_replay_timestamp() AS replication_delay;
— 0 = OK. Читаем с slave.
— Больше 0 = ждём или читаем с master.
— NULL = ещё не реплицировали (логи!). Читаем с
master.

51. Причины
— Медленная сеть.
— Не справляется реплика.
— Слишком много слейвов (>20 на мастер).

52. master-master

53. Зачем?
— Отказоустойчивость.
— Может быть быстрее.

54. Логика
Выбираем рандомное соединение.

55. Минусы
— Лаг репликации выше.
— Поломка = потеря данных. Поломка
реплицируется.
— Может забить сеть.

56. О репликации в MySQL
сегодня расскажет
Андрей Аксенов

57. Репликация руками
Всегда можно сделать это руками.

58. Шардирование
Размазывание данных по нескольким серверам.

59. Отдельные таблицы
Отдельные соединения. WHERE IN вместо JOIN.

60. Часть одних и тех же
данных

61. где 3 - количество серверов. Альтернаива - map в key-
value хранилище.
Как выбрать сервер?
$connectionID = 'user_db' . ($user_id % 3 + 1);

62. Попроще
Попробовать разделить на части, которые
используются вместе, но не пересекаются.
Надо знать ID пользователя, но легко выбрать все его
посты, посортировать и т.д.

63. Посложнее
Не удаётся сгруппировать данные.
Надо знать ID данных, чтобы их достать. Никаких
JOIN, ORDER и т.д. Таблица используется как key-value.

64. Обычные задачи
становятся
необычными
— Выбрать TOP 10.
— Постраничная разбивка.
— Выбрать с наименьшей стоимостью.
— Выбрать посты юзера X.

65. А правильно ли мы
выбрали хранилище...

66. Шардинг из коробки
— memcache
— Redis
—
— ...
Cassandra

67. Подробно о
шардировании сегодня
будет в докладе
Дениса Иванова

68. Как быть со
статистикой?
Считать статистику по основным данным - ошибка.
— Скорее всего вам не нужен realtime.
— Не считайте статистику на основной базе.
— Специальный slave.
— OLAP
— Или что-то готовое...

69. Фоновая обработка
Всё, что не критично сделать прямо сейчас, можно
обработать в фоне.

70. Зачем?
— Быстрее ответ сервера
— Можно размазать нагрузку
— Можно обработать на другом сервере
— Можно обработать не PHP
— ...

71. Как?
— AMQP: ,
—
—
—
ActiveMQ RabbitMQ
beanstalkd
Amazon SQS
Gearman

72. Подробно будет
сегодня в докладе
Константина Осипова

73. Архитектура

74. Меньше связанности!
Чем меньше связанности, тем проще менять одно
решение на другое.

75. Связанность?
— В коде (SOLID, GRASP)
— В доменном слое
— В архитектуре в целом

76. SOA
— Система бьётся на отдельные логические части
— Части взаимодействуют через интерфейсы

77. Доменный слой
— Сверхважно отделить его от контекста, в котором
он выполняется
— Что происходит в самом слое не так важно, но
лучше делать это правильно

78. Про доменный слой
— Domain-Driven Design: Tackling Complexity in the
Heart of So ware, Eric Evans
— Implementing Domain-Driven Design, Implementing
Domain-Driven Design
— иBoundedContext DDD в общем

79. В архитектуре
— share nothing
— логика на стороне приложения
— низкая связанность

80. Не стоит
недооценивать
браузерную
оптимизацию

81. Абстракция и
дробление совсем не
бесплатны.

82. Не действуйте
вслепую.

83. Думайте.

84. Проверяйте.

85. Материалы
—
—
—
— Поискать по "highload" в рунете
— Поискать по "sclability" в англонете
Distributed systems for fun and profit
h p://ruhighload.com/
h p://www.insight-it.ru/

86. Как всё это
попробовать?
— DigitalOcean
— Linode
— ...

87. Вопросы?
—
—
slides.rmcreative.ru/2015/horizontal-scaling-highload/
rmcreative.ru