Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Yii, Stay.com)

9,091 views

Published on

Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.

Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).

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

Published in: Engineering
  • Be the first to comment

Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Yii, Stay.com)

  1. 1. Горизонтальное масштабирование Что, зачем, когда и как Александр Макаров Yii core team, Stay.com slides.rmcreative.ru/2015/horizontal-scaling-highload/
  2. 2. Что такое масштабирование?
  3. 3. Возможность увеличить производительность проекта за минимальное время путём добавления ресурсов.
  4. 4. Способы масштабирования — Вертикальное. Больше памяти, быстрее диск, лучше процессор в пределах одного сервера. — Горизонтальное. Больше серверов в кластере.
  5. 5. А оно надо? И так всё работает!
  6. 6. Как проверить? — — siege ab
  7. 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. 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. 9. — RPS / TPS — Response time
  10. 10. Бывает, что не надо... пока — Обновить PHP (+40%) — OpCache + потюнить (не должно быть misses) — Добавить индексы в БД, пооптимизировать — Включить кеш (memcache, Redis) — Apache → nginx + php-fpm
  11. 11. Далее будут доклады на тему оптимизации — PostgreSQL, Илья Космодемьянский — MySQL, Василий Лукьянчиков
  12. 12. Это просто и может дать вам время
  13. 13. Мало!!!
  14. 14. Но мы же уже всё сделали?!
  15. 15. Мониторинг — Выиграйте время — Настройте мониторинг — Он покажет, куда и как расти Повторяйте постоянно.
  16. 16. Что может показать мониторинг — Упёрлись в диск — Мало памяти — Мало процессора — Сеть не выдерживает — Всё более-менее, но ошибки валятся — ...
  17. 17. На что обращать внимание прямо сейчас — Доступность — Нехватка ресурсов — Ошибки
  18. 18. Мониторим ресурсы — — — — — Monit Zabbix Munin Nagios ServerDensity
  19. 19. Мониторим ошибки — — Rollbar Sentry
  20. 20. Нотификации Важно уведомить, но не стоит спамить.
  21. 21. Что анализировать — RPS — Response time — Количество процессов — Количество потоков — Размеры очередей — ...
  22. 22. Будет подробно в докладе Александра Крижановского завтра
  23. 23. Бизнес-анализ — — — На основе своих данных (позже) Google Analytics mixpanel
  24. 24. Когда? Нагрузка бывает как запланированная, так и нет: — Сезонная — Реклама — Новости — Акции
  25. 25. Как бороться с нагрузкой? Бизнес решает. Важна цена вопроса.
  26. 26. Возможно, это будет дешевле: — Профайлинг, очевидные оптимизации — Кеш в memcached — Правка конфигов сервера — ...
  27. 27. Если железо дешевле программиста
  28. 28. Типичная схема Балансировщик + несколько серверов приложения
  29. 29. Что даёт? — Возможность обработать больше запросов — Надёжность
  30. 30. Почему PHP так хорош для масштабирования Share nothing по умолчанию. То есть слабая связанность для слоя серверов приложений.
  31. 31. Балансировка нагрузки — nginx — — — Аппаратные Squid HAProxy
  32. 32. Проблемы — Как выбрать сервер? — Как хранить сессии?
  33. 33. Выбор сервера — По очереди из списка (round-robin) — География IP — Статистика (least-connected, доступность) — Как-то ещё
  34. 34. nginx h p://nginx.org/en/docs/h p/load_balancing.html
  35. 35. А что если упрёмся в балансировщик?
  36. 36. Сессии — По умолчанию в файлах — NFS? — БД? — Нельзя писать в кеш, если данные в сессии важны — Можно поместить в общее отдельное хранилище — Redis однопоточный — По Redis на каждом инстансе, sticky-сессии (ip-hash)
  37. 37. Прокси для memcached и Redis h ps://github.com/twi er/twemproxy
  38. 38. Не пишите своего аналога сессий, используйте PHP! — — h ps://php.net/manual/ru/class.sessionhandler.php h ps://php.net/manual/ru/function.session-set-save- handler.php
  39. 39. Закрывайте сессии session_write_close();
  40. 40. Файлы — Специализированное решение — «Шардирование» средствами PHP
  41. 41. Специализированные решения — — GlusterFS Amazon S3
  42. 42. PHP Flysystem
  43. 43. Раздача — — nginx Varnish
  44. 44. Замечания — Не хранить в базе! — Можно хранить локальный кеш. Например, для роутинга запросов.
  45. 45. База данных — Репликация master-slave — Репликация master-master — Репликация руками — Шардирование — Партицирование (расскажет Денис Иванов далее)
  46. 46. master-slave
  47. 47. Зачем? — Читаем больше, чем пишем? Будет быстрее. — Отказоустойчивость. — Бэкапы (реплику можно остановить). — Тяжёлые вычисления (о статистике далее).
  48. 48. read/write split — 2 пула серверов: master, slave — Соединение по требованию — Логика выбора соединения варьируется...
  49. 49. Логика — Писать всегда в master — Только чтение с slave (array_rand()) — Чтение для записи - ...
  50. 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. 51. Причины — Медленная сеть. — Не справляется реплика. — Слишком много слейвов (>20 на мастер).
  52. 52. master-master
  53. 53. Зачем? — Отказоустойчивость. — Может быть быстрее.
  54. 54. Логика Выбираем рандомное соединение.
  55. 55. Минусы — Лаг репликации выше. — Поломка = потеря данных. Поломка реплицируется. — Может забить сеть.
  56. 56. О репликации в MySQL сегодня расскажет Андрей Аксенов
  57. 57. Репликация руками Всегда можно сделать это руками.
  58. 58. Шардирование Размазывание данных по нескольким серверам.
  59. 59. Отдельные таблицы Отдельные соединения. WHERE IN вместо JOIN.
  60. 60. Часть одних и тех же данных
  61. 61. где 3 - количество серверов. Альтернаива - map в key- value хранилище. Как выбрать сервер? $connectionID = 'user_db' . ($user_id % 3 + 1);
  62. 62. Попроще Попробовать разделить на части, которые используются вместе, но не пересекаются. Надо знать ID пользователя, но легко выбрать все его посты, посортировать и т.д.
  63. 63. Посложнее Не удаётся сгруппировать данные. Надо знать ID данных, чтобы их достать. Никаких JOIN, ORDER и т.д. Таблица используется как key-value.
  64. 64. Обычные задачи становятся необычными — Выбрать TOP 10. — Постраничная разбивка. — Выбрать с наименьшей стоимостью. — Выбрать посты юзера X.
  65. 65. А правильно ли мы выбрали хранилище...
  66. 66. Шардинг из коробки — memcache — Redis — — ... Cassandra
  67. 67. Подробно о шардировании сегодня будет в докладе Дениса Иванова
  68. 68. Как быть со статистикой? Считать статистику по основным данным - ошибка. — Скорее всего вам не нужен realtime. — Не считайте статистику на основной базе. — Специальный slave. — OLAP — Или что-то готовое...
  69. 69. Фоновая обработка Всё, что не критично сделать прямо сейчас, можно обработать в фоне.
  70. 70. Зачем? — Быстрее ответ сервера — Можно размазать нагрузку — Можно обработать на другом сервере — Можно обработать не PHP — ...
  71. 71. Как? — AMQP: , — — — ActiveMQ RabbitMQ beanstalkd Amazon SQS Gearman
  72. 72. Подробно будет сегодня в докладе Константина Осипова
  73. 73. Архитектура
  74. 74. Меньше связанности! Чем меньше связанности, тем проще менять одно решение на другое.
  75. 75. Связанность? — В коде (SOLID, GRASP) — В доменном слое — В архитектуре в целом
  76. 76. SOA — Система бьётся на отдельные логические части — Части взаимодействуют через интерфейсы
  77. 77. Доменный слой — Сверхважно отделить его от контекста, в котором он выполняется — Что происходит в самом слое не так важно, но лучше делать это правильно
  78. 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. 79. В архитектуре — share nothing — логика на стороне приложения — низкая связанность
  80. 80. Не стоит недооценивать браузерную оптимизацию
  81. 81. Абстракция и дробление совсем не бесплатны.
  82. 82. Не действуйте вслепую.
  83. 83. Думайте.
  84. 84. Проверяйте.
  85. 85. Материалы — — — — Поискать по "highload" в рунете — Поискать по "sclability" в англонете Distributed systems for fun and profit h p://ruhighload.com/ h p://www.insight-it.ru/
  86. 86. Как всё это попробовать? — DigitalOcean — Linode — ...
  87. 87. Вопросы? — — slides.rmcreative.ru/2015/horizontal-scaling-highload/ rmcreative.ru

×