Проблема взрывного роста аудитории: что делать, когда не хватает мощностей?

1. Проблема взрывного роста аудитории: что делать, когда не хватает мощностей? Типичный случай интернет-проекта: онстановится популярным и с каждым днём его аудитория растёт невиданными темпами. Каким образом наращивать мощность оборудования и ПО с учётом того, что останавливать проект нельзя?

2. 310k – онлайновая игра • Классическая LAMP система • Прежде всего - чат со всеми сложностями в отдаче информации в реальном времени • Быстрый (крайне быстрый) рост аудитории со 100 до 3000 человек • [-] плохая оптимизация кода • [-] проблемы с бюджетом

3. INFON Spike • J2EE • 365х24х7 • миллионы запросов в сутки • каждый абонент – это живые, уже заплаченные им деньги, поэтому запросы терять нельзя • высокая нагрузка на биллинг

4. Diary.Ru • LAMP система • рост аудитории опережал добавление мощностей • был достигнут «потолок» архитектуры (добавление ещё одной машины ничего не решало) • [-]MySQL и падение репликации мастер-мастер • [-] узкое место – БД • [-] экстенсивное наращивание БД и неоптимальная логика работы приложения (к примеру – JOIN’ы) • [-] отсутствие кэширования выборок

5. Когда становится очевидным, что железо не справляется?

6. Когда становится очевидным, что железо не справляется? • когда оно странно пахнет… • и дымится.

7. Когда становится очевидным, что железо не справляется? • время отклика • отказы запросов • отсутствие реакции на запрос • непонятные ошибки, которых ранее месяцами не было • когда падают сервера • нехватка памяти • сбои репликации • низкая производительность терминальных приложений • ошибки открытия сокетов • ошибки выделения потока на запрос

8. С чего начать переделку?

9. С чего начать переделку? • с аудита системы!

10. Прежде всего, плясать от пользователя!

11. Прежде всего, плясать от пользователя! • взять пользователя и очертить список его задач • какие типы пользователей есть в системе (сайте)? • чем каждая группа отличается от других, что они делают на сайте? • какие задачи выполняют? • какой процент запросов приходится на выполнение той или иной задачи?

12. Прежде всего, плясать от пользователя! • внутренний путь пользователя по системе • разделить виды запросов пользователя к системе (вызов френдленты, комментирование) • взять наиболее часто встречающиеся виды запросов и нарисовать их, стрелочками показывая «а вот теперь он идёт туда» в сиквенс-диаграмме

14. Найти и оценить проблемные блоки

15. Найти и оценить проблемные блоки • идти от внутреннего пути пользователя • где больше всего теряется времени • может сказаться на количестве свободных ниток • где больше всего тратится процессорного времени • может нехватить другим на обработку • неразделяемые ресурсы, в очередях на обращение к которым стоят модули программ • прежде всего - обращения к диску • общая память приложений • хранение сессий вчастности • и, вообще, хранение данных • гэтвей на приём и отправку запросов • инфраструктура, накладывающая ограничения на траффик

16. Только на этом этапе стоит нарисовать всю систему вцелом! • аудит внутреннего пути даст представление, с какой подробностью и какие блоки стоит рисовать • Если начать рисовать раньше, то можно оказаться в ловушке «зашоренности сознания» - представляя всю систему вцелом, выделяются далеко не самые главные блоки, из-за которых происходят тормоза)

17. При рисовании и обсуждении системы полезно воспользоваться следущими приёмами:

18. Пригласить эксперта со стороны

19. Пригласить эксперта со стороны

20. Эксперт должен говорить на одном с вами языке! • приглашать на обсуждение типа пользователей и их внешнего пути, к примеру, юзабилиста можно и даже рекомендуется • а вот приглашать того же юзабилиста на оценку внутреннего пути пользователя может оказаться ошибкой, потому что в этом случае ему придётся объяснять много новых терминов

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

23. White Board! • рисовать всё слайдами • подписывать каждый слайд и писать тезисы обсуждения • фотографировать слайд, после чего его можно стирать или модифицировать

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

