Только ленивый не достал с дальней полки свою экспертность и не предсказал «онлайнизацию» жизни — такую же вынужденную, как и режим самоизоляции. Но трафик, действительно, уже начал расти, а с учётом «каникул» до конца апреля ресурсы, предлагающие доставку товаров, услуги онлайн-образования и, особенно, онлайн-развлечений, могут оказаться не готовыми к потоку посетителей в новой реальности.
Опираясь на свой 12-летний опыт технической поддержки веб-проектов и удалённого администрирования серверов, мы подготовили своего рода «методичку»: что стоит проверить и о чём нужно позаботиться, если вы хотите быть уверенным, что ваш сайт справится с любой нагрузкой. Ну, почти любой.
Итак, вот 10 пунктов, которые критичны для активной жизни вашего веб-проекта в ближайшие дни и недели:
1) Мониторьте вашу инфраструктуру
Прежде всего, вы должны знать, что вообще происходит с вашим сайтом. Если вы умеете обращаться с Prometheus/Grafana, используйте их. Но если опыта взаимодействия с ними нет, это не проблема: можно использовать любой сервис наподобие datadog — вы можете установить его максимально оперативно. Всё ещё сложно? — Обратите внимание на Pingdom или Site24x7: это не полноценные сервисы мониторинга, но они подойдут хотя бы для того, чтобы быть уверенным в доступности вашего сайта и знать, когда он близок к падению.
Помните: вы можете контролировать только то, что можете измерять. Ведь если вы не знаете, что происходит внутри вашей системы и, особенно, где это происходит, — вы не сможете починить, если там что-то сломается.
Есть много вариантов, что может пойти не так, когда наваливается трафик:
- вы ограничены ресурсами процессора.
- вы ограничены лимитами оперативной памяти.
- вы ограничены производительностью дисков\хранилища.
- вы ограничены пропускной способностью вашего облачного инстанса\кластера\сервера.
2) Приготовьтесь масштабироваться
Как только вы увидите, что достигли 80% лимита по ресурсам, необходимо незамедлительно начать масштабирование. Потому что если дождаться 100%, сайт упадёт. И вам потребуется какое-то время, чтобы восстановить работу проекта. Не говоря уже о том, что это всё довольно нервно…
Вы должны действовать быстро, потому что в противном случае вы потеряете посетителей и, возможно, наделаете ещё больше ошибок в режиме «шеф, всё пропало, горим». Поэтому при достижении отметки в 80% лимита ресурсов масштабируйтесь, чтобы снизиться до 40%.
При необходимости — повторить (с)
3) Не забывайте следить за производительностью HDD и пропускной способностью каналов
Гораздо сложнее понять, что происходит, когда система «тупит» из-за высокой дисковой нагрузки или ограничений пропускной способности канала.
4) Контролируйте производительность своих БД
Особенно если вы используете облачные базы данных. RDS, Cloud SQL, MongoDB Atlas и другие сервисы управляются с помощью облачных технологий, но у них есть свои лимиты, и за ними нужно обязательно следить, чтобы вовремя масштабироваться.
5) Когда ваша БД создает большую нагрузку на CPU — проверьте использование индексов, это реально помогает
Внедрение индексирования фантастически снижает нагрузку на процессор. Предположим, CPU вашей БД используется на 90%. Вероятно, вы захотите масштабироваться вдвое, чтобы справиться с двойной нагрузкой. Но если бОльшая часть ваших запросов не индексирована, то внедрение индексации может снизить нагрузку на процессор в 10 раз. Анализ использования индексов стоит затраченных на него усилий!
6) Не спускайте глаз со счетов за услуги облачных провайдеров
Легко забыть про это, когда у вас цейтнот. Поэтому установите алерты в вашей биллинговой системе, чтобы получать уведомления о возможных перерасходах. Ширина канала — вот что особенно затратно. Если нет возможности перенести контент в CDN или в хостинговые компании, предоставляющие большие объемы трафика задешево, наподобие like100tb.com или leaseweb, — готовьтесь к серьёзным издержкам.
7) Избегайте состояния (state) в вашем приложении
Несмотря на то, что возможно масштабировать ресурсы процессора или оперативной памяти в облаке, всё же есть лимиты, которые невозможно перешагнуть. С этой точки зрения, если вы захотите масштабироваться горизонтально, прибавляя новые инстансы того же приложения, оно должно быть готово к такому развитию событий. И когда у вас есть многочисленные инстансы одного и того же приложения, пользовательские запросы будут распределены между многочисленными серверами, и вследствие этого вы не сможете хранить данные на локальном диске.
8) Рассмотрите переезд в облако, если сайт находится на выделенном хостинге
Ибо в такой ситуации вы не сможете легко масштабироваться: добавление серверов займёт определённое количество времени — от пары часов до пары дней понадобится, чтобы получить доступные новые серверы. К тому же, обычно вы платите помесячно, а не почасово. В общем, вы явно не захотите ждать часы, а то и дни, если ваш сайт «лежит». Много проще масштабироваться в облаке.
9) «Затюньте» инфраструктуру
Есть несколько базовых вещей, которые по умолчанию отключены, а их стоит оптимизировать — на уровне ОС, сети, менеджера приложений и самого приложения. И это способно значительно уменьшить потребление ресурсов. Погуглите настройку вашего технологического стека и следуйте базовым рекомендациям.
10) Будьте готовы запустить кэшированную версию
Невзирая на все ваши усилия, при стократном росте трафика, вы «ляжете». Чтобы масштабироваться, нужно время. Так что будьте готовы воспользоваться статической кэшированной версией. Для этого пригодится кэш Cloudfront/Cloudflare, ваш CDN-кэш, кэш nginx’а или любой другой. Просто удостоверьтесь, что у вас есть такая возможность, буде она понадобится.
Sannis
Всё-таки я бы посоветовал задумываться об этом уже при 60%. Как правило на application серверах при преимущественно CPU-bound нагрузке из-за hyper threading начинается нелинейный рост.
antosha
Ну, в общем, да, 60% — это отметка отсечения, аларм. А 80% — тут уже время действовать. Женя об этом речь ведёт :-)