Тайны хайлоад.
Скандалы, интриги, расследования.
Что такое Highload?
Highload (хайлоад) - это когда приложение выдерживает/не выдерживает пики допустимой нагрузки. Я бы назвал это нагрузка по горлышко.
Как возникает высокая нагрузка?
Приложение растет, развивается и при этом приводит много пользователей. Пользователи создают активность на сайте (хиты).
Highload можно поделить на 2-типа по возникновению:
- Планомерный - когда система каждый месяц собирает все больше и больше пользователей вокруг себя.
- Резкий - это когда вашим приложением внезапно начали пользоваться на несколько порядков больше пользователей чем раньше.
Резко нагрузка может возрасти из-за того что ваш функционал стал интересен большому кругу пользователей или на ваш ресурс подключили огромную рекламную кампанию.
Вызвать проблемы с вашим ресурсом может так называемый "Хабраэффект" - когда ссылку на ваш ресурс опубликовали на всем известном it-ресурсе или другом очень посещаемом ресурсе и все резко начали заходить к вам в приложение чтобы "посмотреть" и как правило сайт становится не доступным или открывается очень медленно.
Вы все поймете сами
Тот момент когда вы заходите на сайт, а там либо бесконечный ответ сервера, либо ошибка базы данных или еще что нибудь от сервера - это все признак того что сервер перестал справляться с текущей нагрузкой и наступил момент когда ваше приложение по горлышко забито трафиком. Системы мониторинга, клиент, менеджеры вам сообщат о том что ваше время настало.
Главный герой
Главным героем в такой ситуации является разработчик приложения со всей свитой.
- Разработчики модулей - для оптимизации кусочков приложения
- Системный администратор - для конфигурации сервера
- Тех-поддержка вашего вашего хост-провайдера - помощь со стороны прова. Сеть, железо, анализ
- Менеджеры - для успокоения клиента. Здрасте у нас тут сайт не работает
- Добрые люди - кормить, вытирать пот со лба разработчиков
Вот они:
Что делать?
- Звонить клиенту и говорить про сложившуюся ситуацию
- Писать провайдеру чтобы узнать все ли в порядке с сетью и железом
- Рисовать заглушку о том что на сайте кратковременные проблемы (на всякий случай)
- Собрать статистику по загрузке отдельных модулей
- Разбить модули на статические и динамические. Статику отдаем без обработки - сразу из файла. Динамику кешируем по возможности.
- Засучить рукава и вперед работать с тяжелыми кусками приложения
- Настраивать сервер под высокие нагрузки, при необходимости нарастить серверное железо
За работу! Делаем хорошо сразу!
Все должно быть просто и независимо
Простые решения разрабатывать очень сложно так как нужно полностью реализовать тз. по приложению.
Простые решения - сложно, долго, дорого, но делать нужно изначально все просто и независимо. Зачастую редко получается собрать все модульно и независимо, но это нужно делать! Независимость модулей дает свободу и скорость монтажа/демонтажа компонентов. Простые модульные решения - это гибко.
Гибкая система не бывает сложной.
Правильно инвестировать время на разработку
Правило 95%
Инвестируйте время только в обеспечение 95% функционала. Остальные 5% отбрасывайте — это частные случаи, которые ведут к усложнению системы.
Примеры из жизни:
- Некоторые пользователи в соц. сети могут иметь десятки тысяч связей. Если их менее 5%, поставьте ограничение и не решайте эту задачу, пока есть более важные проблемы.
- Некоторые пользователи грузят видео, которое имеют нестандартную кодировку. Покажите ошибку вместо того, чтобы тратить время на доработку конвертера.
- Менее 5% пользователей используют браузеры с отключенными куками, ограничениями Javascript и т.п. Отключите возможность просмотра сайта для них и разместите подробные инструкции по обновлению браузера вместо адаптации сайта под них.
Нужно решать только самые важные задачи, так как у разработчика - задач всегда больше чем времени на их решение. Поэтому очень важно уметь расставлять приоритеты, и верно принимать решения на любом уровне.
Архитектура
Самое важное и значимое. Важность хорошей архитектуры проекта очень сложно переоценить. Архитектура должна по умолчанию подразумевать гибкость решения для дальнейшего масштабирования.
Если фундамент верный и крепкий, то можно построить многоэтажное приложение.
1. Простота
Обычно приложение сначала запускается на одном сервере и это хорошо и очень удобно, так как база и бек-енд работают на одном сервере.
Для старта это очень хорошее решение. Экономия сил, денег и времени на поддержку. Можно арендовать мощный сервер чтобы справиться с возрастающей нагрузкой. Но бывает так, что приложение сразу отдается огромной аудитории и сразу ясно что highload с первых дней. Вот тогда делаем то что описано ниже.
2. Миграция базы данных на отдельный сервер
Во всех приложениях в большинстве случаев самым слабым и высоконагруженым местом является база данных. Все дело в запросах.
Обычно один хит это от 10-ти до 100 (иногда более) запросов в бд.
Разнесение базы данных и вашего бек-енда позволит повысить производительность базы данных, и облегчить работу всех компонентов на бек-енд сервере.
Если база и бек-енд лежат отдельно, то эти сервера работают независимо и, следовательно, не влияют друг на друга.
Для того чтобы подключится к удаленной базе, в настройке подключения вместо привычного нам localhost, необходимо вписать IP нашего сервера бд. К примеру 10.10.0.2
Даунтайм (время простоя)
Когда вы будите переносить базу данных, то пользователи будут в нее что то писать. Наше приложение работает 24/7 и поэтому каждую секунду работает CRUD
Что делать?
- Просто и эффективно. Отключить ресурс, и вывесить объявление о плановых работах. Лучше это делать ночью (ели это не порнхаб)
- Репликация баз данных.
Репликация это механизм для масштабирования базы данных, который позволяет синхронизировать базы данных.
Мастером будет старый сервер, а слейвом новый. После настройки достаточно поменять IP адрес базы в приложении на новый сервер. А далее — выключить старый сервер.
После того как настроите как перенесете базу, не забудьте настроить конфиги.
3. Разносим веб-сервер и бек-енд
Выделение бек-енд сервера (в нашем случае PHP) позволит повысить производительность вычислительных мощностей.
Сервер PHP обычно называют бекендом. Тогда Nginx будет отдавать файлы статики самостоятельно, а PHP сервер будет занят только обработкой скриптов.
4. Несколько PHP бекендов
Веб сервер и бек-енд разнесли, но нагрузка продолжает зашкаливать. Делаем несколько php бекендов.
5. Кеширование
Простое и эффективное решение - помимо кеша которой используют компоненты приложения, подключить Memcache.
6. Очереди задач для тяжелых вычислений
Очереди нужны для обеспечения асинхронности приложения. Для этого нужен дополнительный сервер который будет работать с очередями параллельно пока работает приложение.
7. Сервер для хранения файлов
Файлов много, обычно их хранят там же где и основное приложение. Для больших сервисов это не правильно. Необходимо загружать файлы на отдельные сервера и отдавать их на отдельном домене. fs-1,fs-2...
8. Рекомендации по разработке
- Понимание принципов важнее знания инструментов
- Удаление кода лучше его написания
- Любое решение имеет плюсы
- Уровень мышления определяет уровень решений
- Побочные эффекты требуют изоляции
- Абстракция управляет сложностью
- Тесты вселяют уверенность
