Что такое highload?

Олег Федосеев (НГС) рассказывает про высоконагруженные сайты.

«Если вы интересуетесь веб-разработкой, то вы наверняка слышали слово "highload". Это модно, это интересно, все хотят это попробовать на себе. Но мало кто знает, что на самом деле значит "highload" или "высокие нагрузки" и что нужно знать, чтобы правильно "готовить" высоконагруженный проект.

Мы поговорим о том, что же такое highload, узнаем, с какими проблемами может столкнуться условный веб-проект при росте нагрузки, и попробуем решить эти проблемы. Также мы обсудим, какие подходы и инструменты должен знать веб-разработчик, чтобы успешно справиться с любыми нагрузками»

Подробности: http://techtalks.nsu.ru

Transcript

1. Что такое Highload? Тайны высоконагруженных систем. Скандалы. Интриги. Расследования.
2. • Отвечаю за веб-разработку в НГС • В вебе и программировании уже более 8 лет • Люблю Golang и котиков :) Кто я? Олег Федосеев olegfedoseev o.fedoseev@office.ngs.ru
3. • НГС один из крупнейших сайтов за Уралом • 18 миллионов хитов в день, более миллиона уникальных посетителей в день • Тысячи запросов в секунду в приложению, в пиках до 10к rps • Десятки тысяч запросов в секунду к базам • Гигабайты трафика :) Откуда я знаю про Highload?
4. Highload Определение
5. Ваш вариант? “Highload это…
6. …когда сайт ломается” “Highload это…
7. …когда больше 10 тысяч пользователей в день” “Highload это…
8. “Highload это… …когда больше 100 тысяч пользователей в день”
9. “Highload это… …когда больше миллиона пользователей в час!”
10. На самом деле нет
11. Пользователи != Запросы
12. Запросы бывают разные YouTube != Лента.ру А ещё их кэшируют :)
13. Highload это когда ресурсов одного сервера уже мало
14. Секреты высоконагруженных систем
15. LAMP’овый пример
16. Load Balancer dns nginx upstream Frontend Backend nginx upstream mysql proxy mysql proxy Shard A Shard B Slave Master proxy Memcache / Redis Task Queue NoSQL Cassandra / Riak И что получим из него
17. LAMP - Linux, Apache, MySQL, PHP Гуглить: LAMP, ubuntu, php, vps, apache server, mysql VPS
18. LAMP - Linux, Apache, MySQL, PHP Гуглить: LAMP, ubuntu, php, vds, apache server, mysql VDS
19. LAMP - Linux, Apache, MySQL, PHP Гуглить: LAMP, ubuntu, php, dedicated, apache server, mysql dedicated
20. Выносим базу Гуглить: n-tier arcitecture mysql configuration
21. nginx перед apache Гуглить: nginx, libevent, libev nginx vs apache
22. А зачем нам apache? Гуглить: php-fpm, fastcgi
23. А если у нас много видео? Гуглить: http load balancer dns round-robin ?
24. Балансировка запросов Гуглить: http load balancer dns round-robin DNS 1.1.1.1 2.2.2.2
25. Балансировка запросов Гуглить: load balancer, Cisco ACE
26. Балансировка запросов Гуглить: tcp load balancer, haproxy
27. Балансировка запросов Гуглить: geoip, anycast, bgp DNS example.com US → 1.1.1.1 EU → 2.2.2.2 ДЦ в США ДЦ в Европе
28. Промежуточный итог
29. Масштабируем backend Гуглить: nginx upstream, nginx fastcgi_pass nginx proxy_pass
30. Гуглить: Nginx proxy_cache, Nginx fastcgi_cache Varnish, Apache Traffic Server • Самое простое поставить рядом второй сервер • Меньше запросов к backend’у - меньше нагрузка • Кэшируем всё! Масштабируем backend
31. Гуглить: Nginx proxy_cache, Nginx fastcgi_cache Varnish, Apache Traffic Server • Самое простое поставить рядом второй сервер • Меньше запросов к backend’у - меньше нагрузка • Кэшируем всё! Масштабируем backend
32. Добавим кэша Гуглить: Nginx proxy_cache, Nginx fastcgi_cache Varnish, Apache Traffic Server
33. Добавим кэша Гуглить: memcache, redis, key-value store, crc32, libketama, consistent hashing, handlersocket A-I J-T U-Z
34. Добавим кэша Гуглить: twemproxy, mcrouter haproxy A-I J-T U-Z
35. Кэширование • Кэши не страшно потерять, по этому шардинг • Для лучшей отказоустойчивости используем специализированные прокси - twemproxy, mcrouter • Помним про race-condition • Экспериментально определяем размер кэша • Обязательно мониторить hit/miss
36. proxy Memcache / Redis Что получилось dns Load Balancer nginx upstream Frontend Backend nginx upstream
37. Load Balancer dns nginx upstream Frontend Backend nginx upstream Slave Master proxy Memcache / Redis Репликация Гуглить: mysql binlog, row-based/statement-based replication
38. Load Balancer dns nginx upstream Frontend Backend nginx upstream Slave Master proxy Memcache / Redis Репликация
39. Load Balancer dns nginx upstream Frontend Backend nginx upstream Slave Master proxy Memcache / Redis Репликация Гуглить: haproxy, mysql-proxy, pgpool
40. Нюансы репликации (MySQL) • Репликация может лагать • Нужно быть аккуратным с недетерминированными запросами (NOW(), RAND() и т.д.) • В случае падения мастера - нужна ручная перестройка схемы • Стоит регулярно смотреть в slowlog • Масштабирует только чтение
41. Load Balancer dns nginx upstream Frontend Backend nginx upstream Slave proxy Memcache / Redis master-master репликация
42. Load Balancer dns nginx upstream Frontend Backend nginx upstream mysql proxy mysql proxy Shard A Shard B Slave Master proxy Memcache / Redis Шардинг Гуглить: mysql cluster, mysql fabric
43. • Очень важно выбрать правильный ключ • В случае с транзакциями боль • На сколько прост ввод/вывод шарда • Записи масштабируются, но требует много ресурсов • Ещё кучи нюансов :) Шардинг Но не забываем про NoSQL :)
44. Шардинг в MongoDB Гуглить: mongodb, mongodb sharding
45. Cassandra Гуглить: cassandra, google bigtable, hbase, amazon dynamo, riak
46. • Много хороших решений • Надо уметь готовить • Другая схема данных • Другой язык запросов • Другие приоритеты в CAP теореме NoSQL
47. Load Balancer dns nginx upstream Frontend Backend nginx upstream mysql proxy mysql proxy Shard A Shard B Slave Master proxy Memcache / Redis NoSQL Cassandra / Riak Теперь с NoSQL
48. • Мастер-мастер даст отказоустойчивость • Шардинг даст пропорциональный прирост записи, но есть нюансы • Не стоит забывать про “NoSQL” решения, есть очень хорошие базы данных • Иногда полезно совмещать RDBMS и NoSQL решения Масштабирование записи
49. Load Balancer dns nginx upstream Frontend Backend nginx upstream mysql proxy mysql proxy Shard A Shard B Slave Master proxy Memcache / Redis Task Queue NoSQL Cassandra / Riak Итоговая архитектура
50. Релиз новой версии кода Гуглить: blue-green deployment continuous delivery
51. Мониторинг Гуглить: zabbix, graphite, pinba, statsd etsy skyline, opentsdb, influxdb • Графики должны быть на все изменяющиеся значения • Даже если значение не изменяется, на него должен быть график (вдруг изменится) • Как минимум следить за превышением пороговых значений • В идеале отслеживание трендов и “умное” детектирование аномалий
52. Общие нюансы Гуглить: fault-tolerance, failover, soa microservice arcitecture • Всегда помните о проблеме больших чисел • Помните о блокировках в разных частях системы • Отказоустойчивость очень важна • Загружать сервера на 100% опасно • SOA и микросервисы
53. Секреты высоконагруженных систем • Отделяем мух от котлет для полноценной утилизации ресурсов и независимой масштабируемость • Все сервисы масштабируются по разному, но подходы похожие • Но помни про нюансы (лаги, консистентность и т.д.) • Быстрый и автоматический failover залог здорового сна • Использовать php+mysql для всех задач можно, но есть специализированные сервисы для многих задач
54. Олег Федосеев olegfedoseev o.fedoseev@office.ngs.ru Вопросы?