26. Разработчики системы • Прежде всего – сисадмин, который самый первый сталкивается с багами • Дизайнер-юзабилист-программист клиента, который разрабатывает «морду сайта» • Тестер, который знает все баги прошлой системы • И тот парень, который даёт деньги на новое оборудование

27. Планирование

28. Важно не забыть о: • Рабочих руках. • кто чем может заниматься и сколько времени они могут потратить на проект • немаловажно – в какой промежуток времени у них будет это время! • Доступных ОС и языках программирования • это может быть важно, в случае, если люди умеют писать на нескольких языках • Материальных ресурсах • прежде всего, количество серверов • сетевая инфраструктура (хостинг) • память • производительность машинок • лицензии на различные проприетарные модули системы • т.д. • Времени на переделку вообще • тут полезно задуматься об этапах (милстоунах), к которым хотелось бы что-то получить и договориться, что это «что-то» будет

29. Какие части системы очень не хочется переделывать: • «морда сайта» • да и вообще дизайн, потому что долго и муторно, а дизайнер, который это делал давно уволился • редизайн сайта в условиях, когда пользователям всё нравится, посещаемость активно растёт, а вот бэкэнда нехватает – странное дело

30. Какие части системы очень не хочется переделывать: • интерфейсы интеграции и связи с внешними партнёрами • потому что интерфейсы были утверждены давно, их формат – предмет договора, заключённого в позапрошлом году, да и партёры не собираются ничего менять

31. Какие части системы очень не хочется переделывать: • формат базы данных • и вообще переделывать БД – долго и муторно, данные терять не хочется и т.д.

32. Какие части системы очень не хочется переделывать: • какие-то куски бизнес-логики • потому что они были написаны каким-то индусом из оффшорной конторы и как они работают без буддисткого мироощущения понять решительно невозможно

33. Просто требуется представить, как дальше будет развиваться проект • Какая посещаемость будет у него через год? • А через два года? • А через три?

34. Проектирование. • Во время аудита системы и планирования становится понятен круг задач: • что нужно будет переделать точно • какие есть критические места (а значит и стоит подумать над этими вещами) • от каких частей отказываться точно нельзя • и что всё же делать с тем, что переделывать не хочется, но очень надо

35. Общая архитектура системы • предлагаются все-все идеи новой системы, как она должна функционировать, из каких блоков состоять, как в ней разрешены указанные проблемы • неплохо посмотреть на уже готовые примеры (хотя бы на уровне блок-схем) • посмотреть достоинства и недостатки каждой предложенной архитектуры и кратко рассмотреть, чем это грозит в ближней перспективе • количество работ по переделке • время • как решены проблемы того, что переписывать не хочется

36. Типичные решения проблемы производительности

37. Более мощное железо? • даёт быстрый рост производительности • не нужно переделывать систему • запас производительности быстро исчерпывается • требует хорошей команды админов для переноса кода • энергопотребление = проблемы со стойками

38. Написать более эффективный код • помогает разгрузить сервер • может решить какие-то замеченные проблемы со стабильностью и безопасностью • к сожалению плохо помогает с неразделяемыми и разделяемыми ресурсами • чаще всего тормозит или нестабилен не плохой код, а используемые чужие библиотеки, сервера и БД • уже в краткосрочной перспективе при увеличении количества народа быстродействия снова не хватит

39. Оптимизировать запросы к БД • правильно использовать возможности БД – это насущная необходимость • от join’ов избавляться нужно – это однозначно • не стоит забывать использовать выборки по индексам! • Вспомнить SQL (к примеру, считать количество полей cout’ом, а не выборкой) • хранимые процедуры позволяют существенно увеличить производительность • уже в среднесрочной перспективе эффект от этого сойдёт на нет: БД всё же ограничена по вычислительным ресурсам, а возможности для оптимизации буду уже исчерпаны

40. Оптимизировать структуру БД • Разделить поля по типу записи и чтения в них: • статические (редко меняемые, такие, как user info), оптимизированные на чтение откроет возможности для кэширования • поля на запись (к примеру, сообщения в чате) позволит более эффективно воспользоваться механизмом репликации • выделение постоянно дополняемых таблиц позволит использовать механизм партишининга

41. Оптимизировать структуру БД • разделение хранимой информации по схемам: • к примеру, вынос информации пользователей, чьё имя начинается от A до D в одну схему, E-H – в другую и т.д. • позволит легко переносить схемы между различными серверами БД, становится легче добавлять новые машины • меньший объём информации = быстрые выборки!

42. Оптимизировать структуру БД • Более эффективная структура БД позволит расширять поля для хранимой информации • Оптимизация данных может помочь эффективному использованию индексов • серьёзная переделка БД заставляет писать новую бизнес-логику доступа к ней • хорошо, когда эта бизнес-логика отделена от программы, а если она находится в том самом коде талантливого индуса, куда лезть не следует?

43. Использование репликации БД • Теперь выборки могут производиться сразу на нескольких серверах! • Особенно эффективна репликация по типу: пишем в мастер, читаем со слейвов. • Для многих серверов есть готовые решения для балансировки нагрузки, зачастую даже интегрированные с кэшем выдачи • в долгосрочной перспктиве могут начаться отказы и ошибки репликации при определённой скорости записи • при падении сети происходит рассинхронизация БД • особенно губительно для реплик мастер-мастер • требует переделки логики доступа к БД • нужно вводить балансер, который равномерно распределяет нагрузку между зеркалами

44. Кэшировать! • Память всё дешевеет, а производительности на кэш не нужно (можно использовать старые машины) • очень правильно выделить отдельные машинки под сервера кэша – это может быть MemCached или JBoss Cache • для этого очень помогает выделение объектов, которые не меняются во время жизни сессии пользователя. К примеру – те же сессии или user info в блоге или форуме • когда кэш является посредником к БД – эффективно писать интерфейсы доступа к данным • Нужно получить какой-то объект – дёргаем интерфейс. Он лезет в кэш, нет объекта в кэше – лезет в БД, кладёт в кэш и отдаёт реквестеру. Таким образом в кэше всегда есть актуальный объект.

45. Кэшировать! • Основной минус: кэш неэффективен, когда объекты запрашиваются редко либо объектов так много, что они просто вытесняются более новыми • нужно считать, где кэш будет эффективен • для этого пригодится аудит системы, знание внешнего и внутреннего путей пользователя • переделка объектов для эффективного кэша затрагивает структуру БД и бизнес-логику приложений • см. многострадальный код индуса)

46. Использование множества зеркал и балансировщика между ними • Более гладко распределяется нагрузка • Можно за балансировщиком поставить различные машинки для разных типов запросов • к примеру ngnix как балансер, один сервер – для отдачи картинок и прочей статики и пару серверов с ПХП приложениями • если за разными серверами, балансированными балансером скрывается общий бэкэнд или неразделяемый ресурс (к примеру, БД), то эффективность этого механизма резко падает

47. Очереди задач Те вещи, которые выполняются периодически (например, рассылка комментариев по почте) неплохо выносить в специальные обработчики с очередями задач к ним. • можно использовать готовый механизм очередей задач (например, Apache ActiveMQ – он имеет механизмы интеграции с большинством современных языков программирования) • можно написать свой (как обёртку над кроном или другим планировщиком)

48. Очереди задач • главное достоинство – иметь возможность поместить какую-то задачу в очередь и как только для неё будут свободные ресурсы – она выполнится • это серьёзно позволяет нормировать нагрузку на сервер • синхронизацию каких-то частей тоже эффективно производить через очереди • конвертация БД или перекладывание данных из одного формата в другой • в обработку через очереди классно выносить те вещи, что не требуют немедленной реакции • например, различные рассылки внутрисистемных уведомлений, внутренняя почта, рассылка уведомлений администратора, подсчёт пользователей на сайте, различная статистика

49. Очереди задач • Полезное достоинство – связывание частей системы через общие серверы очередей • класть в очередь могут одни части системы на одной машине, а выполнять – другие, на другой, что позволяет гибко нормировать нагрузку

50. Очереди задач • основной минус очередей – асинхронность выполнения, никто не гарантирует получения ответа в заданный промежуток времени